架构师的 36 项修炼第11讲：致未来的架构师_架构修炼知道 百无一用

 

本课时将分享技术之外的话题：如何从普通程序员成长为技术专家？

技术人的进阶路径

普通程序员与顶尖技术专家之间有多大差距？他们的进阶路径是怎样的？

 

跟大多数领域一样，计算机技术人才构成也是金字塔型。一般说来，这样的金字塔结构是按照二八定律划分的。如下图，我按照二八定律将技术人金字塔分为八层，从 0 级到 7 级。

0 级——普通程序员

最下面的是第 0 级，80% 的技术人都处在这一级。0 级技术人，在开发过程中几乎没有话语权。他们要实现的功能，所使用的技术框架、编程语言、数据库，他们遇到关键问题的处理方法等等，都是被指定的。中国目前大约有 1000万 程序员，也就意味着有 800万 的程序员是在别人的指导和安排下工作的。一个 10 人团队大约有 8 人是 0 级技术人，这跟现实中观察到的情况大致相同。

1级——团队的影响者

往上一级是 1 级技术人，占剩下 20% 的 80%，即技术人总数的 16%。处于这一级的人我称之为团队的影响者。他们通常是技术团队里的架构师、技术经理、技术骨干，每个 10 人团队里面大约有一两个这样的技术人员。他们负责团队产品研发的技术选型、关键的技术实现、排查关键的技术难题、负责产品的技术架构设计等。

2 级——公司的影响者

再上面一级是 2 级技术人，有 3.2% 的技术人处于 2 级，我称这一级的人为公司的影响者。他们在公司范围内有一定的技术影响力，决定了公司大的技术方向，比如使用什么样的编程语言，整个公司使用什么样的核心框架、使用什么样的数据库、什么样的测试工具，诸如此类。在一个 300 人左右的公司里面，差不多有 10 个这样的人。

3 级——全国影响者

再往上是金字塔的第四层，3 级技术人是全国影响者，占技术人总数的 0.64%。他们通过自己的博客、专业书籍、各类技术峰会等公开渠道在全国范围内影响到相当一部分人，是某一个细分领域的领军人物。他们通常也是技术的布道师，率先在开发中使用实践了国外一些比较新的技术方法、技术工具、技术框架等，并将这些技术在全国范围内进行推广。

4 级——全球影响者

而在 3 级之上，则是具有全球影响力的一些技术人员。他们在全球范围内进行技术布道、出版书籍、发表演讲，在全球范围内影响技术潮流，这样的人大约占总数的 1‰ 左右。对绝大多数中国的技术人说， 3 级是瓶颈，很难到达 4 级，成为具有全球影响力的 4 级技术人，因为中国的 IT 技术在全球技术生态仍在第二梯队，在第一梯队引领全世界的是美国，4 级以上的技术人才目前主要在美国。

 

在金字塔的 4 级及以下，虽然也有人拥有较大的影响力，会一定程度上影响技术趋势，但他们仅仅是软件的使用者、布道者、传播者，并不是开发者。

5级——关键开创者

具有全球影响力的技术工具和技术框架的开发者才是真正的开创者。这些人处在金字塔的第六层，是 5 级技术人，我称其为关键开创者。因为有了他们的工作和成果，如 Log4j、JUnit 等提升生产力的工具，全球的开发人员都能够更高效地开展工作，开发出更高质量的代码，这样的人仅占技术人总数的万分之二。

6 级——领域开创者

而在金字塔的第七层，我称其为领域开创者，这些人不但开创出流行的应用工具，还开创了一些领域。在这个领域之内，还有其他的开发者进行周边生态开发。比如像 Spring，已经构成了一个软件开发的生态。Java 开发人员可以利用 Spring 全家桶开发一个功能完备的 Web 应用系统。这样的人约占技术人总数的十万分之五。

7 级——行业开创者

在整个金字塔最上层，是全球技术人中的王者。他们是行业的开创者，可以催生出每年营收在几十甚至几百亿的行业，比如 Hadoop 的开创者 Doug Cutting、Java 的开创者、Linux 的开创者，这些人约占全球技术人的十万分之一。

进阶路径

对于普通的软件开发者而言，到达金字塔的最上层，成为一个行业的开山祖师可能性不大，但成为 3 级、4 级甚至 5 级的机会还是存在的。特别随着中国互联网和 IT 技术的不断进步，这样的机会事实上是越来越多了。美国人主导的知名开源软件中，越来越多的核心开发人员来自中国，而中国人自己主导的开源软件， 也越来越得到全球认可。

