写了这么多年代码，有没有这样的迷茫和迷茫——科技的发展日新月异，而奋起直追的我们，究竟是技术的主人还是技术的奴隶？今天就来说说技术人的软件世界观。在浩瀚的软件世界中，作为一个普通的程序员，显得渺小，甚至迷茫。我们内心崇拜技术，但也对日新月异的技术深表恐惧。有时我在想，紧跟技术领域的最新趋势，提升自己的技能是否是我的价值？那么我是技术的主人还是技术的奴隶？人之所以迷茫，是因为找不到工作和生活的重心，感受不到工作或生活的价值。那么什么是价值呢？大一点是我改变了世界，小一点是我所做的改善了某些问题。如果你不知道你的行为、目标和价值观之间的关系，那么你的重点在哪里？我们如何区分重要性和优先级？程序员的迷茫，不仅仅是面对复杂技术的无力感，更重要的是，他们长期埋没在软件世界浩瀚的分工体系中，看不到价值所在从业务到软件架构的链条，无法明确自己在分工系统中的位置，是由于没有处理好自身、技术和业务之间的关系造成的。很多程序员打心底里不喜欢业务。我以前有过这种经历。我宁愿从事框架工具和技术组件研究。我的一个朋友经常跟我抱怨说：“你天天加班，写了那么多代码，然后呢？有什么变化吗？你不是写了一堆垃圾吗？”仔细想想我们经常记在脑子里的生意。这只是逻辑和过程。我们失去的是对业务场景的感受，对用户痛点的体验，对业务发展的思考。这些都是与价值密切相关的部分。我们自然而然地用战术上的勤奋来掩盖战略上的懒惰！那么这样做的后果就是我们把自己局限在流水线的岗位上，阉割了发现商业价值的能力，过分关注新技术对职场竞争力的价值。这就是我们在面对复杂的技术时产生技术学习焦虑的根本原因。业务、技术和软件系统的价值链那么什么是业务？它指的是某种有目的的工作或工作项目。商业的目的是解决人类社会与吃喝住行密切相关的领域问题，包括物质需求和精神需求，使商业活动的主体和受众都受益。通俗地说，业务就是用户的痛点，也是服务商（比如公司）的盈利点。技术是解决问题的工具和手段。例如，为了解决用户随时随地购物的业务问题，程序员利用Web技术构建电子商务APP，当需求升级帮助用户快速购买商品时，程序员利用数据算法等技术手段，构建推荐引擎。如果技术脱离了业务，那么技术的应用就得不到很好的落地，技术的研究也就失去了场景和方向。如果业务与技术分离，那么业务的开发就变得极其昂贵和低效。所以回头想想我们日日夜夜写了那么多代码搭建出来的软件系统。它的价值是多少？说白了就是解决业务问题，所以当你的工作内容对解决业务问题没有带来太大帮助的时候，就应该及时做出调整。那么软件系统如何体现自身的价值呢？在我看来，体现在以下几个方面：业务领域和功能：比如支付宝推出了基于支付领域的转账和收款功能，比如人工智能自动驾驶系统。服务能力：这就像火车站的售票窗口。判断其服务能力的标准是有多少用户同时购票，能否在规定时间内完成购票，能否连续工作7*8小时。对应到软件系统领域，表现在以下三个方面：系统正确性（程序能够正确表达业务流程，没有bug）可用性（可以7*24小时*365不间断工作）大规模（高并发）,高吞吐量)互联网企业借助大型软件系统承载多种业务功能，使其具备庞大的服务能力，利用互联网技术突破空间限制，高效廉价地解决业务问题，创造巨额利润.这是人肉无法比拟的。理解了这一层的概念之后，就可以理解这条价值链：企业依靠软件系统提供业务服务创造价值，程序员通过构建并不断演进软件系统服务能力和业务功能来支撑公司业务发展来创造价值.价值。有了这个价值链，我们就可以反思我们的工作和学习对软件系统服务能力的提升有多大贡献？你可以反省一下自己的工作和学习到底是在实际解决领域内的业务问题，还是只是在做意义不大的重复性工作。两天前我面试了一个候选人。他的工作是开发票务系统。他说他在研究linux内核和汇编语言。我问他linux内核和汇编语言的学习对你的工作有什么帮助。你能给个例子吗？他哑口无言，心里觉得，这么一个爱学习的好苗子，竟然迷失了精神，无法集中注意力，在做一些浪费精力的事情。正确的学习方式应该是将学习与具体的业务场景相结合，通过软件系统为公司业务服务创造价值，程序员通过串联提升软件系统服务能力来创造价值，从而帮助这些价值的实现程度考虑优先事项。学习本身并没有错，错的往往是初衷。现在再看高并发分布式分发相关的知识，你会发现，并不是因为这些知识比较先进、比较时髦，很多公司都有需要学习，而是对价值链做出了实实在在的贡献。Value-DrivenArchitecture谈到软件系统，人们不可避免地会想到架构。之所以在这里讲架构，是因为每个程序员本质上都是软件架构体系的一部分。我们可能深埋在系统管道中，感受不到位置和价值。但是如果从架构的角度来看这些问题，就会很透彻。那么到底什么是建筑？与上述价值链有何关系？什么是建筑？在我看来，软件架构是一种组织人员、技术等资源来解决业务问题、支持业务增长的活动。可能比较抽象，我想我们可以从架构师的一些具体任务中理解这句话的意思：组织业务：架构师通过在业务领域中探索和研究知识，构建自己的业务“世界观”。基于这样的理解，他会拆分业务生命周期，建立业务边界，构建一套领域模型来解决具体的业务问题，并确认模型和领域之间的关系和协作，完成对业务领域的分析。组织工作的要素。组织技术：为了在计算机世界中运行人类社会的商业模式，架构师需要在计算机世界中选择合适的框架、中间件、编程语言、网络协议等技术工具，按照之前的设计方案进行组织，形成一套软件系统解决方案，在我看来，软件系统就像一个技术组织，即技术组件和技术手段按照一定的逻辑组织起来。这些技术工具职责明确，分工明确，以实现业务功能为目标。聚集在一起。比如RPC框架或者消息队列，像信使一样用于内部系统之间的通信服务，而数据库则负责记录结果，更像是文员。组织人员：为了达到使用软件系统解决业务问题的目的，架构师还需要关注软件系统的构建过程。他号召实现软件系统，从公司组织中召集了一批软件工程师，将这些人员分成不同的小组。根据工种、不同的职责、不同的制度来组织，确定这些人员之间的协作方式，注意组织制度是否运转良好，如沟通是否顺畅，产出是否符合要求,能否按时完成。整体组织，对外输出：架构师的首要目标是解决业务问题，促进业务增长。所以他非常关心软件的健康状况。因为只有软件系统运行起来，才能对外提供服务，解决用户接入过程中的业务问题。架构师需要关注运行过程中产生的数据，比如业务成功率、系统运行资源占用数据、用户反馈信息、业务增长等，这些信息将帮助架构师制定下一步的架构目标和方向。因此，软件架构不仅仅是选择什么样的框架，选择什么样的技术组件那么简单。它贯穿于人的组织、技术的组织和业务的组织，并以解决业务问题为目标将这三种组织有机地结合起来。很多面试者在被问及他开发的系统的架构时，只会罗列一些技术组件、技术框架等技术要素，这样看起来根本就没有弄清楚架构的深层含义。也有一些架构师只专注于底层技术的研究，认为构建一个优秀的系统是一件很厉害的事情，却忽略了一个软件系统的价值是由解决业务问题和支持业务的能力来衡量的生长。因此，***出了很多对组织和业务都没有帮助的制度。成本与收益前面提到，软件系统只有在运行中才能创造价值，也就是说，软件系统能否7*24小时*365天稳定工作，关系到公司的收入水平。因此，开发团队对生产环境的发布始终持谨慎态度，总是加班加点解决生产环境的问题。软件系统的成本体现在软件构建过程中。这时候，我们就能明白那些工程技术的价值，比如项目管理、敏捷开发、单元测试、持续集成、持续构建、版本管理等，其中有一些是为了保证软件系统的正确性。有的是为了降低沟通成本，有的是为了提高开发效率等等。但总的来说，都是为了降低软件建设的成本。因此，在提升系统服务能力、创造更多商业效益的同时，降低建设成本也是增加收益的有效手段。作为一名软件工程师，我们往往处于软件构建过程体系的某一点。我们可以基于成本和收益的关系来思考自己每项技能的价值，学习新的有价值的技能，甚至在工作中基于成本和收益的考虑来选择合适的技术。比如在逻辑变化不大的地方，没必要做太多的设计，应用各种花哨的设计模式浪费时间。只有这样，我们才能成为技术的主人。架构目标需要适应业务发展架构的目标是支持业务增长，提高软件系统的服务能力。但话虽如此，实际上要做出很多取舍。比如对于创业团队来说，在他们的产品是否能够解决业务问题的想法还没有得到确认之前，就立马构建了一个高性能、高可用的分布式系统。这样的架构目标远远超出了业务发展的需要。***结果是浪费了大量的人力物力，却毫无起色。架构师需要评估情况并仔细衡量正确性、规模和可用性之间的关系。比如今年生意火爆，日均订单300万。根据对未来可能的预测，明年可能会有3000万的订单。那么架构师应该关注规模和可用性。而且每个点的提升程度也需要架构师衡量，比如可用性应该达到2个9还是3个9。回顾我过去的工作，很多时候是因为没有确立架构目标，导致大量组织资源的浪费。比如在之前的创业团队中，因为自己有一定的代码洁癖，经常会花很多时间和同事一起关心代码质量。上线速度快的功能需要延迟。当时过分追求正确性，与创业团队快速验证想法的业务需求并不匹配。还有一个比较深刻的案例是，我在做技术团队的leader的时候，做工作汇报的时候，leader问我接下来的团队工作有什么计划？当时讲了很多提高代码质量、每天早上开会、任务透明化、建立迭代机制等等，然后被各种批评。当时团队主要是外包人员，人员水平低下，发达的财务体系漏洞百出。该业务线最重要的商业价值是按计划实现潜在投资者的需求，努力招商引资。于是很快领导就叫来测试架构的相关人员和我一起梳理核心功能的测试，把研发、测试、上线的流程自动化。那时候，我不明白做这件事的核心价值是什么。但回过头来看，这种工作方式正好符合业务发展的需要，即保证系统满足设计要求，保证系统达到可接受的正确性，为后续的快速推进打下基础，并且最重要的是，为企业降低了建设成本。所以，程序员想要工作，想要达到性能，就必须认清系统背后的商业价值，根据价值梳理工作重点，而不是像我一样过度纠结于细节，追求技术理想化。正如在程序员的困惑一章中提到的：程序员的困惑长期埋藏在软件世界庞大的分工体系中，看不清从业务到软件架构的价值链。我在分工体系中无法明确定位自己的位置，也处理不好自己与技术和业务的关系，所以想在这里谈谈分工。为了让软件系统更好地为业务服务，架构师必须对软件系统生命周期进行拆分，比如将开发生命周期、测试生命周期、用户访问生命周期、软件运维生命周期分开，并根据不同的生命周期区分职责和角色。例如，开发人员负责开发周期，负责完成软件开发，测试人员负责测试开发人员交付的结果等，这样就形成了分工。分工一旦形成，每一个分工组织都会有自己的价值追求。架构师关注的顶层价值，即软件系统能否支撑业务增长，会以分工的形式分解到各个组织中。劳动分工是有价值的，因为它允许在一个简单、并行和可替换的管道中解决复杂和昂贵的任务。但久而久之，价值碎片化的问题就出现了。比如，测试人员只专注于发现更多的问题，开发人员只专注于快速开发更多的系统，运维人员只专注于保证系统的稳定性。三者往往只站在自己的立场上问对方要做什么，没有人关注整体价值，导致矛盾重重，增加了软件实施的成本。作为流水线的一员，因为被重复性的工作所困扰，对工作的意义感到困惑，他甚至觉得自己作为一个人的创造力和灵感都被扼杀了。于是朋友就抱怨说我说你写了那么多代码然后什么都没做，这是很有道理的。那是因为我只关注做装配工的价值要求，看不到生态链顶端的价值。我们仔细想想那些teamleader，哪个精英leader不负责更广泛的价值，比如项目经理只需要关心自己项目的商业价值，而公司CEO关心的是整体的商业价值公司内部所有业务的价值。因此，关注值越大，地位越高。这些高层领导掌控着整体价值链，及时纠正底层分工组织的价值目标与整体价值目标的偏差。从价值出发——为学习和工作寻找新思路困惑可以引发思维，结构塑造视野，价值是我们生存和工作的逻辑起点。基于这样一种价值思考，对我们的学习和工作有何启示？明确自己的业务相关主题：找出自己协作网络中的业务方和客户方，这样才能从客户方找到离自己最近的业务价值点，更多地挖掘自己业务方的资源。甚至可以利用这个思路沿着网络向上或向下挖掘价值链，整合更多的上下游资源，实现更大的价值。更进一步，为更大的价值负责：不要因为是开发人员就关注软件运维，也不要因为测试就关注软件开发，因为你关注的越多，更多你可以看到整体价值目标。如果你只关注一亩三分地，那你这辈子就注定要困在这三分之一亩地里，成为一个急死在流水线上的码农。试着换个思路，站在架构师的角度去思考价值问题，看看能不能把技术融入到业务中，融入到用户中，融入到最终的价值中。之前朋友说产品经理应该踢到运营位，程序员应该踢到产品经理位。这才是正确的做事方式。这句话也有类似的意思。只有向前迈出一步，才能知道如何做得更好。像建筑师一样思考，用价值找到重心：人因为找不到重心而迷茫，而价值的意义就是引导我们去思考要做什么才能实现价值，做什么先做什么比后做什么会创造更多的利益。像架构师一样全局思考，将遇到的问题拆分，将学到的东西串联起来，力求形成完整的价值链。学会连接，建立系统：前几天看到一篇文章，对今日头条的产品形态极度批判，指责其智能算法将人类封闭在自己的喜好中，进一步分裂了人类社会。这似乎有道理，有趣的是，互联网将我们连接到广阔的世界，同时也将我们封闭在自己的小世界里。还是我朋友说他最大的价值在于联系，把不同的人联系在一起，很快就会有有趣的事情发生。或许算法的本质是服从和迎合，但人要想了解世界，最终还是要靠自己的行动与不同的人建立联系。这也是摆脱流水线束缚的有效途径。另外，我们自己也是某些事物连接的产物，比如架构师，他是业务、技术、管理连接的产物。因此，我们应该建立自己的知识体系，吸收和整合新知识，把孤立的概念联系起来，形成自己的价值链。比如这篇文章结合了我在技术开发方面的经验和我对架构的理解以及我自己过往的经验，这也是一个内部系统回顾。在科技界，您有哪些感悟和经验？欢迎在留言区与我们交流互动。
