程序员之路

先感谢你与我一同学完了这部 60 余讲、30 多万字的课程，经过这几个月时间的对微服务、分布式、云原生等话题的学习讨论，估计现在听到这些词汇你也挺累了。在结束语中，我们来聊一点与技术相关，又不局限于具体技术的话题。

原本编辑小姐姐是给了我一篇名为《架构之路没有终点》的命题作文，我想“架构之路”或许多少有一点狭隘，因为并不见得这门课程每一位同学现在或者将来就会成为架构师，但我相信收听这门课程的同学，现在、将来或者至少过去曾经是一名程序员，所以，我们还是来聊一聊“程序员之路”吧。

程序员，字面意思是指编写程序代码的人。但在不少程序员的认知里，今天去写代码，目的却是为了日后可以不必再写代码。程序员的”进阶职业“中，无论是对“顶层设计”、“战略架构”侃侃而谈的架构师和资深专家，还是“从技术走向管理”的研发部门管理者，似乎都已脱离了字面意义上的“写程序代码的人”，作为程序员这个群体的领导者或管理者，理应以治下的程序员能有更高的效率更好的产出作为工作目标和考核依据。

按职业经理人的视角来看，以上是合情合理的，但这种视角下的程序员，恐怕也算得上是最难以管理的职场群体了：工作的过程无法标准化和流水线化，编码的产出指标与质量指标都很难量化地衡量和对比；偏偏写代码这种工作还是一种创造性的脑力劳动，性质决定了程序员必须是一群能独立思考，带有一点天生洁癖，有一点习惯性找茬纠错抬杠的人，领导交办的任务，动辄“这个需求不合理”，要么是”这个功能实现不了”，天哪，怎么会有如此难缠难管的员工？

与此相对的另外一面，业界普遍都认可程序员是相对单纯，不必琢磨复杂人际心思的职场群体，这群人天生带有一种工匠式的图腾崇拜精神，本质上与旧时的小手工业者并没有什么区别，都奉行达者为师，不迷信管理他们的人，但充分尊重能够指导他们的人；都带着些许理工钢铁直男式的直线思维，爱讲逻辑爱讲道理，万一讲不通，起码还能“Talk is cheap, Show me the code”，从这个角度来看，一个对事不对人的、爱讲道理的群体，又怎么可能会难缠难管呢？

久而久之，你对代码、技术、产品状态与团队研发状态的理解，渐渐和团队成员产生了偏差错位，丧失了细节上给予指导的能力，丧失了专业问题上提出接地气解决方案的能力，只能在无法“Show me the code”短期难以校验对错的大战略方向提意见，在会议、流程及团队管理措施上下功夫，在职业经理人式的宣讲与汇报上寻找存在感，此刻，你便从团队的导师变成了管理者，最终你与团队的关系，从携手并肩奋斗的伙伴，完全演变成只能靠公司制度与管理职位的权力来维系雇佣关系。

《架构整洁之道》，第 15 章

Software architects are the best programmers, and they continue to take programming tasks. Software architects may not write as much code as other programmers do, but they continue to engage in programming tasks. They do this because they cannot do their jobs properly if they are not experiencing the problems that they are creating for the rest of the programmers.

软件架构师本身就是最好的程序员，他们会一直编写代码，虽然可能不会像其他程序员输出的代码量那样多，但是只有持续地编程，才能确保他们遇见其他程序员所面对的问题，体会其他程序员心中的感受，因此如果不编程，他们亦将无法胜任软件架构这项工作。

—— Robert C. Martin, 《》, 2018

我很清楚在目前的 IT 业界，只有少量极客文化浓厚的公司会允许少量高端程序员以“独立贡献者（Individual Contributor）”的角色做到高端的职位，绝大多数企业都还是“技而优则仕”，去做管理或者做战略方向的务虚工作，往往是由屁股决定的问题而非由脑袋决定的问题。

我也相信假如能够轻松地做好技术，没有人愿意随便放弃。我所听过的离开技术一线最常见的原因是“年纪大了，时间不够用了”或要“聚焦精力去做管理了”。对这种现象我的看法是：确实很难轻松地做好技术，但是做在好技术工作的前提下，却有可能较为轻松地做好架构和管理工作。

我自己也是一名架构师和管理者，在作自我介绍的场合，用的头衔却从来都是“”，这是一种人设标签。如果你问我为什么管理几十人、几百人的团队的同时，还能抽出时间去编码、去写作、去关注具体的细节与技术的潮流发展，我会理所当然地回答“因为我是一名程序员”啊。这句话的第一层意思是，我是程序员，去编码是天经地义的。另一层意思是，我是程序员，与一群最讲道理、最直来直往、最不需要琢磨小心思的程序员协同工作，管理才不需要耗费太多的精力，因此“兼职管理”才是可行的。

