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

在浩大的软件世界里，作为一名普通程序员，显得十分渺小，甚至会感到迷茫。我们内心崇拜技术，却也对日新月异的技术抱有深深的恐惧。有时候我会思考难道在技术领域内不断紧跟新潮，不断提升技能就是我的价值所在?那么我是技术的主人还是技术的奴隶?

人之所以迷茫往往是找不到工作生活的重心，感受不到工作或生活的价值。那么什么是价值呢?说的大一点就是我改变了世界，说的小一点就是我的所作所为改善了某些问题。如果不清楚自己的行为、目标、价值三者的关系，那么又何来重心?又如何能分得清重要性与优先级呢?

程序员的迷茫不仅仅是面对技术繁杂的无力感，更重要的是因为长期埋没于软件世界的浩大的分工体系中，无法看清从业务到软件架构的价值链条，无法清楚定位自己在分工体系的位置，处理不好自身与技术、业务的关系所致。

很多程序员打心底不喜欢业务，这一点我曾经也经历过，我更宁愿从事框架工具、技术组件研究的相关事情。我有个朋友经常吐槽我说："你们天天加班加点写了那么多代码，然后呢?有改变什么吗?还不是写出了一堆垃圾。"仔细想想很多时候业务在我们脑海中存留的只是逻辑和流程，我们丢失的是对业务场景的感受，对用户痛点的体会，对业务发展的思考。这些都是与价值紧密相关的部分。我们很自然的用战术的勤快掩盖战略的懒惰!那么这样的后果就是我们把自己限死在流水线的工位上，阉割了自己能够发现业务价值的能力，而过多关注新技术对职场竞争力的价值。这也就是我们面对繁杂技术，而产生技术学习焦虑症的根本原因。

业务、技术与软件系统的价值链

那么什么是业务呢?就是指某种有目的的工作或工作项目，业务的目的就是解决人类社会与吃喝住行息息相关的领域问题，包括物质的需求和精神的需求，使开展业务活动的主体和受众都能得到利益。通俗的讲业务就是用户的痛点，是业务提供方(比如公司)的盈利点。而技术则是解决问题的工具和手段。比如为了解决用户随时随地购物的业务问题时，程序员利用web技术构建电子商务App，而当需求升级为帮助用户快速选购商品时，程序员会利用数据算法等技术手段构建推荐引擎。技术如果脱离了业务，那么技术应用就无法很好的落地，技术的研究也将失去场景和方向。而业务脱离了技术，那么业务的开展就变得极其昂贵和低效。

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

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

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

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

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

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

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

前两天面试了一个候选人，他的工作是从事票务系统开发，他说自己在研究linux内核与汇编语言，我就问他linux内核和汇编语言的学习对你的工作产生了哪些帮助?

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

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

价值驱动的架构

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

什么是架构?

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

组织人员：为了能够实现利用软件系统解决业务问题的目标，架构师还需要关注软件系统的构建过程，他以实现软件系统为号召，从公司组织中聚集一批软件工程师，并将这些人员按不同工种、不同职责、不同系统进行组织，确定这些人员之间的协作方式，并关注这个组织系统是否运作良好比如沟通是否顺畅、产出是否达到要求、能否按时间完成等。

组织全局，对外输出：架构师的首要目标是解决业务问题，推动业务增长。所以他非常关心软件的运行状况。因为只有在软件系统运行起来后，才能对外提供服务，才能在用户访问的过程中，解决业务问题。架构师需要关注运行过程中产生的数据比如业务成功率，系统运行资源占用数据、用户反馈信息、业务增长情况等，这些信息将会帮助架构师制定下一步架构目标和方向。

所以软件架构不仅仅只是选用什么框架、选用什么技术组件这么简单。它贯穿了对人的组织、对技术的组织、对业务的组织，并将这三种组织以解决业务问题这一目标有机的结合在了一起。

很多面试的候选人在被问及他所开发的系统采用什么架构的问题时，只会罗列出一些技术组件、技术框架等技术要素，这样看来其根本没有理清架构的深层含义。也有一些架构师只专注对底层技术的研究，以为打造一个卓越的系统是非常牛逼的事情，可是他忽略了软件系统的价值是以解决业务问题的能力、支撑业务增长的能力为衡量标准，所以最后生产出了很多对组织，对业务没有帮助的系统。

成本与收益

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

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

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

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

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

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

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

成也分工，败也分工

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

