导读

公司技术资深总监曹老板写给技术同学的技术成长分析，我复制过来保存一份。

正文

很多同学都有关于工程师该如何成长的问题，大家普遍对如何成长为牛人，如何获得晋升，如何在繁忙的工作中持续学习充满了困惑，这其实是每一位同学成长过程中必经之路。最近几次1-1也和同学聊过这方面的问题。在这里也想跟大家分享一下我的一些心得。

同学们普遍对成长充满了焦虑感。工作太忙没时间学习，需求太多太琐碎感觉自己没什么进步，做技术是不是做到35岁以后就没人要了，等等，都是对成长焦虑的体现。在这里我想说的是，这种焦虑是正常的，所有的渴望，在内心的投射其实都是焦虑。任何一个渴望成长的人，不管处于什么阶段，一线工程师，架构师，还是总监，副总裁，其实内心中都是充满了焦虑的，无一例外。对于这种焦虑，我们所要做的是接纳，而不需要过度担忧。这种焦虑并不是说，想明白如何成长了就会没有了，到了某个阶段就会没有了的。成长的脚步和期待一刻不止，内心的焦虑也一刻不会停歇。正是这种焦虑感，驱使你写代码追查问题到星夜，驱使你牺牲休息娱乐的时间和一本本厚厚枯燥的书作伴，驱使你不断努力向前，不舍昼夜。相反的，如果内心中没有这种焦虑，反而是值得担忧的。这可能说明已经习惯呆在自己的舒适区了。在现在这样一个高速发展的社会，以及我们这样一个高速发展和变化的行业，失去对成长的渴望和焦虑反而是一个非常危险的信号。

所谓的程序员35岁危机，其实背后的根本原因是，有太多太多人在工作几年以后，就觉得自己什么都会了，之后的十几年工作只不过是头2-3年的简单重复而已。在我们这样一个行业里，在招聘的时候，如果摆在管理面前的两个人，一个是初出茅庐或刚工作2-3年，充满了对成长的渴望；另一个工作十多年了但水平和工作2-3年的人差不多，只是更熟练一些，不过在舒适区已经躺了十年了。如果负责招聘的是你，你会做出什么样的选择？

而另一方面，其实是高端人才在行业内的极度极度稀缺。大家可以想一想，我们部门上一次招聘到D10及以上的同学是什么时候？从业务平台部2016年中成立到现在，一个都没有过。D9同学也是凤毛麟角，一年能招到1-2个就足够可以偷着乐了。面试碰到牛人的时候，就如同相亲碰到女神一样激动。这其实在行业内是非常普遍的现象，真正的大牛太稀缺了。在这样一个行业里，如果一个人能够持续成长，能力和工作年限成正比的持续提升，这样的人，任何时候在行业里都是被疯抢，怎么可能会遇到任何年龄的危机呢？

每一个业务平台技术部的同学，都应该立志成为这样的大牛，持续学习和成长。

如何学习，其实是有方法论的，那就是刻意练习。所谓的10000小时成为大牛的理论是片面的，如果只是简单重复10000小时，是不可能成为大牛的。刻意练习包含了三个步骤。第一，找到你要学习的这个领域体系的范式（pattern）；第二，针对每个范式刻意的反复学习和练习；第三，及时反馈。

大家在过往的工作和学习生活中，或多或少都在实践着刻意练习。拿面临高考的中学生举例子，好的学生通常是把一门功课拆成了很多知识点（寻找pattern），然后针对知识点以及他们的排列组合，有针对性的反复做各种难度的题（刻意练习），每次做完题都对一下答案看看正确与否，如果错了就思考，记录，复盘（持续及时反馈）。这样的学习方法就是事半功倍的。而事倍功半的学习方法，就是不分青红皂白拿起一本习题或卷子就拼命做，我上学的时候身边不少同学非常勤奋但成绩并不好，多半都是这个原因。再举一个我最近在学打羽毛球的例子，正确的学习方法是把打羽毛球拆解成步法和手上动作，小碎步，米字步，正反手挑球，放网，正手和头顶高远球吊球杀球等（寻找pattern），然后针对每一个动作反复练习（刻意练习），然后请教练或者录下来看视频纠正自己的动作（及时反馈）；而错误的学习方法是，上来就盲目找人打比赛，以赛代练，这样的进步是很慢的，而且错误的动作形成习惯以后未来反而很难纠正。