在工作中所需要的知识技能，自己并不感兴趣，该怎么办？
在工作中接触不到的知识技能，是否有必要专门去了解、学习，乃至刻意锻炼？

工作的职责的与自己感兴趣的方向一致、与自己知识体系缺失形成互补，这样的机会可遇不可求。今天的软件业已高度成熟，分工日益细致，对于多数人来说，聚焦在少数几个点上拧螺丝是常态，能够在广袤的舞台上造火箭才是特例。所以，上面两个问题不一定是每位同学都认真思考过，但我相信它应该是每位程序员都实际遇到过的，譬如以下这位同学在课程第一篇中的提问，是否在你的职业生涯中的某个时刻，有过相似的感受？

人生苦短，光阴易逝，把有限的时间和精力投入到对自己最有价值的方向上显得尤为关键，多数人都能接受“选择永远比努力更重要”的观点，但进一步问什么才是好的选择时，就只有少数人能对自己学习的知识技能、从事的工作方向做出定量的价值判断。这里我以上面提问为例，拿出自己的判断模型，供你参考：

知识收益：问题里“架构方面的课程”有不少都属于知识，知识的收益往往是间接的，最终会体现在缩减模型中的“投入成本”因素，即降低（Cognitive Load）上。世界上鲜有“烟囱式”的专业人才，专才的知识体系基本还是“金字塔式”的，在领域里能够显著超过他人高度的前提条件，往往便是拥有着超过他人的知识广度。具体到软件开发中，像计算机体系结构、编译原理、操作系统原理等原理性的知识，对于不写编译器、不开发操作系统的程序员，在实践中几乎找不到直接的应用场景的，但它们毫无疑问是程序员知识体系的基石，是许多实用技能和常见工具溯源的归宿。
花费一定成本去学习这类知识，目的是要将自己的知识点筑成体系，将大量的不同的零散的知识点、通过内化、存储、整理、归档、输出等方式组合起来，以点成线、以线成面，最终形成系统的、有序的、清晰的脉络结构，这就是知识体系。程序员是需要终身学习的群体，当新的信息输入时，如果能在知识体系中快速找到它应该安放的位置，定位它的问题与解题空间，找到它与其他知识点的关联关系，那你接受新信息的认知负荷就降低了，通俗地讲，你就有了比别人更高的学习效率，更敏锐的技术触觉。
提升空间：如果一项工作对你来说是个全新的领域，甚至能称为是一项挑战，那风险的背后往往也蕴含有更高的收益。但我将提升空间归入到价值判断的因素之中，更重要的目的是为了规避舒适区的陷阱。人性会在持续的颓废时发出示警，却容易被无效的努力所欺骗。去做已经完全得心应手的事情，不耗费什么精力，不会觉得痛苦困难，如果把它当作打游戏看电影般的娱乐消遣，放松自己是合适的，但不应该再指望从中追求什么价值。
没有价值，是因为提升空间是可以下降至零，但投入成本不可能为零，因为成本中不仅包括精力，还包括时间，花时间重复去做已经完全熟练的事情，相当于计算分子为零的算式，结果必然是没有价值的。

以上便是我的价值判断模型，每个人都应该有属于自己的价值观，你可以参考，却不必与谁的一致；也并不是提倡凡事将价值判断当作公式去进行计算，而是希望你能养成一种类似的思维习惯。

前两部分谈的是发展观、价值观这种大方向的话题，本文的最后，我想以一个具体的可操作的小话题来结束这篇结束语——程序员应该如何构筑自己知识体系？同时也向大家汇报解释，为何这门课程会是一门公益课。

我所践行的知识整理方法是“将思考具象化”，思考本是外界不可知的，其过程如何、其结果如何只有你自己心里才清楚。如果不把自己思考的内容输出给他人，很容易就会被自己所欺骗，误以为自己已经理解得足够完备了。

开篇中，我便提到了撰写这门课程的目的：做技术不仅要去看、去读、去想、去用，更要去说、去写。将自己“认为掌握了的”知识叙述出来，能够说得清晰有条理，讲得理直气壮；能够让他人听得明白，释去心中疑惑；能够把自己的观点交予别人的审视，乃至质疑，在此过程之中，会挖掘出很多潜藏在“已知”背后的“未知”。

这门架构课里，我不仅在探讨架构的知识与技术，也很希望能够将自己如何思考、整理、构筑知识体系的方法展示出来。在留言中曾有同学将它总结为“用输出来倒逼输入”，我看了心中觉得颇感知音，在此，一并感谢各位同学的支持与同行。