比如开发人员负责开发周期负责完成软件研发，测试人员负责对开发人员交付的成果进行测试等，于是就形成了分工。一旦分工形成，每一个分工组织都会有自己的价值追求，架构师关注的顶层的价值即软件系统能否支撑业务增长被分工的形式打碎到各个组织中。分工是有其价值的，他使得复杂昂贵的任务可以被简单、并行、可替换的流水线方式解决。

但久而久之，价值碎片化的问题就出现了，比如测试人员只关注找出更多问题，开发人员只关注快速开发更多的系统，运维人员只关注保障系统稳定。

三者之间常常都只站在自己的立场去要求对方怎么做，没有人再关注整体价值，产生诸多矛盾增加软件实施成本。而身处流水线中的一员，又因为困扰于重复性工作，迷茫于工作的意义，甚至感觉自己做为了人的创意与灵感都被扼杀了。所以我的朋友吐槽我说你写了那么多代码然后并没有怎么样是非常有道理的，那是因为我只关注着做为流水工人的价值要求，看不到生态链最顶端的价值。

我们仔细想想那些团队领导，精英领袖哪一个不是为着更广大的价值所负责，比如项目经理只需要关心自身项目的商业价值，而公司CEO则关心公司范畴内所有业务的总体商业价值。所以关注的价值越大且职位也就越高。这些高层领导者们把控着整体的价值链条，及时纠正底层分工组织的价值目标与整体价值目标出现偏差的问题。

从价值出发-找寻学习与工作的新思路

迷茫能引发思考，架构则塑造了视野，而价值则是我们之所以存活，之所以工作的逻辑起点。基于这样一种价值思维，对我们的学习和工作又可以有哪些改启示呢?

明确自身的业务相关主体：找出你工作的协作关系网内的业务方和客户方，这样你就可以从客户方中找到离你最近的业务价值点，从你的业务方中挖掘更多的资源。甚至你可以按这个思路顺着网络向上或向下挖掘价值链条，整合更多的上下游资源以实现更大的价值。

向前一步，为更大的价值负责：不要因为自己是开发人员就不去关注软件运维，不要因为只是测试就不关注软件开发，因为你关注的越多你越能看清全局的价值目标。如果只关注一亩三分地，那么注定这辈子只能困守在这一亩三分地里，成为一名流水线上焦虑至死的码农。试着转变思维，从架构师的角度思考价值问题，看看能否将技术贯穿到业务、到用户、到最终的价值去。之前我的朋友说过要把产品经理踢到运营位置去，把程序员踢到产品经理位置去，这样才是正确做事方式。这句话也是类似的意思，向前一步才能懂得怎么做的更好。

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

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

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

【星霜荏苒】 - 程序员如何在技术浪潮的更迭中保持较高的成长速度 ？

题记

作为技术人，到年底都会进行一次自我反思或者总结，回过头来看看这一年自己成长了多少。笔者也不例外，同样打算从 2017 年开始记录自己的年终总结。虽然这种总结的文章不算纯技术文章，但是为了避免记流水账，所以想尽脑汁想以一种新颖的方式展现在读者面前。于是打算用一个大家比较关心的问题来贯穿全文。不出意外，以后每年的形式都会如此。一年一个宏观的问题。文章中的经历保证都是笔者百分之百亲生经历的，有成功的案例也有失败的案例，当然读者自身的情况也会与笔者不同，各位读者可以根据自身的情况来取长补短。文章中的一些观点仅代表笔者个人的一些看法，如有不妥，欢迎提出来一起讨论和批判。

笔者在网上的中文笔名是“一缕殇流化隐半边冰霜”，常常被人简称为“冰霜”、“霜菜”、“霜”。这一年一篇的年度文章既然这么特别，那么就给这个系列文章取一个特别的名字吧。在中国的文化中，四个字的成语读起来能更加有内涵，成语里面也必须带“霜”字和光阴意思，通过大量的搜寻以后，就定下了这个系列的标题的名字 —— 星霜荏苒。

【解释】星霜：星辰运转一年一次循环，每年秋季始降霜，因以批岁月。指岁月渐渐流逝。

【出处】唐·温庭筠《寄崔先生》：“星霜荏苒无音信，烟水微茫变姓名。”

好了，本系列的文章该说明的地方都说明完了，以后每年就不做此说明了。正文正式开始。

技术更迭是有加速度的

