靠谱的工程师都是相似的——《程序员修炼之道》读书笔记

《程序员修炼之道（第1版）中文版》，2005年，

豆瓣评分：8.7 分，

《程序员修炼之道（第2版）中文版》，2020年

豆瓣评分：9.1 分，

新书遗漏的内容

下面这段内容仅在作者的早期手稿里出现过，但最终版把它删除了。但是，我比较赞同这一观点，所以在这里补上。（本书译者 云风 提供）

你是否注意到，一些项目团队非常高效，每个人都知道该做什么，并做出了充分的贡献；而其他一些团队的成员却总是争吵不休，似乎无法相互谦让？通常这就是一个正交性问题。

当团队组织重复到架屋迭床时，成员会对职责感到困惑。每修改一个东西都需要整个团队开会，因为修改会影响每个人。

如何才能将团队组织成职责明确、重叠最少的不同小组？没有简单的答案。这一定程度上取决于具体项目，以及你对可能发生变化区域的分析；同时还取决于你能调用的人手。

我们的首选做法是：首先，将基础设施从应用程序中分离出来，让每个主要的基础设施组件（数据库、通信接口、中间件层等）都有自己的子团队，让应用程序中特别明显的不同功能都能简单地分开。然后，再查看我们拥有（或计划拥有）的人员，并相应地调整分组。 

有一个通俗的方法，可以用来评估项目团队结构的正交性——只需简单看看，在讨论每个修改时，有多少人需要参与进来。人数越多，组织的正交性越差。显然，一个正交的团队更有效率。（话虽如此，我们还是鼓励子团队间保持相互沟通。

写在前面

我的反思

一般来说，刚刚接触编程的人，更倾向于从具体的程序代码学习编程的理念，而不是从程序设计理论书籍去理解编程的概念。就像学习英语，在刚开始的时候，最重要的是扩大自己的阅读量和词汇量，而不是“钻研”各种奇技淫巧。

入门阶段

本书的阅读体验

The Pragmatic Programmer（以下简称TPP）这本书，就是在自我提升阶段，值得反复阅读的绝好的书籍。这本书里面涉及到了在软件开发中的方方面面，它用非常短小的篇幅，覆盖了非常大的范围（事实上，这是我看过的覆盖面最广的有关程序员技术的书籍）：

• 从正确的理解需求到灵活的设计实现；

• 从估算/提升程序的运行效率到提升软件的开发效率；

• 从程序员的自身修养到与他人交流时的tips。

传统的计算机书籍一般采用自下而上，由浅至深，循序渐进的方法来讲述计算机理论。

这本书的组织结构显得比较松散，章节之间相对独立，这使得“随机阅读”成为可能：你可以随便的翻到某一章直接阅读，而有联系的章节均在每一节末尾给出。每一节里面都有一两个起到概括全文作用的Tips，这些Tips都是前辈经验的结晶，需要被牢记。和代码大全2里的Checklist相类似，TPP把全书出现的70个Tips整合到一起，放在了书末尾，以便查阅。

本书的内容

第一节：我的源码让猫给吃了。

1、开发过程中出现未曾预料的技术问题，交付晚了等情况，没关系，这些是无法避免的。发生了，我们就要尽可能想方设法地职业的去处理它们。程序员这个职业需要诚实和坦率，要敢于承认自己的错误。

2、要对担负的东西负责，如果某些东西真的超出了你的控制范围可以不处理，需要尽早提出这个不可控的点。自己职责所在的事情就需要为其结果负责。当结果不达标，比如磁盘垮了，但你却没有备份代码，那这就是你的错。不要为出错的情况找借口，想老板说"我的源码让猫给吃了”，对问题没有任何帮助，而要向他们提供可行的解决方案，做什么能够最大的挽回局面。

第二节：软件的熵

1、熵是一个热力学概念，指的是在某个系统中的“无序”的总量，热力学定律指出宇宙中的熵总是倾向于最大化。软件工程里中也存在这么一个定律，工程越庞大，代码的“无序”状态越严重。

2、破窗理论指出，当一个东西本身就破旧时，不但没人爱惜，还会朝他仍石头，导致更多破窗。软件开发中也一样，如果我们项目留有很多“破窗户”（低劣的设计、错误的决策、糟糕的代码），之后接手的人也会倾向于是它变得更糟糕。如果代码很漂亮，你自己以及之后接手的人，都可能会格外注意，不把它弄脏的。所以我们应该尽早处理工程中遗留的问题。

第三节：石头汤和煮青蛙

1、三个士兵返乡，路上饿了，路过一个村子，想跟村民借点吃的，但村民粮食贫乏不愿意出借。士兵们没有气馁，他们煮开了一锅水，往里面放了几块石头。村民好奇为他们在干嘛，士兵解释，这叫石头汤，如果能放点胡萝卜的话会更好喝。村民跑回家拿来了胡萝卜，士兵说如果放些土豆会更美味，又有人跑回家带来了土豆。后面又有人加了别的东西，最后士兵和大家一起吃了一顿饱饭。

2、有时候你确切的知道自己需要什么以及怎么做，但请求许可这件事往往会遭遇拖延和漠然，每个人都会护卫他们自己的资源，这让事情变得复杂，这叫“启动杂役”（start-up fatigue）。这时候我们不应该等着所有事情都准备好，而应该先拿出“石头”煮起来，就是想让事情启动起来。只要是有益的事情，你把做出的一部分结果拿给别人看，然后告诉他们如果加的别的什么会更好，大家一般都会帮忙的。

第四节：足够好的软件

1、使质量成为需求问题。很多时候对于质量的评估都是开发人员在进行，我们对质量要求低，交付时会出现很多问题，我们对质量要求高，会很大程度延误工期。所以指定需求时，把质量这一块考虑进去，在商定的时间内，由产品或者客户决定他们可以接受的质量是什么样的。

2、没有完美的软件，应该知道何时止步。今天了不起的软件常常比明天的完美软件更可取。及早让客户使用，他们的反馈常常会把你引向更好的解决方案。

还有更多内容，请阅读原书吧～

本书的遗憾

《程序员修炼之道》就是程序员的《九阳真经》，它理应成为程序员放置手边时时翻阅、研读、参照的枕边书，字典书、信仰之书。

然而，由于篇幅所限，TPP在介绍程序设计的理念及原则时，都是「点到为止」，也就是说，TPP只提供了一个通往成为注重实效的程序员的前进方向，而具体的细节，则需要你在工作中，或者进一步阅读相关书籍来把握。

参考链接：https://blog.csdn.net/broadview2006/article/details/119734814