如上图所示，对于 0 级技术人而言，比较现实的途径依然是不断精进、逐级提升。如果你现在只是团队里面的一个普通开发者，尽量去学些新技术、实践新技术，试着解决团队里的技术难题、做一些架构设计，使自己成为 1 级技术人，成为团队里面的技术骨干或者架构师。

 

成为团队的技术骨干后，进一步地，在跨团队合作过程中，对其他技术团队进行技术指导，帮助他们解决难题，争取成为有公司影响力的人。在你获得了足够的技术经验和技术实力的基础之上，通过公开演讲、出版图书、撰写博客等方式去打造自己的个人品牌，获得全国影响力。在这个过程中也可以参与或者主导一些开源技术产品的实现，争取成为关键开创者，甚至成为领域开创者。

如何逐步成为技术专家

那么如何才能一级一级地提升自己，成为具有更高影响力的专家呢？这里总结了几点，如下图所示，以供参考。

 

勇于承担责任

第一是要勇于承担责任。好的技术都是经过现实锤炼的，能够真正解决现实问题的，得到大多数人欢迎和拥护的。所以自己去学习各种各样的新技术固然重要，但是更重要的是在实践中思考。如果一味按照指令完成开发，永远都无法真正理解一项技术。但如果在实践中勇于对自己工作的结果负责，就可以倒逼自己更多地思考技术的核心、关键点、技术的缺陷与优势，从而真正掌握一项技术。另外，在团队中承担核心的技术职责，有助于产生技术影响并巩固自己的技术地位。

在实践中保持技能

第二个是在实践中保持技能。有个说法叫作“1万小时定律”。是说成为一个领域的专家级人物，必须要经过 1万 小时高强度的训练才行。对软件开发这样更强调技术的领域，这一点尤其明显，必须要经过长时间的编程实践来提升技术认知，理解技术的精髓，感悟技术的真谛。但是 1万 小时的编程并不指重复写低难度代码，而是有适当难度的代码。什么叫适当难度呢？就是努力才能达到，但也不是遥不可及。

 

比如，每一次在完成一个工作以后，下一次的工作都要比上一次的工作难度再增加一点点，不断地让自己去挑战更高难度，从而去获得更高的技术，拥有更高的技术能力和技术认知。通俗说来就是要摘跳起来够得着的苹果，不要简单地摘伸手就能摘到的苹果，这样对你的技术提升是没有帮助的。但是如果难度太高，去做了，然后失败了，连续的失败，痛苦的失败，其实对人的挫折打击也是非常大的，而对真正的技术提升其实帮助并不大。所以最好是选择那些跳起来能够摘得到的苹果，你要努力再进步一点点，你才能够完成。完成以后，下一次，在这个基础上再努力一点点、进步一点点，完成更难一点的工作。通过这样持续的工作训练和挑战，在实践中去持续地获得进步，你就可以从金字塔的一级向更高的一级前进。

警惕银弹陷阱，关注问题场景

还有一个建议是警惕银弹陷阱，关注问题场景。很多人都有一种理想化的期望，就是希望能够想到一个一劳永逸、可以解决所有问题的解决方案或技术。但现实中这样的解决方案和技术是不存在的。没有万能的方法，每一种方法都有适用的场景，每一种技术都有优缺点。你必须要理解所面临的问题的关键细节、上下文场景，才能选出最合适的技术方案，真正解决问题，否则即使你拥有强大的技术，也很难用好技术。所谓的专家就是善于根据场景发现方法的那个人，如果你关注场景、根据场景去寻找解决办法，或许你会发现解决问题非常简单，并不需要多么高深的工具和技术。所以，你必须意识到方法、技术、工具这些都不是最复杂的，真正难的是剖析场景、理解问题。

 

关于问题，软件开发其实就是解决问题，解决业务的问题、解决技术的问题等。我们每天都在帮公司解决问题，帮用户解决问题，但其实大多数情况下我们连公司面对的问题是什么，用户真正的问题是什么都不知道。所以如果你想真正把问题解决好，那么，当产品经理、老板、上司要你去解决一个问题的时候，你要先去了解真正要解决的问题是什么，而不只是听从指令完成交付。因为在稀里糊涂的状态下，你很难有所提升。

架构师阅读清单