从 2010 年开始，被定义为移动互联网的元年，移动开发也是从这一年开始逐渐开始火爆的。笔者也是从毕业之后加入这个浪潮的。据说移动开发火爆之时，理发师通过几个月培训以后也可以拿到月薪1，2W的薪水，可见那个时候对移动人才的饥渴程度。但是到了 2014 年底开始，移动开发的入职要求回归理性，要求逐渐提高，到现在基本大公司社招也不再招高级以下的移动开发了。面试当然也比之前几年难度提高了不少。BAT 的面试可能会考察前沿技术，热修复和跨平台，底层技术，LLVM + Clang ，基础技术，WebKit 和 JSCore 。身边一部分 iOS 开发也逐渐开发转写 JavaScript 了。国内 iOS 开发者也可能会觉得大前端时代的到来，对自己技术的冲击。（当然国外的 iOS 开发者对这些并不感冒，国外的玩法还是原生开发。）继续回到国内的行情，当大前端的一些东西逐渐吞噬 iOS 开发者的开发领域的时候，也许还没有等大家熟悉或者精通前端各种框架的时候，这时 AI 又出现在大家视野中了。机器学习，深度学习一大堆的概念如潮水般涌来。

2012 年底到 2013 年初，有大批创业公司如雨后春笋般的出生。到了 2014 年底，也有大批的公司没有活过那年的冬天。到了今年 2017 年，依旧有大批的创业公司出生又倒下，如各个单车公司。在资本的市场里就是如此的残酷。

周围的一些同事也有出现焦虑的，说实话，我也焦虑过。风口技术恨不得一年一变。年初的区块链和三大前端框架可能还没有玩转，年底立即就被 AI 又碾压一波。一位前端大神这样和我解释到，“技术就需要时刻的跟着，前端如果几个月不跟新技术，看到新技术可能会陌生。如果守着老技术几年不变，呵呵，可能再了解新技术的时候，前端框架已经换了新天地了。”也许这个回答带有一些夸张成分，但是从侧面也能看出前端这几年的发展速度之快。

大家也可以回想一下近几年技术的更迭，也许也能感受到，技术更迭是有加速度的。

焦虑的起源？

我还是以 iOS 开发者来举例。常常会在 iOS 开发者群里出现的 3 个图。

一个是 iOS 开发没人要了和 iOS 开发又有人要了。这 2 幅图常常被作为一个梗出现在各个讨论群中。原因为何？因为 iOS 开发的一部分需求被前端开发者承担了。国内很多小公司招聘要求上也直接写的要求会 JS 、RN、Weex 等技术。直接导致不会 JS 的 iOS 开发就没人要了。每每苹果对跨平台或者热修复进行“封杀”或者任何举措的时候，原生开发都会刷一波 iOS 又有人要了的表情。前端也许同样会有焦虑，焦虑也许来自于对三大框架的掌握程度，如果只精通一个框架，找工作遇到了精通三大框架的人也会心虚。

这也是焦虑来源之一，不会某些知识点会导致找不到工作或者找不到好工作。

另外一个焦虑可能就来自于“倒灌”吧？

每年风口技术变化极快。比如今年 AI 技术之火爆，直接导致的情况是应届毕业生拿到 AI 的 offer 以后，薪水直接无情的秒杀工作2-3年的人。工作2-3年的人就算一直跟这些新技术，也会感觉到压力。所以也就有了上面的第二张图，求你别学了，我们跟不上。

毕竟很少有人能保证每天有大块的时间都在学习新技术，除去完成公司的工作以外，加上可能的加班时间，人回家也会疲劳，也需要休息。每天都有大块的时间用来学习新技术的时间也就不是很多。

人与人学习的速度和掌握的程度也都不同，经过相互比较以后，就会发现自己比别人学的慢学的少，如果这样强行比较，确实也会产生自己不如别人的焦虑感。

如何高效学习？

面对技术的更迭之快，我们应该如何高效的学习保持竞争力不被淘汰呢？这块笔者经历了近 10 个多月的成长以后，对这个问题有一定的发言权了。请听我把我的这一年的经历和心得体会慢慢道来。

我先从心理上谈起，最后谈到我的学习方法。按照这个思路来，希望能让读者能有所收益。

1. 正确看待焦虑和迷茫

程序员一旦焦虑或者迷茫以后，就会对成就感的获得大大降低。长久这样就会导致动力不足。但是现实产生焦虑的原因经过前面的分析，也是客观存在的。那我们应该如何面对呢？

