《程序员的修炼——从小工到专家》读书总结（1）—实效的哲学与途径
文章目录如下
工匠精神实效的哲学实效的途径 DRY原则 Code Review 正交性 曳光弹与原型制作 项目周期预估 高效沟通与领域语言作为一名程序员。你怎么看待你所从事的职业？你的职业给你带来了什么？突然想起了《霸王别姬》里的一个片段：漫天飞雪，小生们一遍又一遍的宣誓，触动我心；自古人生于世，需有一技之能；我辈既务斯业，便当专心用功。——把你从事的职业当成一门技艺去磨练。可能这就是工匠精神吧！
程序开发是一门技艺，那你准备如何去磨练？ 一起来看看《程序员的修炼之道—从小工到专家》—Andrew Hunt 怎么说。
首先要认识到软件的熵增；随着时间的推移，若不再持续改进，再好的设计也会过时，再好的软件也会被淘汰。就如前几年很火的SSH框架，现在已经很少有人用了吧？大数据起步时基于MR编程的开发，现在已经基本看不到了吧？同样的，时下大受欢迎的Spark、Flink，你觉得它能继续火多久呢（我觉得还能火很久）？如果把学习一门技能看作投资的话，那度量你投资好坏的重要指标之一就是其对你未来成长的助益大小，以及该技术面向时下与未来的通用程度。新技术层出不穷，而我们能够投入的精力是有限的，当然要选择力所能及、收益最大的去投入了！另一方面，即使新技术层出不穷，但很多底层的原理与运用是不会轻易改变的。比如计算机科学的“四大名著”，哪一部不是“源远流长”？其底层的，万变不离其宗的技术规则是要牢牢掌握的；也正是这些看起来不能直接体现在开发运用中的东西时时刻刻都在运用着，构成了一个程序员之所以称之为程序员的底层竞争架构，我想大家都很热乐意称之为“内功”。再比如说如果你是从事JAVA相关工作的，那JVM是一个非常值得学习的经典技术。 总体而言，若你即将或已进入职场，那越快调整好自己对技术学习的认识、对自身从事行业的认知，收益越大。 学习是一门持续性的投资，想要有长足的积累，那定期投资必不可少。每一段时间都要有一个明确的学习目标，不仅仅是你的专业知识，也应涵盖专业外知识；比如营销、经济、心理学等等。对了，养生也可以考虑考虑。 综上来看，世界这么大，似乎我们能学的东西五花八门，看的有点让人眼花缭乱。大千世界，道路何其之多，何以辨识哪条道对于自身而言才是适合的、正确的呢？这时候，的、得结合自身具体情况进行权衡，这时，批判性思维的重要性就凸显出来了。这往往是个试错的过程，很需要毅力，当然有机会向业界前辈请教的时候一定要把握住。底线是：不能别人说这个好，大家蜂拥而上，自己也随波逐流。独立思考在任何时候都非常重要。
在软件开发里面，有以下实用经验值得借鉴。
DRY原则，Don’t Repeat yourself. 系统中的每一项知识都必须具有单一、权威、无歧义的表示。 重复代码的危害性，有过完整项目开发经历的小伙伴多少有所体会，在此不再过多赘述。 不妨想象一下： 在项目即将完成，临近上线之际，突然有一个需求变更，而已知该功能至少涉及到10个模块的相似代码修改（哦，这糟糕的设计）。啥？为什么会涉及到“10个模块的相似代码修改”？不知道开发中有没有这种体验，在进行模块开发时，明明有一段代码是可以复用的，但因为其复杂性，在运用到具体的功能模块时有各种各样的差别难以调和。似乎多花点时间去思考设计也可以做到抽象复用，奈何基于当前架构设计功力下，项目时间似乎不太允许。这也就导致干脆CP一份进行“复用”，甚至退化到面向过程编程。在这种不良开发背景下，你的需求变更怎么做？后续维护怎么做？重构吧！
定期Code Review 若是项目团队能够定期进行 code review，及时重构现有不合理的代码架构还好。若非如此，诸如上述问题，破窗效应一旦产生，后续涉及到需求变更、版本升级维护，那成本就高了；甚至在极端情况下直接导致项目的失败。 初期设计偷的懒，多半会在后期需求变更维护时加倍还回去。我们知道，在软件开发过程中，错误越晚纠正，所需要付出的成本就越高；一个良好灵活的项目架构设计可以大大减少开发维护的成本。 要避免上述问题说难也不难，说简单也不简单，这不仅是没个人的职责，更是考验一个团队对基本开发原则、设计模式的理解与运用能力（又到了复习设计模式的时候了：设计模式原则（6）开闭原则）。同时要考虑到模块化开发、代码解耦、测试等方方面面的基本功。是不是突然明白为什么好的架构师这么贵了。。。
正交性 何为正交？同一个系统里，若干不相关因素的改变不应该产生联动；其致力于消除无关事物间的互相影响。我们的模块化开发、单元测试、项目分工合作都有正交原则的指导影子，甚至几大设计原则背后的本质、或目标就是提高软件模块间正交性。 正交性的运用往往涉及到项目开发中编程与人员分工合作的问题。编程的正交性问题从以上两项便可举一反三。而针对分工合作，试想在一个项目组里分工不明确会是什么样的一个场景？我曾经有机会经历过，从那以后，不管多困难，我都想方设法的对任务进行划分以避免overlap。分工合作，先有明确的分工，而后才能有好的合作。
曳光弹与原型制作 持续的让用户/PM看到团队的产出 我们知道，曳光弹发出强光而清晰揭示射击轨迹，辅助射手及时调整弹道以方便击中难以瞄准的目标。 在我们项目开发中也往往会用到类似曳光弹的方法。比如原型开发，用较低的成本快速的向用户展示项目预期结果，进而及时获得反馈并进行必要的调整。和曳光弹不同的是，原型一般不会集成到最终项目里，类似于用完就丢的一次用品，很多细节都可以不用考虑，其甚至可以不是代码，而只是白板上的一个速写。曳光弹除了为用户展现、确认项目预期外，还可以继续细化以实现最终的项目，先开发出最简单的前台功能模块，让用户看到效果，后续快速迭代（看起来像是敏捷开发，再加个CICD吧）。
预估项目时间时引入各种不确定性。 你有什么？要产出什么？花费多少时间？ 你需要多少时间完成这项任务？相信大家在工作中经常会遇到这类问题，这就涉及到时间预估了。记住，在开始估算前一定要搞清楚你究竟要做什么，你的scope在哪里。若是有过相关经验还好，若是涉及到某些没有探寻过的领域，你不知道里面存在哪些坑等着你去踩，除了请教相关领域的前辈，最好还要引入不确定性因素。事实上，即使是在一些做过的事情上让我预估时间，我也得引入不确定性因素；“若是XXX都已ready，不出意外的话，YYY天是可以完成的”。不管什么时候，话都不能说满！若是无法在短时间内给出回答，不妨延后回答；“我可以稍后回复你吗？” 当然在平时，也可以有意的去锻炼自己的预估能力。比如记录每次任务预估的准确度，若预估不准确，分析是哪里出了问题，该如何改进。
高效沟通与领域语言 语言的界限就是一个人的界限。 在日常的工作沟通中，总是会不由自主的蹦出一些专业名词。听者能明白还好，一些复杂的概念可以一笔带过。可若是不理解该当如何？即使同为程序员，研究侧重的方向也可能会不一样，别人也不一定能理解你蹦出的这个专业名词代表着什么。可能在你的知识体系下，专业名词P代表着A含义，在别人的知识体系下可能是B含义、C含义，这就导致了沟通上的Gap。还有些情况是，某个专业名词本身的定义就不是很明确，甚至在业界颇有争议。看起来，沟通问题在程序员群体里似乎是很常见的事情，我想，“No bb, show me your code!”，这句话的由来多少也有一些沟通的问题在里面吧。 软件开发，作为世界上最复杂的工程之一，有着浩如烟海的专业术语，或说是领域语言吧。前辈们定义创造了各种各样的领域语言，从我们熟知的Java、C++、Bash，到SQL，再到UML等等都可以算作是领域语言。因为这些领域语言的存在，我们可以更加专业、准确地描述、沟通业务需求。在清晰无误的业务需求驱动下，高效的软件开发才能成为可能。 反观我们的日常开发合作，其实也在不知不绝中定义了一套领域语言。就比如说阿里数仓分层架构（可能好多朋友都有参考过阿里的数仓分层架构），每一层都有其专业表达（ODS、CDM、ADS），在此领域语言背景下讨论数据流的时候是不是直接说专业名词就可以了呢？而不是每次都需要做冗余、费劲的分层阐述。
当然，有时候不得不认识到，人与人之间是存在认知差异的，别人明白不了你的想法是正常的。在确保自己准确表达了自我后，就没必要继续纠结了，若每一个想法别人都能理解，那你还怎么混。再以上预设前提下，我们可以记住一条沟通使用法则：别人需要什么，你有什么？你怎么讲和你讲什么同样重要，甚至更重要！
总结 程序员其实应该好好学一学哲学的，毕竟软件开发本身一边涉及到世界上最复杂的工程，另一边涉及到最难的沟通。如何进行灵活的协调？有时候加一点哲学的智慧未尝不是一个好方法。当然了，诸如编程设计、业务分析、沟通等等基本功是一定要扎实的。
