资深技术Leader曹乐：如何成为技术大牛。链接：https://mp.weixin.qq.com/s/QaBTm_9AJC01Isr3LLR3aw
通篇是在讲方法的，具有普适性。我在看的时候，时常能想到自己学东西一些比较失策的地方。这里就是给我们思维上转个弯儿，如果能够在学新东西的时候稍微借鉴一下，一定是有积极意义的。
【10000小时的刻意练习】
1.找到该领域的范式（寻找pattern，对于自己不熟悉的领域，这是比较难的过程）
2.针对每个范式反复练习刻意联系（如果是熟悉的就调重点看）
3.及时反馈（对比自己公司或者别的公司的工作）
【具体的方法】
快速梳理该领域的知识点，形成框架体系（寻找pattern），这里有些小窍门可以快速构建起一个领域的知识点体系，例如看一些该领域的综述性或开创性的文章（看论文，别瞎看网上的文章），或者找本该领域综述性的教科书看它的目录（注意，好的教科书的目录往往就是这个领域的知识框架，内容倒不一定非要看下去）。然后，针对每个知识点，找书里的相关章节，该领域相关paper里的相关section深入学习，建立起自己对这个知识点的理解（刻意练习）。最后，再把知识点和现实工作中的情况（自己工作，或其他公司相关的工作）进行对照（及时反馈），从而建立对一个知识点的深度理解，最后融会贯通建立对一个领域的理解。
【一个实际的例子】
拿我当年学习分布式存储的过程为例子，先结合自己的工作内容梳理出需要深入了解的知识点（例如，元信息组织，Meta Server设计和HA，副本组织和管理，Recovery，Rebalance，单机存储引擎，数据/元信息流，纠删码，一致性，多租户，存储介质，网络环境和IDC等等），同时看很多综述性的材料，梳理分布式存储的知识点（有网上各种整理的比较好的文章，也有从各种系统实现的paper里抽出），不断迭代构建分布式存储领域的知识点（寻找pattern，这是最难的一个过程）；然后针对每一个知识点，找相关材料进行深度学习，例如，对于分布式一致性，需要阅读CAP理论，Paxos的论文，Raft的论文等等以及周边的很多材料（刻意练习）；然后找各种系统实现的论文或文章，比如GFS，Dynamo，Aurora，OceanBase，Ceph，Spanner等等，看看和对比它们在一致性上是如何考虑和取舍的，当然，最重要的是结合自己工作中的反复实践和所学知识点进行比对（及时反馈）。这三个阶段并不是割裂的，而是周而复始的，经常会在刻意练习和及时反馈的学习过程中，发现自己遗漏的知识点，或者发现自己梳理的两个知识点其实是重合的。通过这种交叉比对，以及在实践中不断检验的方式建立的知识点是非常可落地的，而不会看了几篇论文以后就人云亦云。
【把工作当成理论学习的检验场所】
每个同学应该对自己工作所在的这个技术和业务领域进行系统性的学习，并在工作中反复实践和验证。不同的领域之间其实是融汇贯通的，当你对一个领域精通并总结出方法论以后，很容易就能上手别的领域。因此花几年实践彻底研究透一个领域，对于刚工作几年的同学来说，是非常重要，甚至是必须的，也只有在一个领域打透之后才谈得上跨领域迁移，去拓展自己的知识面。更直接的说，对于一个领域还未完全掌握的同学，深度是最重要的，不用想广度的事情，等掌握了一个领域之后，再去拓展广度就变得很容易了。这里一个常见的误区是，学习的内容和工作的领域没有太多直接的关系。
实践比理论重要地多，上述例子中看文献描述了很多，但是最后沉淀下来都是基于实践的验证和反馈：
一个常见的误区是，学习的内容和工作的领域没有太多直接的关系。举一个例子，很多优秀的架构师，尽管日常工作中可能反复在用，但未必说得出开闭原则，里氏替换原则，迪米特法则等等，反过来，对面向对象设计这7大原则出口成章的人，很多其实离真正的架构师还远得很，有些甚至只是博客架构师而已。实践远远比看书，看文章重要得多，上文所述的我构建自己分布式存储知识体系的过程，看起来好像都是看材料，看论文，而实际上80%的收获都来源于带着理论的实践，和从实践中总结沉淀的理论。因此，彻底搞明白自己工作所在的技术和业务领域，是最务实高效的做法，工作和学习割裂，会导致工作和学习都没做好。
【多思考，在行动中多问自己是什么，为什么】
工作中每个点滴的琐事与平凡，都是可以抽象总结成为方法论的，更别说工作所在的领域自身的博大精深了。从日常工作中学习的秘诀，就是“行动中思考”。
【如何写好代码】
提高写代码的能力的核心，首先在于坚持不断的写，但更重要的，在于每天，每周，持续不断的review自己之前的代码；同时，多review牛人写的代码，比如是团队里你觉得代码写的比你好的同事，比如社区里以代码漂亮著称的开源代码（作为一个C++程序员，当年我的榜样之一是boost库）。
一旦觉得自己之前的代码不够好，就立刻复盘，立刻重构。
多思考自己代码和好的代码之间不同之处背后的为什么，通常这就是为什么这些代码更好的背后的秘密。特别要说明的是，代码规范除了知道是什么外，要格外重视思考每一个代码规范背后的为什么。代码规范的每一句话，背后无一例外都是一片江湖上的血泪史。
【trouble shooting的能力】
要提高trouble shooting的能力，关键在于要深度复盘自己遇到的每一个问题，包括线上的，包括测试发现的，寻找每一个问题，每一次事故背后的root cause，并且思考后续如何避免同类问题，如何更快的发现同类问题。要对团队内外遇到的所有问题都要保持好奇心，关注一下周边的事故、问题背后的root cause。Trouble shooting能力的提高是几乎无法从书本上得到的，完全来源于对每一个问题的深度思考，以及广泛积累每一个问题。对于架构师而言，可能未必在一线写代码了，但看团队中一个架构师是否真正牛逼的一个很重要标准，就是看他是否能够追查出团队其他同学查不出来的问题。我见过的一个真正牛逼的架构师，对于系统中疑难杂症，通常问几个问题，就能大致猜出是哪里出的问题，以及可能的原因是什么，准确程度如同算命，屡试不爽，令人叹为观止。
【体系化的思维能力】
一方面是在日常工作中，对每一个接口设计，每一个逻辑，每一个模块，子系统的拆分和组织方式，每一个需求的技术方案，每一个系统的顶层设计，都要反复思考和推敲，不断的复盘。
另一方面，需要大量广泛的学习行业内相似系统的架构设计，这其实就是开天眼，只是技术相对来说，行业内的交流更加频繁，淘宝、美团、百度、Google、Facebook、Amazon等各个公司介绍系统架构的论文和PPT铺天盖地，需要带着问题持续学习。
【了解业务】
架构师的难点不在于给出方案，而在于找到唯一的那一个最简单优雅的方案。就是在自己了解的行得通的方案中，找到最适合当前业务的架构。
【坚持一个方向，深入挖掘才是最重要的】
尽管我们通篇都在讲方法，但其实在成为技术大牛的路上，方法反而是没那么重要的。真正困难的，在于数年，数十年如一日的坚持。太多人遇到挫折，遇到瓶颈，就觉得手头的事情太乏味枯燥，就想要换一个方向，换一个领域，去学新的技术，新的东西。而真正能够成为大牛的，必须是能够青灯古佛，熬得住突破瓶颈前长时间的寂寞的，必须是肯下笨功夫的聪明人。因此，和坚持相比，方法其实并没有那么重要。
——————————————————————————————————————————————————
我的理解
如果说针对一门新技术或者新的框架，那么第一步应该是去找到官网的第一手资料，看看它解决了什么问题，有什么特点等等，而不要一上来就去啃大部头的书或者看什么视频（当然看一些综述类的视频也能达到这个目的，不过是别人总结的，没有官网来的原汁原味）。
针对于范式，我觉得既可以在学其它内容的时候，寻找到权威书籍的目录或者官网中介绍的点来画图，也可以根据自己所学进行反推，这样来回来回地比对，应该能将理论中的要点和实际中的体会相互结合。
自己实际的工作就是对这个理论进行反馈的最佳机会，所以如果真的想好好搞技术，就找到工作当中常用的技术，按照使用频率或者重要程度排个序，一个一个按照上述方法进行深入学习，甚至在这个过程中，可以刻意去把一些少有机会去深入的基础慢慢打牢，这个过程因为有工程实用的机会，肯定要比在学校的学习更为扎实。
不用纠结，大牛学了不用也会忘。但是有一点，学过的东西总结成一眼能看完的图谱，有助于过几个月甚至过几年再来看时迅速找到方向和解决问题的思路。所以不要说学过忘了所以没用，一些有记忆时限的东西，最重要的时先看，理解，动手，内化，最重要的一步总结图谱。这个过程中就算是理解了，如果对图谱的总结缺失了，那么时间一长，基本就白学了。
在看了这篇文章，仔细消化消化之后，越发觉得网上的文章、公众号之类的文章，如果没有机会去实践的话，看了也是白看。实践大于理论，而理论也要有体系。
我觉得，时长冒起的一个想法，仔细了解<阿里Java规约>，并要去了解每一条背后的为什么。这是一个很有价值的事情。
之前在技术的成长里，我也说过不要对任何细微的问题放任不管。自己也会在工作中解决，甚至挖掘和了解其它同学的bug，目的就是要在一个熟悉的场景中找到为什么会犯错，如果能够深入总结，总是能有收获的。大牛这里甚至用Trouble Shooting的能力构建来说明这个问题，说明自己走对了，看到这里的时候还是很开心的，又有了能够坚定向前的动力。
对比大牛说的架构师需要学习同类型业务的公司是如何组织自己的架构，可以查到论文和PPT，原文说这个是铺天盖地的，但是自己平常接触较少，说明自己的信息源还是不够好。另外所说的带着问题和了解自身业务场景的原因，其实就是技术实现和现实的一个平衡。简单的例子，如果是一个内部几十个人用的网站，没必要上来就想着高并发大数据量；规模到了什么量级，就用什么场景对应的解决方案就好，没必要过度设计。