我是这样面对的。

在技术的更迭变化过程中，如果一味的跟新技术，那你是否想过，追随新技术的到底是为了什么？是为了跳槽或者转岗？还是为了提高薪资实现人生理想和自我价值？这两个理由都是正确的，需要注意的一点就是不要盲目追随新技术。一味地盲目追随只会导致最终沦为技术的奴隶。我们需要做技术的主人，更加从容的面对技术的变更。

如何选择？如果在不转岗的情况下，在没有目标的情况下，去学习一些本职工作中可能用不到的知识，可能就有点“盲目”。这些知识学习的过程中也许不够高效。不高效的学习又遇到了别人高速的成长，一比较，新的焦虑又会产生。这里我有切身的体会。

以下是我本人的失败的案例，与君分享。

在今年7月份的时候，我买了一本 Haskell 的书，打算研究研究这个函数式编程的鼻祖。也是接触了 FP 以后，对 Haskell 产生的浓厚的兴趣。我选择点 Haskell 技能点完全就是为了兴趣。工作中也基本不用（可以说是完全不用）。转岗也是完全不可能的，如果去拉钩等招聘网站上面搜“ Haskell 开发工程师”，心里会凉凉，国内一个对应的岗位都没有。（国外是有一些，但是也非常少）。我买的是下面这本书：

电子书我看了这本

书上写的打不倒的空气人，学不会的 Haskell。我学习 Haskell 进度很慢，因为确实实践的机会太少了。看完书确实对 FP 的理解上了一层，但是用它来开发的机会就很少。Haskell 是一门很好的语言，但是我学习它的曲线确实太痛苦了。中间走了很多弯路。（弯路，错误的路线就不分享了）后来组长和我说了一些话，他认为不经过大量实践的学习是低效的。事实证明我学习 Haskell 确实是低效了。我没有大量的实践。学是学了，只不过进步速度非常慢。收获也有，但是挫败感也不少。打不倒的空气人，我没有被打倒，明年有空再继续学。

学习永远没有错，错的是选择了低效耗时耗精力的前进方向。

这里笔者的建议还是优先学习公司项目里面用到的知识，深挖技术痛点。有多余的时间再去横向了解其他的。和 T 型人才一样，先专一门，再扩宽广度。先广度没有深度就会导致你连工作都找不到。

再说说迷茫，迷茫的来源有二个，一是看不到自己对公司的价值，二是看不到自己未来发展的路。

先说迷茫的来源一，看不到自身的价值。很多人每天在公司写业务，俗称“搬砖”，每天都搬，感觉一点长进都没有。回过头来看框架部门的人或者自己部门的研究员，每天都在研究或者做一些框架或者工具。当有大量的人使用的时候，就会很有成就感。并且认为业务没啥技术含量，业务里面的逻辑和流程在换了一家公司以后就没有任何优势了。这种想法其实是不对的，是错误的片面的。如何正确的认识和改变这种想法在下一节里面会更加详细的讨论。

再谈谈迷茫的来源二，看不到未来的路在何方。这个迷茫我觉得来自于对自身的定位不明确。一位老师和我说过，毕业后的头5年，你可以去选择各种开发，前端后端或者移动端，可以随便选。这是为了什么呢？就是为了找到自己感兴趣的和自己的长处并且打算一辈子一直做下去的方向。如果你还看不到自己未来发展的路，那么可以考虑把眼界放的更广一点，去找寻自己真正感兴趣的方向。所谓真正感兴趣的，是指如同熬夜打游戏一样毫不困倦，如果某个方向你能做到不是公司强迫你加班，自己写代码写到深夜或者通宵也毫不厌倦，那么这一定是你感兴趣的。方向一旦确定就不会迷茫，朝着目标狂奔吧。

2. 业务和架构如何选择？

程序员里面也许会存着这样的鄙视链，写架构的鄙视写业务的。这种鄙视是有失偏颇的。

首先，绝大多数的公司的收入来源是来自于公司的业务。除去一些极少数的公司。写业务的同学不必觉得业务没有存在价值，你们应该明白，你们写的业务是替公司赚钱的。

当然，能在公司里面写内部框架或者工具的同学，技术一定积累到一定深度了。框架和工具没有平白无故的产生，它们的诞生都是解决问题或者痛点的。要么解决开发中的痛点，要么为了提高开发效率。试问如果没有对开发有一定的了解和认识，如何去深刻的理解和感受这些痛点？不理解它们，也做不出能解决问题的框架或者有用或者好用的工具。