当学习方法不正确的时候，刻苦的学习常常只是看起来很勤奋，并没有应有的效果。当接触一个陌生领域的时候，错误的学习方法是不带目的性，上来就找一堆相关的大部头开始啃。而正确的学习方法应该是快速梳理该领域的知识点，形成框架体系（寻找pattern），这里有些小窍门可以快速构建起一个领域的知识点体系，例如看一些该领域的综述性或开创性的文章（看论文，别瞎看网上的文章），或者找本该领域综述性的教科书看它的目录（注意，好的教科书的目录往往就是这个领域的知识框架，内容倒不一定非要看下去）。然后，针对每个知识点，找书里的相关章节，该领域相关paper里的相关section深入学习，建立起自己对这个知识点的理解（刻意练习）。最后，再把知识点和现实工作中的情况（自己工作，或其他公司相关的工作）进行对照（及时反馈），从而建立对一个知识点的深度理解，最后融会贯通建立对一个领域的理解。这样说可能有点抽象，拿我当年学习分布式存储的过程为例子，先结合自己的工作内容梳理出需要深入了解的知识点（例如，元信息组织，Meta Server设计和HA，副本组织和管理，Recovery，Rebalance，单机存储引擎，数据/元信息流，纠删码，一致性，多租户，存储介质，网络环境和IDC等等），同时看很多综述性的材料，梳理分布式存储的知识点（有网上各种整理的比较好的文章，也有从各种系统实现的paper里抽出），不断迭代构建分布式存储领域的知识点（寻找pattern，这是最难的一个过程）；然后针对每一个知识点，找相关材料进行深度学习，例如，对于分布式一致性，需要阅读CAP理论，Paxos的论文，Raft的论文等等以及周边的很多材料（刻意练习）；然后找各种系统实现的论文或文章，比如GFS，Dynamo，Aurora，OceanBase，Ceph，Spanner等等，看看和对比它们在一致性上是如何考虑和取舍的，当然，最重要的是结合自己工作中的反复实践和所学知识点进行比对（及时反馈）。这三个阶段并不是割裂的，而是周而复始的，经常会在刻意练习和及时反馈的学习过程中，发现自己遗漏的知识点，或者发现自己梳理的两个知识点其实是重合的。通过这种交叉比对，以及在实践中不断检验的方式建立的知识点是非常可落地的，而不会看了几篇论文以后就人云亦云。拿分布式存储的一致性举例子，如果不是反复对比、思考和反复实践，你不会发现GFS论文里最难的一段，多个Writer对一个文件进行append的逻辑，在实践中根本没用；你也不会发现看起来优雅而学术的CAP三选二的理论，实践中压根不是这么完美，很多时候只能三选一；你也不会发现Dynamo论文里的Vector Clock，网上有无数文章摇头晃脑的解读，但在Amazon的应用场景里是个典型的over design，Cassandra在这点就务实很多。

这时候大家可能会有个疑问，工作本身就如此繁忙了，哪里能抽出足够多的时间去学习？

其实工作和学习本身，是不应该被割裂的。工作本来就应该是学习的一部分，是学习中的实践和及时反馈的部分。学习如果脱离工作的实践，其实是非常低效的。因此每个同学应该对自己工作所在的这个技术和业务领域进行系统性的学习，并在工作中反复实践和验证。不同的领域之间其实是融汇贯通的，当你对一个领域精通并总结出方法论以后，很容易就能上手别的领域。因此花几年实践彻底研究透一个领域，对于刚工作几年的同学来说，是非常重要，甚至是必须的，也只有在一个领域打透之后才谈得上跨领域迁移，去拓展自己的知识面。更直接的说，对于一个领域还未完全掌握的同学，深度是最重要的，不用想广度的事情，等掌握了一个领域之后，再去拓展广度就变得很容易了。这里一个常见的误区是，学习的内容和工作的领域没有太多直接的关系。例如，我以前曾经花了非常大的功夫去读Linux内核的源代码以及很多相关的大部头，几乎花掉了我将近两年的所有空闲时间，然而在我这些年的工作里，几乎是没有用处的，最多就是有一些“启发”，ROI实在是太低了，现在也忘得差不多了。更重要的，软件工程是一门实践科学，从书本上得到的知识如果没有在实践中应用和检验，基本上是没有用处的。举一个例子，很多优秀的架构师，尽管日常工作中可能反复在用，但未必说得出开闭原则，里氏替换原则，迪米特法则等等，反过来，对面向对象设计这7大原则出口成章的人，很多其实离真正的架构师还远得很，有些甚至只是博客架构师而已。实践远远比看书，看文章重要得多，上文所述的我构建自己分布式存储知识体系的过程，看起来好像都是看材料，看论文，而实际上80%的收获都来源于带着理论的实践，和从实践中总结沉淀的理论。因此，彻底搞明白自己工作所在的技术和业务领域，是最务实高效的做法，工作和学习割裂，会导致工作和学习都没做好。

这时候大家可能会有另一个疑问，感觉日常工作非常琐碎，学不到什么东西，怎么办？

如果把学习分成从书本中学，和从工作中学这两种的话，那毫无疑问，工作中的“知识密度”，比起书本的“知识密度”，肯定是要低很多的，因为书本里的知识，那都是人家从他们的工作中抽象总结出来的。这也是为什么大家普遍觉得日常工作“琐碎”。然而工作中每个点滴的琐事与平凡，都是可以抽象总结成为方法论的，更别说工作所在的领域自身的博大精深了。从日常工作中学习的秘诀，就是“行动中思考”。