课程的最后，分享一下对我个人成长影响较大的几本书，这 5 本书支撑起了我的技术思维框架，每一本书都是我个人技术成长中的一座重要的里程碑，希望这些书也能够给你带来帮助。

《Effective Java中文版》

第一本书是 Effective Java。这本书是我在早期的时候遇到的，令我感觉比较震撼的一本技术书。通过这本书，我第一次感受到技术编程之美，发现在枯燥无聊的软件开发过程中，还有这样一些精致的、巧妙的编程方法和技巧可以应用，而这些技巧有很多是和我当时的编程方法相反的。下图所示是《Effective Java中文版》。

事实上正是通过这本书，我打开了专业软件编程的大门，它使我意识到专业的东西一定是反常识的，这恐怕是这本书给我最大的收获。看了这本书以后，当我本能地想用习惯的方法进行编程的时候，我总是问自己，有没有更好的、更高效的编程方法。这本书让我知道，在堆砌代码实现功能之外，还有这样一些优美的、精致的技巧可以使用。它让我理解到了编程这门技术的专业性所在，让我感受到技术的高度，不再坐井观天。

《设计模式》

另外一本书是《设计模式》，如下图。这本书也比较知名，我也在很早的时候就看了这本书。但是读这本书的时候，我其实并没有太多的感觉，真正让我理解它是在后面的漫长的工作中。当我在阅读别人的代码，包括一些开源代码和优秀的代码示例的时候，我从别人的代码里看到了这些设计模式，看到这样一些精致的编程解决方法，回过头来再想，原来设计模式是这样一些可以让问题变得更加优美的、精致的、灵活的解决方法，然后从头再学习这些设计模式。

 

       

之后，我在工作中才开始尝试使用各种各样的设计模式，让自己的代码也变得更加灵活和可复用。这个过程大概持续了好几年的时间，这几年的时间里，我反复地阅读了几本关于设计模式的书，从多个方面去了解设计模式究竟是如何解决技术问题的。可以这么说，如果你不懂设计模式，你就不懂面向对象编程，你就没有真正掌握那些面向对象编程的强大技术。所以掌握面向对象编程一定要学习设计模式。

《敏捷软件开发——原则模式与实践》

还有一本给我震撼的书是 Bob 大叔的这本《敏捷软件开发——原则模式与实践》，如下图所示。这本书里面提出了一个重要的软件设计思想方法， 就是在软件开发过程中，需求一定是会变更的。软件设计的重要的使命就是去面对需求变更，去解决需求变更的问题，也就是所谓的敏捷开发。

 

但是敏捷开发最重要的并不是什么软件开发方法、软件开发过程管理，而是软件设计本身。你设计出来的软件，必须真正是灵活、敏捷、易于维护、易于扩展、易于变更的，只有这样你才算做到了敏捷软件开发。

 

那么如何做到让自己开发的软件灵活、易维护、易变更、易扩展？Bob 大叔在这本书里面给了几组软件开发的设计原则、设计模式与最佳实践。包括了很多人都很熟悉的：开闭原则、依赖倒转原则、里氏替换原则、接口隔离原则、单一职责原则。

 

在这本书里面 Bob 大叔说，优秀的工程师不应该害怕需求变更，而是应该欢迎需求变更。因为所谓的优秀的软件就是面向需求组变更设计的，只有当需求变更发生的时候，自己的设计才能够体现出价值来。而好的程序和差的程序员之间的差别并不在于开发的功能是否完备，而是在于开发出来的软件是否更易于维护和扩展。

《企业应用架构模式》

如下图所示，《企业应用架构模式》也是一本关于模式的书，作者是大名鼎鼎的马丁·弗洛（Martin Fowler）。

 

我以前也曾经很好奇这些做架构设计的，开发出来灵活可复用的框架的人，他们是如何工作的？他们为什么能够开发出来这样有技术难度的产品来。马丁·弗洛在这本书里面对各种各样的企业应用架构模式进行了总结，看了这本书，你会发现各种各样的框架、工具、架构方法，其实都是有模式可循的，也就是有套路可循的。

 

所谓的“模式“就是指可重复使用的解决方案。人们在实践中发现很多软件开发的需求问题，要面对的架构问题都是相似的，它的解决方法也是相似的，把这些相似的解决方法总结出来，就构成了架构模式。马丁·弗洛在这本书里面对企业应用架构的各种模式都进行了总结。基本上通过这本书，你对于企业应用开发过程中的各种问题，和相对的解决方案，以及方案的各种优缺点，都会有一个完整的了解和认知。

 