我认为能写框架或者工具的，一定在技术上有一定积累，并且能理解和看清开发中或者业务中的一些痛点。于是乎开发出了解决这些问题的东西。

至少目前国内的大多数公司都是无法缺少写业务的。小公司为了生存可以缺少写框架和工具的，但是不能缺少写业务的。大公司更加是需要写业务的。目前国内好像还不存在不写业务的公司。如果纯写框架或者工具给其他公司使用，以此赚钱，那么这些也就成为了这个公司的业务。

再谈谈对架构师或者更高级的职称的理解。

在我们的 BU 里面专门有一个架构组，里面的人全是 P7 架构师以上级别。他们的工作内容是什么呢？就是提供能解决当前开发痛点方案的人。我与他们交流过，他们虽然对业务没有理解到每行代码逐字逐句的代码行，但是对公司整个业务流程，数据流转，有一个整体的认识。他们对业务的认识更加深刻，比我们只负责单一业务理解层次更广。他们在此基础上还能解决开发中的难点和痛点，对 BU 部门的业务发展还能提供自己的思考。架构师们还具有自主发现业务价值的能力。

也许大家会认为架构师不写代码，但是他们需要出解决方案。解决方案一定程度上比写代码还要难。解决方案的灵感来源于什么？来源于对公司业务的深刻理解和技术的深厚积累。缺少对业务的理解，提出的方案可能就是不完全适合这个公司的。缺少对技术的深厚积累，提出的方案性能可能就不是最好的。

我觉得大家不要藐视写业务这一环。如果你在公司是写业务的程序员，请不要放弃自己。公司把一个业务交给你，你是否能按时高效的交付是你当前需要考虑的问题。当你对当前业务玩的很溜了，对这块有深刻理解了。可以再去考虑理解去理解你所在的产品线，这一条业务线的流程。在理解流程的同时去考虑当前公司的架构设计为何如此设计？有什么优点有什么缺点？哪些能改哪些不能改，哪些是历史遗留问题造成的？

只有这样日积月累的积累，当你积累了大量业务经验，以及大量业务场景下优秀合理的架构设计以后，你就能向着架构师的方向前进了。

我坚信一点，公司花钱雇一个架构师来工作，工作的职责一定是替公司设计并完成架构方面的一些事情。俗话也说，没有最好的架构只有最适合的架构。架构师的价值就在于此，在深刻了解公司业务需求以后，针对公司的业务，量身定制一套最好最适合的架构。

在公司里面，我的工位旁边坐了一位 P8 高级算法专家，在我不知道他的职称之前，我观察到他平时的工作内容就是把各种算法落地，切实的解决公司里面的痛点和开发难点。每每有产品或者开发来问他某个逻辑时，他都能了如指掌。我一度以为问的逻辑都是他参与开发的。直到之后我知道他的职称以后，更加感受到算法专家的价值所在。

在非学术工业生产中，算法专家的价值在于利用各种算法来解决公司中各种业务痛点。我看到他就用了各种图论算法加上机器学习解决实际生产中智能调度的问题。对他所负责的业务了解之深刻。（当然，在学术研究中，算法专家的价值应该是在于创造或者改进算法效率吧）

在 iOS 领域，大家也都认识迪哥，迪哥就是架构师，和迪哥交流之后，迪哥的日常工作内容是对部门人员的组织，对技术选型的决策，对业务的组织，对架构的方案，所以我认为架构师的工作是以解决业务问题，推动业务增长为基础，在此之上改善公司的架构，使之能对外提供更加优秀的性能，并具有对人、技术、业务的组织统筹能力。

一个好的产品，一定是能完美解决用户痛点的。如何理解和发现业务的价值也是一种能力。至少这种能力是架构师必备的能力。我目前也在业务中修炼，在深刻理解公司的业务的同时，也在考虑如何设计架构，为何要这样设计，有没有更好的设计？我不能说我以后一定会成为架构师，但是至少我认为我在朝着架构师的方向努力着。

3. 技术分工的不同和统一

笔者今年前端和后端都有涉及。前端算是离用户最近的一端。而且现在处于大前端时代，大家可能会发现前端能干的活越来越多了，往前，可以涉及到客户端，往后可以涉及到 Nginx。前端工程师的技术栈也变得非常广阔。后端工程师反而会显得没有前端那么忙碌了。