对于每一个软件工程师，最重要的两个能力，是写代码的能力和trouble shooting的能力。并且，要成为优秀的架构师，出色的开发能力和追查问题的能力是一切的基础。提高写代码的能力的核心，首先在于坚持不断的写，但更重要的，在于每天，每周，持续不断的review自己之前的代码；同时，多review牛人写的代码，比如是团队里你觉得代码写的比你好的同事，比如社区里以代码漂亮著称的开源代码（作为一个C++程序员，当年我的榜样之一是boost库）。一旦觉得自己之前的代码不够好，就立刻复盘，立刻重构。更重要的是，多思考自己代码和好的代码之间不同之处背后的为什么，通常这就是为什么这些代码更好的背后的秘密。特别要说明的是，代码规范除了知道是什么外，要格外重视思考每一个代码规范背后的为什么。代码规范的每一句话，背后无一例外都是一片江湖上的血泪史。要提高trouble shooting的能力，关键在于要深度复盘自己遇到的每一个问题，包括线上的，包括测试发现的，寻找每一个问题，每一次事故背后的root cause，并且思考后续如何避免同类问题，如何更快的发现同类问题。要对团队内外遇到的所有问题都要保持好奇心，关注一下周边的事故、问题背后的root cause。Trouble shooting能力的提高是几乎无法从书本上得到的，完全来源于对每一个问题的深度思考，以及广泛积累每一个问题。对于架构师而言，可能未必在一线写代码了，但看团队中一个架构师是否真正牛逼的一个很重要标准，就是看他是否能够追查出团队其他同学查不出来的问题。我见过的一个真正牛逼的架构师，对于系统中疑难杂症，通常问几个问题，就能大致猜出是哪里出的问题，以及可能的原因是什么，准确程度如同算命，屡试不爽，令人叹为观止。

对于一个架构师，除了更加优秀的代码能力和trouble shooting能力外，需要构建相对完整的当前技术领域的知识体系，需要有体系化的思维能力，需要对技术所服务的业务要有非常深入的了解。体系化的思维能力，来源于两个方面。一方面是在日常工作中，对每一个接口设计，每一个逻辑，每一个模块，子系统的拆分和组织方式，每一个需求的技术方案，每一个系统的顶层设计，都要反复思考和推敲，不断的复盘。另一方面，需要大量广泛的学习行业内相似系统的架构设计，这其实就是开天眼，只是技术相对来说，行业内的交流更加频繁，淘宝、美团、百度、Google、Facebook、Amazon等各个公司介绍系统架构的论文和PPT铺天盖地，需要带着问题持续学习。除了技术领域本身外，架构师需要非常了解业务上是如何使用我们的系统的，否则非常容易over design，陷入技术的自嗨中，这也是为什么我说Amazon Dynamo论文里讲的Vector Clock是个over design的原因。另一方面，很多时候技术上绕不过去的坎，可能非常复杂的实现，往往只需要上层业务稍微变通一下，就完全可以绕过去，这也是为什么我说GFS论文里，多个Writer同时Append同一个文件是个根本没用的设计（实际上Google内部也把这个功能去掉了）。这也是为什么我在咱们部门内反复强调大家需要深入了解业务，因为达到同样的业务目标，可能稍微改一下产品方案就可以让需求的技术实现变得无比简单。只有真正知道上层业务是如何使用系统的，才可能真正做好架构。 深入了解业务并不难，对于每个同学，只要对于每一个接到的需求，对于每一个需求评审中的需求，对于周边同学或团队要做的需求，都深入思考为什么业务要提出这个需求，这个需求解决了业务的什么问题，有没有更好的方案。遇到不明白的多和周边同学、产品、运营同学请教。最怕的是自己把自己限定为纯粹的研发，接到需求就无脑做，这等于放弃了主动思考。衡量一个人是不是好的架构师，也有一个方法。对于一个需求，如果他给出了好几个可行的方案，说这些方案也可以，那些方案也可以，往往说明他在架构师的路上还没有完全入门。架构师的难点不在于给出方案，而在于找到唯一的那一个最简单优雅的方案。

总结起来看，行动中思考，就是始终保持好奇，不断从工作中发现问题，不断带着问题回到工作中去；不断思考，不断在工作中验证思考；不断从工作中总结抽象，不断对工作进行复盘，持续不断把工作内容和全领域的知识交叉验证，反复实践的过程。

在工作所在的技术和业务领域中刻意练习，加上行动中思考，就是成为技术大牛的秘诀。

看起来方法也不复杂，为什么大牛还是非常稀少？

尽管我们通篇都在讲方法，但其实在成为技术大牛的路上，方法反而是没那么重要的。真正困难的，在于数年，数十年如一日的坚持。太多人遇到挫折，遇到瓶颈，就觉得手头的事情太乏味枯燥，就想要换一个方向，换一个领域，去学新的技术，新的东西。而真正能够成为大牛的，必须是能够青灯古佛，熬得住突破瓶颈前长时间的寂寞的，必须是肯下笨功夫的聪明人。因此，和坚持相比，方法其实并没有那么重要。

和大家共勉。