【第1229期】程序员如何在技术浪潮的更迭中保持较高的成长速度 ？
前言
有思考的年终总结。今日早读文章由@于德志授权分享
正文从这开始～
题记
作为技术人，到年底都会进行一次自我反思或者总结，回过头来看看这一年自己成长了多少。笔者也不例外，同样打算从 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 非常多，饿了么前端吉祥物，天哥，天尊……数不清，她一毕业就在前端的架构组工作，能力非常强。再次我也感谢一下她对我这种入门级小白的问题耐心的解答。在成长的路上解答了很多问题。
另外一个师父是和我同一天入职的朋朋，他也是前端开发，技术非常强。我和他关系也非常好。平时有前端的问题也会问他。
最后一个师父是我大学同寝室的，前端也很厉害，不懂的问题也会向他请教。
在此也感谢上面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》，中文翻译是代码整洁之道。这本书笔者最近有意无意的又拿出来翻了翻。再读第二遍，第三遍或者甚至第四遍的时候，每次阅读的体验都不同。读第一遍可能由于自己资历不够，能和书作者产生共鸣的地方并不多。更多的是在阅读书中的文字和代码，体会作者的意图。当然这也是最基本的。但是我最近发现读第二遍或者第三遍的时候，和书作者能产生更多的共鸣了，共鸣就来自于平时自己的开发过程中，书中的举出了一些例子就是自己亲身经历的，或来自于重构一个功能，或来自于绞尽脑汁的设计一个架构，或来自于某个特殊需求，种种亲身经历都会重新浮现在脑海中。一部分书中的内容我觉得我已经内化为自己的东西了。当然还有一个部分没有共鸣。
一遍遍的读一本书，在程序员成长的各种阶段都会有不同体会。开始会觉得书好厚，内容很枯燥，但是直到你经历了很多以后，会发现这本书其实很薄，回过头来看这本书就像自己的不同阶段的回忆录，里面的很多内容你都亲生经历过了。这也许就是自身水平的成长之路。这也算是自身成长最直接的物质体现。
最后，为你推荐
关于本文
作者：@于德志
原文：https://halfrost.com/halfrost_2017/