前端的数据来源来自后端，前端更加偏重 UI，交互，设计。后端更加偏重接口性能，数据的正确性。但是随着云基础设施的逐渐完善，后端的基础设施都挪到云上了，这部分的配置和管理都变得异常的轻松，这一切都交给云了。

现在前端框架和浏览器发展的突飞猛进，业务上一部分逻辑都直接在前端做掉了，即使现在前后端分离，前端在公司中承担了越来越多的角色了。有这样一个笑话：大前端工程师对后端工程师说，你们后端不就是一个写接口的嘛，吐吐字符串。后端工程师对大前端的工程师说，你们前端不就是搭搭页面嘛，前端就是一段漂亮的字符串。虽然他们说的都不准确，但是也从侧面抽象了他们工作的内容。

所以前端和后端分工不同，但是他们还是合作的关系，缺一不可。

在 Airbnb 女博士朱赟的小密圈里看到一个问答

提问：作为一个后端开发，想请教安姐，如何去提高自己的驾驭复杂业务逻辑的能力、设计能力和抽象能力？如果接手一个稳定性不够好的系统，如何收敛复杂度，逐步提高稳定性？

朱赟老师非常干练和漂亮的给出了这个答案:

驾驭首先要做到通晓。了解所有业务逻辑的来龙去脉，知道一些典型系统设计方案以及其针对的问题，还有优劣比较。接触过一些实际的系统。在此之上，才有可能把合适的设计套用到当前的业务逻辑上，把现有的业务逻辑抽象成一个已经存在（部分）解决方案，或更经典的方式。

接手一个稳定性不好的系统，如果没有足够的时间从头设计、完全重构。那么至少要知道影响稳定性的几个关键要素，然后根据重要性、紧急性和解决问题需要的资源（时间、技能集、人等）进行优先级排序，逐个击破。对于所有的改善型动作，确保有适合的评测和监控，这样能够知道不同的措施效果到底是怎么样的。

结合之前我们讨论的架构和业务的关系，同样也是统一的。不管是前端还是后端，不管是业务还是架构，这些分工的最终目标都是同一个：让技术推动业务增长，实现公司盈利翻倍。写框架或者工具的同学写出更好的框架和工具提高开发效率，写业务的同学利用技术让业务稳定性和逻辑更加稳定可靠。最终的目的都是为了推动公司的业务增长。我认为看到了这一点，就能认清自己在公司里的价值。在找到自我价值和实现公司价值的时候，就不太容易迷茫，成就感的获得会更加容易。

4. 高效的学习方法

讲到此，我就用我今年一年的经历来谈谈我认为高效的学习方法是怎么样的。顺带也总结一下今年一年我的工作内容和收获。大概为了3个阶段。

第一阶段，iOS 阶段

我是今年2月份，年后来到这里的。来到公司以后交给我第一个的任务就是解决项目中和内存泄露相关的问题。因为项目里面都是用的 RAC ，这块组里的同学对它里面原理理解不够深刻，很容易写出内存泄露的代码。我来了以后就把组里的所有和内存泄露相关的问题都找出来。之后组里又开始了组件化的工作，于是我又开始了研究并实现适合组内使用的路由方案。

后来公司内部在推跨平台方案——Weex。我也很荣幸的被指派了研究这块内容。从阅读源码中，我也学到了很多很多。到这里就到今年5月份了。

第二阶段，前端阶段

6月份以后，组里接了一个新活，我也主动申请了去写这个活的前端页面。由于在了解了 Weex 以后，顺水推舟的就选择了 Vue 这个框架。于是开始写 Vue 相关的项目了。

在短短2个多月的项目迭代中，我学到了很多东西。公司内部的各种脚手架用法，前端开发流程，前端页面埋点，前端发布流程，前端的项目持续集成，页面性能监控 APM ，前端工程化，组件化... 这些在 iOS 中同样都是存在的，但是我就用了几个迭代就都接触了。同期的相比其他同学开始说学习前端，我的进度是比较“神速”的，至少我在整套都学习完成以后，他还在摸索 JS 过程中。

虽然我现在前端的资历还很浅，但是当个 P4 写写基本的业务迭代还是可以胜任的。我也深深的知道，前端的内容非常多，仅仅几个月只是一个皮毛中的皮毛。但是至少让我体验了一把前端开发中的日常。

