深度好文 | 资深技术Leader曹乐：如何成为技术大牛

双生说：曹乐是典型学霸，清华本硕，多年互联网大厂研发经验，因此“资深”。我刚到新部门的时候，约各位合做部门的Leader请教，也算帮我作新岗位入职的“平稳降落”。印象最深的，就是做为技术Leader的曹乐，一点都不像技术——他和我谈对业务的理解，各个维度的看法与想法，让人印象深入。而后，他很热情的帮我安排了他团队几个同窗的1-1，帮助我了解了更多从技术视角对业务与技术团队协同、共创的思考。后来，开始深刻合做，发现合做的技术同窗，不只仅技术上追求精进，并且是真正的也可以跳出来去看业务全局。能跳出来，能跳进去。

这封信，是曹乐写给团队的。如何成为技术大牛（来自另外一学霸同事的评论，感谢）：寻找范式、刻意练习、及时反馈；垂直打透、横向迁移、深度复盘；聪明人要下笨功夫。

Enjoy~

不少同窗都有关于工程师该如何成长的问题，你们广泛对如何成长为牛人，如何得到晋升，如何在繁忙的工做中持续学习充满了困惑，这实际上是每一位同窗成长过程当中必经之路。最近几回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内部也把这个功能去掉了）。这也是为何我在我们部门内反复强调你们须要深刻了解业务，由于达到一样的业务目标，可能稍微改一下产品方案就可让需求的技术实现变得无比简单。只有真正知道上层业务是如何使用系统的，才可能真正作好架构。 深刻了解业务并不难，对于每一个同窗，只要对于每个接到的需求，对于每个需求评审中的需求，对于周边同窗或团队要作的需求，都深刻思考为何业务要提出这个需求，这个需求解决了业务的什么问题，有没有更好的方案。遇到不明白的多和周边同窗、产品、运营同窗请教。最怕的是本身把本身限定为纯粹的研发，接到需求就无脑作，这等于放弃了主动思考。衡量一我的是否是好的架构师，也有一个方法。对于一个需求，若是他给出了好几个可行的方案，说这些方案也能够，那些方案也能够，每每说明他在架构师的路上尚未彻底入门。架构师的难点不在于给出方案，而在于找到惟一的那一个最简单优雅的方案。

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

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

看起来方法也不复杂，为何大牛仍是很是稀少？

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

和你们共勉。

（完）