技术变化那么快，程序员如何做到不被淘汰？

阿里妹导读：写了这么多年的代码，你是否曾经有过这样的迷茫和困惑——技术发展日新月异，奋力追赶的我们，究竟是技术的主人还是技术的奴隶天，我们邀请到了蚂蚁金服的技术专家空融，一起来聊聊技术人的软件世界观。

所以回过头来我们想想自己没日没夜写了那么多的代码从而构建起来的软件系统，它的价值何在呢白了就是为了解决业务问题，所以当你所从事的工作内容并不能为解决业务问题带来多大帮助的时候，你应该要及时做出调整。那么软件系统又是如何体现它自身的价值呢我看来有如下几个方面的体现：

业务领域与功能：比如支付宝立足支付领域而推出的转账、收款功能等，比如人工智能自动驾驶系统等。

服务能力：这就好比火车站购票窗口，评判它的服务能力的标准就是它能够同时处理多少用户的购票业务，能不能在指定时间内完成购票业务，能不能7*8小时持续工作。对应到软件系统领域，则表现为以下三个方面：

系统正确性(程序能够正确表述业务流程，没有Bug)
可用性（可以7＊24小时＊365不间歇工作）
大规模（高并发，高吞吐量）

互联 公司正是借助大规模的软件系统承载着繁多的业务功能，使其拥有巨大的服务能力并借助互联 技术突破了空间限制，高效低廉解决了业务问题，创造了丰厚的利润，这是人肉所不可比拟的。

理解了这一层面的概念，你就可以清楚这个价值链条：公司依靠软件系统提供业务服务而创造价值，程序员则是通过构建并持续演进软件系统服务能力以及业务功能以支撑公司业务发展从而创造价值。

有了这个价值链条，我们就可以反思自己的工作学习对软件系统的服务能力提升起到了多大的推动作用以反思自己的工作学习是否切实在解决领域的业务问题，还是只是做一些意义不大的重复性工作。

前两天面试了一个候选人，他的工作是从事票务系统开发，他说自己在研究linux内核与汇编语言，我就问他linux内核和汇编语言的学习对你的工作产生了哪些帮助否举一个例子哑口无言，我内心就觉得这样一个热爱学习的好苗子正迷茫找不到重心，正在做一件浪费精力的事情。正确的学习方式应该是将学习与具体业务场景结合起来，和公司通过软件系统开展业务服务而创造价值，程序员通过提升软件系统服务能力创造价值这一链条串接起来，从对这些价值产生帮助的程度去思考优先级。学习本身没有错，错的往往就是那颗初心。

现在你再来看高并发分布式相关的知识，你会发现并不是因为这些知识比较高深、比较时髦，很多公司有需求才值得学习，而是他们对价值链条有着实实在在的贡献。

价值驱动的架构

一谈到软件系统，人们免不了想起架构这件事来。之所以此处去谈及架构是因为每一个程序员本质都是软件架构体系中的一分子，我们可能深埋于体系流水线之中，感受不到位置和价值。但如果站在架构这一高度去看这些问题则将会非常透彻。那么架构究竟是什么上述的价值链又有什么关系呢/p>

什么是架构/p>

在我看来软件架构就是将人员、技术等资源组织起来以解决业务问题，支撑业务增长的一种活动。可能比较抽象，我想我们可以从架构师的一些具体工作任务来理解这句话含义：

组织业务：架构师通过探索和研究业务领域的知识，构建自身看待业务的”世界观”。他会基于这种认识拆分业务生命周期，确立业务边界，构建出了一套解决特定业务问题的领域模型，并且确认模型之间、领域之间的关系与协作方式，完成了对业务领域内的要素的组织工作。

组织技术：为了能在计算机世界中运作人类 会的业务模型，架构师需要选用计算机世界中合适的框架、中间件、编程语言、 络协议等技术工具依据之前设计方案组织起来形成一套软件系统方案，在我看来软件系统就像是一种技术组织，即技术组件、技术手段依据某种逻辑被组织起来了，这些技术工具被确定了职责，有了明确分工，并以实现业务功能为目标集合在了一起。比如RPC框架或消息队列被用于内部系统之间的通信服务就如同信使一般，而数据库则负责记录结果，它更像是一名书记员。

正如之前所说软件系统只有在运行的时候才能创造价值，也就是说软件系统能否7*24小时＊365天稳定的工作关系到公司的收益水平。所以开发团队对生产环境的发布总是小心翼翼，对解决生产环境的问题总是加班加点。而软件系统的成本则体现在软件构建过程，这时候我们就能理解那些工程技术如项目管理、敏捷开发、单元测试、持续集成、持续构建，版本管理等的价值了，他们有的是保证软件系统正确性，有的是为了降低沟通成本，有的是为了提升开发效率等但总的来说就是为了降低软件的构建成本。所以在提升系统服务能力，创造更多业务收益的同时，降低构建成本也是一种提升收益的有效手段。