我认为我前端这块学习是高效的。为何高效？因为我是在实践中学习的。利用公司真实的项目锻炼自己，真的学习特别高效。每天项目中遇到的问题，上下班在地铁上都会很有目的的在网上查询解决办法。学习目的非常明确。我比每天看语法的不实践的同学进步要快很多。

关于前端入门，我可以提供一下我的路线。

首先当然是了解 JavaScript 和 Css。入门方法还是看书。我看了一下这些书：

《JavaScript 权威指南(第6版)》
《JavaScript 高级程序设计（第3版）》
《JavaScript DOM 编程艺术第二版》
《ES6标准入门（第二版）》
《Effective JavaScript 编写高质量 JavaScript 代码的 68 个有效方法》
《Speaking JavaScript》
《你不知道的 JavaScript 上卷》
《你不知道的 JavaScript 中卷》

之后就是大量的实战项目训练了。参与公司业务迭代的“蹂躏”，很快能学会很多东西。几个迭代下来就能玩通整个流程。

当然我为了加强训练的抢断，自己在 Github 上也练习。当时对 Electron 框架也非常感兴趣，就写了这个开源项目Vue 全家桶 + Electron 开发的一个跨三端的应用。

除此之外在公司内部还认了3个师父，把我前端技术带着飞。一个是知乎前端大V，@敖天羽，这个妹子的 title 非常多，饿了么前端吉祥物，天哥，天尊……数不清，她一毕业就在前端的架构组工作，能力非常强。再次我也感谢一下她对我这种入门级小白的问题耐心的解答。在成长的路上解答了很多问题。（这里也可以安利一波妹子在知乎上开了 Live ，对前端前进路线迷茫的同学可以去听听，一定能解答你的一些疑惑）

另外一个师父是和我同一天入职的朋朋，他也是前端开发，技术非常强。我和他关系也非常好。平时有前端的问题也会问他。

最后一个师父是我大学同寝室的，前端也很厉害，不懂的问题也会向他请教。

在此也感谢上面3个师父的答疑解惑，把前端未入门的小白 carry fly 了。

小结一下这段前端学习，大量的项目实践 + 主动有目的的看书学习 + 有大神指点 = 高效的学习。

第三阶段，Go 阶段

7月份跟着组长一起转写后端业务了。短短几个月，成长也非常迅速。Go 的基本用法都很了解了。我的 Go 的学习成长路线也总结记录了，感兴趣的同学可以看这篇文章《Go 初学者的成长之路》，这里就不再赘述了。

转写后端业务以后，语言关不是多大问题，感觉比较头疼的就是后端的整个生态体系。东西多的如潮水般将我淹没。

我们组负责的业务都和地理位置有关。所以我把空间搜索这块进行了深刻的研究。所有的研究成果也写成了文章放在了这里《空间搜索文章集合》。

参与的项目迭代至今，所有的后端开发流程，Thrift RPC 框架 nex，Docker，k8s，ELK日志，Redis，Huskar SOA 配置，GoProxy 配置，ETrace 监控，MaxQ 延迟消息队列，Eless 发布，Workflow 工作流，PostgreSQL 使用，Google S2……这些基本使用都掌握了。眼看着自己开发的服务 QPS 逐渐成长，心里就比较有成就感。这个项目就像自己的孩子一样，疼爱有佳。

除了自己看书学习以外，项目中遇到各种技术问题也都是组长和组员替我答疑。也是带我飞的节奏。如果自己学习，自己摸索，要想掌握上面的这么多东西，不知道要多久才能弄懂。

小结一下这段后端学习，同样也是，大量的项目实践 + 主动有目的的看书学习 + 有大神指点 = 高效的学习。

以上的这些经历就是比较成功的经历，相比 Haskell 的学习，明显进步“神速”，在解决公司项目痛点的同时，也快速学习提高了大量的知识。回想起组长之前说的，在公司的项目里面去实践是成长最快的。我也利用了一年的时间验证了这句话真实性。

5. 总结

程序员如何在技术浪潮的更迭中保持较高的成长速度 ？我的答案就是在公司的项目里面去实践是成长最快的。首先业务的迭代排期会让你的学习不拖拉，在排期中必须要完成指定的任务，这对学习进度有了非常好的保证。其次，实际项目中的实践能让你对语言的熟练程度，语言的生态环境，开发过程，查找 bug 流程，监控各个方面都有实践经验。而且实际项目中还能让你遇到各式各样的坑，坑踩多了就成长了。正确的学习方式也应该是将学习与具体业务场景结合起来，帮助公司利用自己掌握的技术开展业务服务而创造价值。如此看来，这样的成长一定是最快的。

