程序员之路

程序员之路

音频公开课

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

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

程序员的发展观

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

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

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

Talk is cheap. Show me the code.
屁话少说，放”码”过来。

—— Linus Torvalds, Re: SCO: “thread creation is about a thousand times faster than onnative”, 2000

以上这些，是希望无论日后你的职业目标是永远做一名程序员，还是架构师，抑或是成为一名研发管理者，都不要轻易地离开技术领域的一线前沿，离开技术、放弃编码的决定很可能会像你高考之后放下的数学、生物、地理等知识那样，一旦放手，毕生就很难有机会再重新捡起来。

久而久之，你对代码、技术、产品状态与团队研发状态的理解，渐渐和团队成员产生了偏差错位，丧失了细节上给予指导的能力，丧失了专业问题上提出接地气解决方案的能力，只能在无法“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, 《Clean Architecture》, 2018

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

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

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

程序员的价值观

聊完编程与程序员、架构师、管理者的发展，我们再来探讨两个程序员价值观方面的问题：

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

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

周老师，想了解一下你之前是怎样从业务往架构转型的？我是工作两年的小白，一直都很想学习架构方面的课程，但是由于工作全是业务逻辑，而且是极其复杂繁琐的业务，每天都是对着协议研究业务实现，感觉自己都困在业务里面无法自拔。

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

价值 = (技能收益 + 知识收益) × 提升空间 / 投入成本

技能收益：问题里“每天都是对着协议研究业务实现”就属于典型的技能，它往往代表着直接收益。一项每天工作都要用到的技能，无论你是否感有趣，都值得花一些时间精力去掌握，它至少对短期利益起到了明确的支撑作用；反之，永远都不会派上用场的屠龙术，再高大上也是水月镜花。
正视技能收益的意义在于避免自己变得过度浮躁，以“兴趣不合”、“发展不符”为借口去过度挑剔。我也提倡兴趣驱动，提倡快乐工作，但不设前提条件的兴趣驱动就未免太过“凡尔赛”了，首先在社会中务实地生存，不涉及是否快乐，先把本分工作做对做好，再追求兴趣选择和机遇发展，这才是对多数人的最大的公平。
知识收益：问题里“架构方面的课程”有不少都属于知识，知识的收益往往是间接的，最终会体现在缩减模型中的“投入成本”因素，即降低认知负荷（Cognitive Load）上。世界上鲜有“烟囱式”的专业人才，专才的知识体系基本还是“金字塔式”的，在领域里能够显著超过他人高度的前提条件，往往便是拥有着超过他人的知识广度。具体到软件开发中，像计算机体系结构、编译原理、操作系统原理等原理性的知识，对于不写编译器、不开发操作系统的程序员，在实践中几乎找不到直接的应用场景的，但它们毫无疑问是程序员知识体系的基石，是许多实用技能和常见工具溯源的归宿。
花费一定成本去学习这类知识，目的是要将自己的知识点筑成体系，将大量的不同的零散的知识点、通过内化、存储、整理、归档、输出等方式组合起来，以点成线、以线成面，最终形成系统的、有序的、清晰的脉络结构，这就是知识体系。程序员是需要终身学习的群体，当新的信息输入时，如果能在知识体系中快速找到它应该安放的位置，定位它的问题与解题空间，找到它与其他知识点的关联关系，那你接受新信息的认知负荷就降低了，通俗地讲，你就有了比别人更高的学习效率，更敏锐的技术触觉。
提升空间：如果一项工作对你来说是个全新的领域，甚至能称为是一项挑战，那风险的背后往往也蕴含有更高的收益。但我将提升空间归入到价值判断的因素之中，更重要的目的是为了规避舒适区的陷阱。人性会在持续的颓废时发出示警，却容易被无效的努力所欺骗。去做已经完全得心应手的事情，不耗费什么精力，不会觉得痛苦困难，如果把它当作打游戏看电影般的娱乐消遣，放松自己是合适的，但不应该再指望从中追求什么价值。
没有价值，是因为提升空间是可以下降至零，但投入成本不可能为零，因为成本中不仅包括精力，还包括时间，花时间重复去做已经完全熟练的事情，相当于计算分子为零的算式，结果必然是没有价值的。
投入成本：在这门架构课程中，我经常讲的一个词是“权衡”，经常说的一句话是“凡事不能只讲收益不谈成本”，在我的价值模型里，收益大小也是必须在确定的成本下才有衡量比较的意义。这里的成本，既包括你花费的时间、金钱与机会，也包括你投入的知识、精神与毅力。
强调投入成本，是希望你不要去钻牛角尖，如果一项知识或技能，你学习起来非常吃力，花费大力气弄懂之后过一段时间却又会迅速遗忘掉，这很可能是因为你既没有实际应用它的场景，知识体系中也没有建立好掌握它的稳固的前置基础。这种就属于你目前还拿不动的东西，不妨趁早放手，先做好减法，才能做好加法；也不必觉得可惜，如果它对你来说是必要的，一定还会再次出现，想躲也躲不掉。

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

将思考具象化

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

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

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

这个目的也是它成为免费公益课的原因：课程本身就是我对自己知识体系的整理的成果，是我思考的具象化表现，这件事情中，我自己是最大的受益者，其后的极客时间课程，以及出版的纸质书籍，都可算是额外的收获，这样看来，经济上的回报也就不那么重要了。

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