作为一名软件工程师而言，我们往往处在软件构建过程体系中的某个环节，我们可以基于成本与收益的关系去思考自己每一项技能的价值，学习新的有价值的技能，甚至在工作中基于成本与收益的考量选择合适的技术。比如在逻辑不大发生变化的地方，没有必要去做过多的设计，应用各种花俏的设计模式等浪费时间。这样我们才能成为技术的主人。

架构目标需要适应业务的发展

架构的目标就是为了支撑业务增长，就是提升软件系统的服务能力。可是话虽说如此，但真实却要做很多取舍。比如对初创团队而言，其产品是否解决业务问题这一设想还没得到确认，就立即去构造一个高性能、高可用的分布式系统，这样的架构目标远超出业务发展的需求，最后的结果就是浪费大量人力物力，却得不到任何起色。架构师需要审时度势，仔细衡量正确性、大规模、可用性三者的关系，比如今年业务蓬勃发展日均订单300万，基于对未来的可能预测，明年可能有3000万的订单，那么架构师应该要着重考虑大规模和可用性。而且每一点提升的程度，也需要架构师衡量把握，比如可用性要达到2个9还是3个9。

回顾自己以往的工作很多时候就是因为没有确立架构目标导致浪费了组织很多资源，比如在之前的创业团队中，由于本人有一定的代码洁癖，经常会花费很多时间和同事计较代码质量，这样本可以更快上线的功能却需要被延迟，当时过度追求正确性的行为是与创业团队快速验证想法的业务需求不匹配的。

另外一点比较深刻的案例则是在本人担任一个技术团队负责人的时候，在一次述职 告的时候，leader问我对接下来团队工作有什么计划当时说了一堆什么改进代码质量，每天晨会，任务透明化，建立迭代机制等等，然后就被各种批驳一通。当时团队基本以外包人员为主，人员水平较差，开发出来的金融系统也是千疮百孔而这条业务线最重要的业务价值则是按计划实现潜在投资方的需求，争取拉到投资。所以不久leader就召集测试架构的相关人员与我这边一同梳理对核心功能的测试工作，将研发、测试、上线的流程自动化。

当时并不理解这样做核心价值是什么。但回过头来看这样的工作方式恰好符合了业务发展的需求，即确保系统是符合设计需求的，保证系统达到可接受的正确性，为后续能过快速前进打下基础，最重要的是为企业降低了构建成本。所以程序员想要工作出业绩，必须认清楚系统背后的业务价值，按价值去梳理工作优先级，而不是像我一般过度纠结细节，追求技术理想化。

成也分工，败也分工

正如在程序员的迷茫那一章节提到的：程序员的迷茫因为长期埋没于软件世界的浩大的分工体系中，无法看清从业务到软件架构的价值链条，无法清楚定位自己在分工体系的位置，处理不好自身与技术、业务的关系所致，所以在这里我想谈谈分工。架构师为了使软件系统更好的服务业务，必然将软件系统生命周期进行拆分，比如分出开发生命周期、测试生命周期、用户访问生命周期、软件运维生命周期，并根据不同的生命周期划分出不同的职责与角色。

像架构师一样思考，用价值找寻重心：人的迷茫是因为找不到重心，而价值的意义在于引导我们思考做哪些事情才能实现价值，先做哪些事情会比后做哪些事情更能创造收益。像架构师那样全局性思考，把遇到问题进行拆分，把学习到的事物串联起来，努力构成完整的价值链条。

学会连接，构建体系：前几天看到一篇文章对今日头条的产品形态极尽批判之词，指责它的智能算法将人类封死在自己的喜好之中，将人类 会进一步碎片化。这似乎很有道理，有趣的是互联 将我们连接至广袤的世界，却也把我们封闭在独属于自己的小世界里。依旧是我的那位朋友，他说他的最大价值在于连接，将不同的人连接在一起，有趣的事情可能就会即将发生。

或许算法的天性就是顺从与迎合，但人最终想理解这个世界还是需要依靠自身的行动与不同人之间建立联系，这也是一种摆脱流水线限制的有效方式。另外，我们自身也是某种事物连接的产物，比如架构师，他是业务、技术、管理连接在一起的一种产物。所以我们应当树立自身的知识体系以吸收融合新知识，将孤立的概念连接起来，形成自身的价值链条。比如这篇文章将我从事技术开发经验、与对架构的理解以及自身过往经历结合起来，这也是一种内在的体系梳理。

在技术的世界里，你又有哪些感悟和体会呢迎在留言区与我们一起交流互动。