有一位计算机的大神建议程序员每年成长的速度至少是一年多学习一门陌生的语言。从今年的结果来看，我是完成了。

程序员在从业几年以后，视野不应该仅仅局限在自己的开发语言中。可以超脱开发语言，放开视野，从更高层次去想想问题。当然笔者以上的这些思考在水平更高的人看来也许水平一般。水平更高的人也一定是这样一步步的走过来，直到最后能指点江山，他们的想法能对整个行业产生影响。以上就是我今年一年技术以外的一些认知。全部都来自我自己亲身实践的“宝贵经验”。希望读者看到这里能有一些收获。

当然每个人成长的方式都会有所不同，我只是提供了一种我经过实践验证了以后发现可行的方法，如果读者自身就有更好的方法，欢迎读者也分享出自己更好的方法，这篇文章就当是看我的年终总结。如果读者自身也对成长缺少一些方法，那可以考虑试试这篇文章里面提高的方法，共勉。

6. 未来

组里业务上又开始用 Python 了。这门在今年火透半边天的语言，明年我也好好学学。除此之外再把 Go 再精进精进。

最后

一年前有一个 P9 的阿里大佬问过我这样一个比较哲学的问题：“你作为程序员已经开发了这么多年，你是如何看待软件开发的？”，当时我回答说，“你想问前端开发还是 iOS 开发？”，答曰：“你能不局限在开发语言之中么？从宏观的角度来谈谈你对开发的定义，流程这些方面自己的见解”。当时我一下子回答不上来，并不是说不出来，而是觉得这个问题太宽泛了，不好回答。直到现在接触了不同语言，不同职位的开发任务以后，我就对这个问题有了自己的答案了。问这种问题，从答案的深浅也许就能看出一个人的水平深浅了。如果对软件开发没有几年的磨炼，没有足够宽的知识面和深度，这种问题答出来的答案一答出来肯定是比较浅显的。这就好比你已经精通了高数以后，考一个小学生解一元一次方程。不管他如何解这个方程，用什么方式，你一眼也能看出来他的水平。同理，上面的问题也是一个站在高处的大神，不管你回答什么答案，在他的资历看来，你的答案的深浅就能大概看出你的资历有几斤几两。

不知道读者看到这里是否心里已经有比较完美的答案了呢？这个问题笔者打算留到明年，作为 2018 年【星霜荏苒】的话题。

最后的最后，说一点最近的体会。有一本神书，《Clean Code》，中文翻译是代码整洁之道。这本书笔者最近有意无意的又拿出来翻了翻。再读第二遍，第三遍或者甚至第四遍的时候，每次阅读的体验都不同。读第一遍可能由于自己资历不够，能和书作者产生共鸣的地方并不多。更多的是在阅读书中的文字和代码，体会作者的意图。当然这也是最基本的。但是我最近发现读第二遍或者第三遍的时候，和书作者能产生更多的共鸣了，共鸣就来自于平时自己的开发过程中，书中的举出了一些例子就是自己亲身经历的，或来自于重构一个功能，或来自于绞尽脑汁的设计一个架构，或来自于某个特殊需求，种种亲身经历都会重新浮现在脑海中。一部分书中的内容我觉得我已经内化为自己的东西了。当然还有一个部分没有共鸣。

一遍遍的读一本书，在程序员成长的各种阶段都会有不同体会。开始会觉得书好厚，内容很枯燥，但是直到你经历了很多以后，会发现这本书其实很薄，回过头来看这本书就像自己的不同阶段的回忆录，里面的很多内容你都亲生经历过了。这也许就是自身水平的成长之路。这也算是自身成长最直接的物质体现。

好了，2017 年的【星霜荏苒】就到这里了。如有任何异议或者想讨论的地方，欢迎和我交流。

2017年12月30日，于悉尼 Sydney

Reference：
Vue 全家桶 + Electron 开发的一个跨三端的应用
Go 初学者的成长之路
空间搜索文章合集

GitHub Repo：Halfrost-Field

Follow: halfrost · GitHub

Source: https://halfrost.com/halfrost\_2017/