更重要的是，你一旦洞悉了这模式背后的规律，你也就对自己的工作，对其他人的工作有了一个更高层次的认知和感悟。你不会再纠结于眼前的这些方法问题，你会超越这些方法和问题，去更高一层看待它们，看它们是否有某种重复性，是否可以进行提炼？这样思考以后，随着工作经验的积累，你就会形成自己的一套架构模式、设计模式，从而真正进入了高手和专家之路。

《卓有成效的管理者》

最后再推荐一本关于管理的书。关于软件开发管理也有很多书，但是管理这件事情其实是有通用性的。软件开发过程中的管理并不特别，这本彼得·德鲁克（Peter F. Drucker）的《卓有成效的管理者》，如下图，讲述了对于知识性、技术性的组织和团队管理中的一些特点和技巧。彼得·德鲁克被认为是管理学大师中的大师，影响了非常多的人，而且彼得·德鲁克并不教条地去讲述那些管理方法和技巧，他认为最好的管理方法、管理技巧其实在小说里，而不是管理学的课本里，管理最重要的就是要洞悉人性，了解人的所求所想，进而利用人的本性，将人有效地组织起来，进行管理。

 

 

而这种理念恰恰是从技术转向管理的工程师、架构师们比较缺乏的，我们做技术的，总以为这个世界是按照某种确定的规律在运行，事物的因果关系是确定的，总以为，我们做成了 A、B、C，那么 D 一定会到来。而事实上，人的关系总是不确定的，管理中的因果关系是非线性的。但是人的关系依然有其内在的逻辑，技术管理者需要从大师的教导中，去理解这种非确定性的逻辑。

总结回顾

软件技术人员在职业生涯中每一次跨越阶层的技术进步，其实都要超越所在阶层的其他 80% 的人，所以这个过程其实是非常艰难的。那么如何去超越同阶层的人，持续不断地获得进步，有几点实践中要注意的事情。

1. 第一是要勇于承担责任，因为通过承担责任才能够真正的洞悉问题和方法，才能够真正的了解自己所在的环境，因为人毕竟是在环境中生活和工作的。

2. 第二持续的训练，通过持续的训练，获得更高层次的技术的感悟和接受能力，但是这种训练是不能重复的。每一次训练都要在上一次训练难度的基础上再提高一点，不要提高太多，只提高一点，也就是所谓摘跳起来够得着的苹果。

3. 在解决问题的过程中要关注问题的场景。因为本质上，方法其实是简单的，技术是简单的，真正困难的是对场景的理解，是对问题本身的理解，要在这个过程中发现真正的问题所在。

我从事软件开发工作 20 多年了，这些年给我最大的感悟就是：一点一滴的知识看起来似乎都是微不足道的，似乎什么也没有改变，但是经过漫长的积累，这些知识点会逐渐构成一个体系，会产生出巨大的威力，或迟或早，会让你跨越一个又一个技术阶层。最重要的是要不停地积累，不停地学习，完成量变到质变的转换。

 

本门架构课中，有些知识可能会立刻对你现在的工作有帮助，而有些知识可能只是在你的心里埋下种子，这些种子可能会在你未来持续的学习积累过程中继续成长，最后在某个时候，在你遇到类似场景问题的时候，结出收获的果实，让你忽然理解顿悟。

 

希望你在将来继续不断学习、成长、思考、实践。我们正处在一个快速变革的时代，各种机会层出不穷，祝你能把握住属于你的机会，实现自己的人生梦想和人生价值。

 

祝福你。

---

精选评论

fengziboboy：

主要是一种思想，一个入门引导，内容不深，但是对于打开思路，架构思维很有用，配合书看，很合适。 一天就能看完，重复看两遍，整理下笔记，基本有个概念。 然后去做项目，配合推荐书目，输出博客。希望自己能坚持下去，感谢。

**强：

讲得太好了，整体课程时间不长，但对架构师的关键技术有清晰的讲解，还有进阶路线、参考书籍，非常实用，谢谢！

*杰：

师父领进门，修行在个人

**巍：

学习了，很有帮助。

**2213：

致敬讲师

**龙：

总体来说，看第一遍有了个大概的认识，受益匪浅。

**威：

撒花 好棒

*建：

学习下来，有所成长，分布式的架构设计，还得继续不断的学习

*星：

已学习，标记

**辉：

学习了。

**生：

很实用 收获很多！对整个系统的架构有了很清晰的认识和定位！