116 lines
12 KiB
Markdown
116 lines
12 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
结束语 _ 程序员之路
|
||
你好，我是周志明。
|
||
|
||
到这里，我们的软件架构之旅就要到终点站了，首先感谢你与我一起学完了这门70多讲、30多万字的课程。
|
||
|
||
这门课讲的是软件架构，不过这并不意味着你学完这门课程就要做架构师。我想，在座的同学在现在、将来或者至少过去曾经是一名程序员，所以在结束语中，我想来跟你聊一点儿与技术相关，但又不局限于具体技术的话题。
|
||
|
||
程序员的发展观
|
||
|
||
程序员通俗地说就是写程序代码的人，但在不少人的认知里，今天去写代码，却是为了日后可以不必再写代码。
|
||
|
||
从职业经理人的视角来看，不管是架构师、资深专家，还是研发部门管理者，这些程序员的“进阶职业”似乎都已经脱离了字面意义上的“写代码的人”，衡量他们工作目标的依据主要是治下的程序员是否有更高的工作效率、更好的投入产出。那么如此一来，不少程序员想成为“不必再写代码”的人，倒是也可以理解。
|
||
|
||
不过，从技术人员的视角来看，程序员这个群体天生就带有一种工匠式的图腾崇拜精神，大家都奉行达者为师，并不迷信管理自己的人，但尊重能够指导自己的人，爱讲逻辑、爱讲道理，讲不通至少还能“Talk is cheap, show me the code”。而如此一来，要脱离技术去管理好一群程序员，可是相当困难的。
|
||
|
||
其实，我之所以说这些，是希望以后无论你的职业目标是永远做一名程序员，还是架构师，或者是成为一名研发管理者，都不要轻易地离开技术领域的一线。
|
||
|
||
离开技术、放弃编码的决定，很可能会像你高考之后放下的数学、生物、地理等知识那样，一旦放手，以后就很难有机会再重新捡起来。
|
||
|
||
久而久之，你对代码、技术、产品状态与团队研发状态的理解，就会渐渐和团队成员产生偏差错位，从而丧失在细节上给予指导的能力，丧失在专业问题上提出接地气解决方案的能力，只能在短期内无法验证对错的大战略方向上提意见，在会议、流程及团队管理措施上下功夫，在职业经理人式的宣讲与汇报上寻找存在感。
|
||
|
||
如果是这样，那么你就从团队的导师变成了管理者，最后你跟团队的关系，就会从携手并肩奋斗的伙伴，完全演变成了只能靠公司制度与管理职位的权力来维系的雇佣关系。
|
||
|
||
当然我也相信，假如能够轻松地做好技术，也没有人愿意随便放弃。我听过的离开技术一线最常见的原因，就是“年纪大了，时间不够用了”或者要“聚焦精力去做管理了”。对这种现象，我的看法是：确实很难轻松地做好技术，但是在做好技术工作的前提下，却有可能比较轻松地做好架构和管理工作。
|
||
|
||
我自己也是一名架构师和管理者，在作自我介绍的场合，用的头衔却从来都是“兼职一些管理工作的程序员”，这是一种人设标签。如果你问我，为什么管理几十人、几百人的团队的同时，还能抽出时间去编码、去写作、去关注具体的细节与技术的潮流发展，我会理所当然地回答，“因为我是一名程序员”啊。
|
||
|
||
这句话的第一层意思是，我是程序员，去编码是天经地义的。另一层意思是，我是程序员，与一群最讲道理、最直来直往、最不需要琢磨小心思的程序员协同工作，管理才不需要耗费太多的精力，所以“兼职管理”才是可行的。
|
||
|
||
程序员的价值观
|
||
|
||
聊完编程与程序员的发展观，我们再来探讨两个关于程序员价值观方面的问题：
|
||
|
||
|
||
在工作中所需要的知识技能，自己并不感兴趣，该怎么办？
|
||
在工作中接触不到的知识技能，有没有必要专门去了解、学习，乃至刻意锻炼？
|
||
|
||
|
||
我们知道，工作的职责能跟自己感兴趣的方向一致、能跟自己知识体系的缺失形成互补，这样的机会是可遇不可求的。今天的软件业已经高度成熟了，分工日益细致，对于大多数人来说，聚焦在少数几个点上拧螺丝是常态，能够在广袤的舞台上造火箭才是特例。
|
||
|
||
所以，前面两个问题不一定是每位同学都认真思考过，但我相信它应该是每位程序员都实际遇到过的。比如，有位同学就在课程开篇词中提了一个问题，不知在你的职业生涯中的某个时刻，是不是也有过相似的感受：
|
||
|
||
|
||
周老师，想了解一下你之前是怎样从业务往架构转型的？我是工作两年的小白，一直都很想学习架构方面的课程，但是由于工作全是业务逻辑，而且是极其复杂繁琐的业务，每天都是对着协议研究业务实现，感觉自己都困在业务里面无法自拔。
|
||
|
||
|
||
人生苦短，光阴易逝，把有限的时间和精力投入到对自己最有价值的方向上显得尤为关键，大多数人都能接受“选择永远比努力更重要”的观点，但进一步问“什么才是好的选择”时，就只有少数人能对自己学习的知识技能、从事的工作方向做出定量的价值判断。
|
||
|
||
所以，这里我就以这位同学的问题为例，拿出自己的判断模型，供你参考：
|
||
|
||
|
||
价值 = (技能收益 + 知识收益) × 提升空间 / 投入成本
|
||
|
||
|
||
技能收益
|
||
|
||
刚刚的问题里提到的“每天都是对着协议研究业务实现”，就属于典型的技能，它往往代表着直接收益。
|
||
|
||
我认为，一项工作中每天都要用到的技能，不管你是否感兴趣，都值得花一些时间精力去掌握，因为它至少是对你短期的利益起到了明确的支撑作用；反之，永远都不会派上用场的屠龙术，再高大上也是水月镜花。
|
||
|
||
所以，正视技能收益的意义就在于可以避免自己变得过度浮躁，而不是用“兴趣不合”“发展不符”之类的借口去过度挑剔。
|
||
|
||
我也提倡兴趣驱动，提倡快乐工作，但不设前提条件的兴趣驱动就未免太过“凡尔赛”了。首先在社会中务实地生存，不涉及是否快乐，先把本分工作做对做好，再追求兴趣选择和机遇发展，这才是对多数人的最大的公平。
|
||
|
||
知识收益
|
||
|
||
问题中提到的“架构方面的课程”，有不少都属于知识。知识的收益往往是间接的，它最终会体现在缩减了模型中的“投入成本”因素，即降低认知负荷（Cognitive Load）上。世界上鲜有“烟囱式”的专业人才，专才的知识体系基本还是“金字塔式”的，这些人在领域里能够显著超过他人高度的前提条件，往往就是他们拥有超过他人的知识广度。
|
||
|
||
而具体到软件开发中，像计算机体系结构、编译原理、操作系统等原理性的知识，对于不写编译器、不开发操作系统的程序员来说，在实践中是几乎找不到直接的应用场景的。可是毫无疑问，这些知识就是程序员知识体系的基石，是许多实用技能和常见工具溯源的归宿。
|
||
|
||
我们花费一定的成本去学习这类知识，目的是要把自己的知识点筑成体系，把大量的、不同的、零散的知识点，通过内化、存储、整理、归档、输出等方式组合起来，以点成线、以线成面，最终形成系统的、有序的、清晰的脉络结构，这就是知识体系。
|
||
|
||
程序员是需要终身学习的群体，当有新的信息输入时，如果能在知识体系中快速找到它应该安放的位置，定位它的问题与解题空间，找到它与其他知识点的关联关系，那你接受新信息的认知负荷就降低了。通俗地讲，你就有了比别人更高的学习效率，更敏锐的技术触觉。
|
||
|
||
提升空间
|
||
|
||
如果一项工作对你来说是个全新的领域，甚至能称为是一项挑战，那风险的背后往往也蕴藏着更高的收益。但我把提升空间归入到价值判断的因素之中，更重要的目的是规避舒适区的陷阱。
|
||
|
||
人性会在持续的颓废时发出示警，却也容易被无效的努力所欺骗。我们去做一些已经完全得心应手的事情时，自然不会耗费什么精力，也不会觉得痛苦困难，如果把它当作打游戏看电影般的娱乐消遣，放松自己是合适的，但我们不应该再指望从中追求什么价值。
|
||
|
||
而没有价值，是因为提升空间已经下降到零了，可我们要注意，其中的投入成本根本不可能为零，因为成本中不仅包括精力，还包括时间。花时间重复去做已经完全熟练的事情，相当于计算分子为零的算式，结果自然是没有价值的。
|
||
|
||
投入成本
|
||
|
||
在这门架构课程中，我经常讲的一个词是“权衡”，经常说的一句话是“凡事不能只讲收益不谈成本”。在我的价值模型里，收益大小也是必须在确定的成本下，才有衡量比较的意义。这里的成本，既包括你花费的时间、金钱与机会，也包括你投入的知识、精神与毅力。
|
||
|
||
强调投入成本，是希望你不要去钻牛角尖。如果一项知识或技能，你学习起来非常吃力，花费大力气弄懂之后，过一段时间却又迅速地忘掉了，这很可能是因为你既没有实际应用它的场景，也没有在知识体系中建立好掌握它的稳固的前置基础。这种就属于你目前还拿不动的东西，不如趁早放手，先做好减法，才能做好加法；你也不必觉得可惜，如果它对你来说是必要的，就一定还会再次出现，想躲也躲不掉。
|
||
|
||
好了，这就是我的价值判断模型，每个人都应该有属于自己的价值观，你可以参考，但不必非得跟谁的一致。我也并不是提倡凡事都要把价值判断当成公式一样去计算，而是希望你能养成一种类似的思维习惯。
|
||
|
||
将思考具象化
|
||
|
||
前面我谈论的是发展观、价值观这种大方向的话题，最后，我想以一个具体可操作的小话题来结束这篇结束语：程序员应该如何构筑自己知识体系？顺便我也跟你解释一下，为何这门课程会是一门公开课。
|
||
|
||
我践行的知识整理方法是“将思考具象化”。因为我们知道，思考这件事是外界不可知的，其过程如何、其结果如何只有自己心里才清楚。如果不把自己思考的内容输出给他人，很容易就会被自己所欺骗，误以为自己已经理解得足够完备了。
|
||
|
||
在开篇词中，我提到过做这门课程的目的：做技术不仅要去看、去读、去想、去用，更要去写、去说。把自己“认为掌握了”的知识给叙述出来，能够说得条理清晰，讲得理直气壮；能够让别人听得明白，释去心中疑惑；能够把自己的观点交给别人的审视，乃至质疑。在这个过程中，就会挖掘出很多潜藏在“已知”背后的“未知”。
|
||
|
||
这个目的也是它成为免费公开课的原因：课程本身就是我对自己知识体系整理的成果，是我思考的具象化表现，在这件事情中，我自己是最大的受益者，而其后所做的极客时间课程，以及出版的纸质书籍，都可以算是额外的收获。这样看来，经济上的回报也就不那么重要了。
|
||
|
||
实际上，在这门架构课里，我不仅在探讨架构的知识与技术，也很希望能够把自己如何思考、整理、构筑知识体系的方法展示出来。之前的用户故事中，詹同学把它总结为“用输出来倒逼输入”，我看了心中觉得颇感知音。在此，一并感谢每位同学的支持与同行。
|
||
|
||
最后我想说的是，课程结束并非终点，我们还可以在留言区互动交流，也祝你享受成长，学有所成。另外，我准备了一份毕业问卷，希望你能花两三分钟填写一下，我也非常期待听到你对这门课的反馈。
|
||
|
||
就到这里，我们再会！
|
||
|
||
|
||
|
||
|
||
|
||
|