我读过……《程序员修炼之道》

真是经典之作。对于程序员，甚至是管理程序员的人来说，这绝对是一本必读之书。《实用程序员》最初于1999年出版，是一本关于如何成为一名实用程序员——真正专业的程序员——的书。尽管这本书出版于二十年前，但看到我们每天仍然面临的困境，即使在那时仍然被讨论，这令人着迷。

刚开始读这本书的时候，我以为里面会有很多技术细节和经验教训，这大概也是我一直回避这本书的原因之一。毕竟这本书已经是二十年前的旧书了，在如今科技飞速发展的今天，技术细节更新换代的速度已经很慢了。但这本书真正关注的是程序员职业生涯中最具挑战性的部分：编写可扩展、可维护的软件，并最终成为专业人士。

其中有代码片段，但作者知道这些代码和技术几年后就会过时，所以这本书并没有过多关注它们。

总的来说，本书作者试图传达的内容并没有太多出人意料之处。任何热爱自己的技术、不惧变化且拥有多年经验的程序员都应该了解本书探讨的许多主题。在我看来，大多数程序员都知道本书所倡导的指导方针，但他们也总是很快找到借口去忽略它们。

《实用程序员》主要关注如何使用软件有效地解决问题以及如何务实地成长为开发人员；不仅要教你如何成为一名优秀的程序员，还要教你如何解决围绕编码的复杂问题，例如：

• 通过DRY（不要重复自己）和YAGNI（你不需要它）编写干净的代码
• 如何评估软件交付。
• 当其他人犹豫不决时如何做出改变。
• 作为开发人员如何对抗停滞。
• 如何通过自动化和测试使软件流程具有弹性和高效。

这些例子和解释并不抽象或牵强，而是你在行业中可以看到的一些现实世界的应用（尽管有些东西已经过时了）。

我将要讲的这本书的一些重要观点如下：

• 我们应该对我们的准则和决定负责。
• 不要让破损的窗户不去修理。
• 批判性思考
• 了解你的工具
• 精心编程和重构
• 使用版本控制
• 测试代码
• 自动化一切

亨特和托马斯表示，上面列表中的最后三件事是实用入门套件的精髓，它们应该成为支撑每个项目的三大支柱。

责任

当你对某件事负有责任时，你应该做好承担责任的准备。如果你犯了错误，无法履行这些责任，你必须弥补并找到解决方案。不要找借口，也不要互相指责。当你犯错（人非圣贤，孰能无过）或判断失误时，要诚实地承认，并尝试提出替代方案。不要把所有问题都归咎于供应商、编程语言、管理层或你的同事。这些因素都可能造成影响，但你应该提供解决方案，而不是找借口。

在你完全确定某件事正确之前，不要主动告诉别人你做不到。此外，不要只是说你做不到，好像一切都结束了一样。相反，要提供一些替代方案，并解释如何才能挽救局面。

正如本书的作者所说：

在大声说出那些站不住脚的借口之前，试着先把它们剔除。你的借口听起来合理还是愚蠢？你的老板会怎么想？(...) 如果必须说，先告诉你的猫。

窗户破损

书中有一个故事，关于研究破窗对城市地区的影响：

一扇破窗，长期无人修复，会让楼内居住者产生一种被遗弃的感觉——觉得当权者根本不关心这栋楼。于是，又一扇窗户被打破。人们开始乱扔垃圾，涂鸦开始出现。严重的结构损坏开始出现。在相对较短的时间内，这栋楼的损坏程度已经超出了业主想要修复的程度，被遗弃的感觉变成了现实。

我们程序员可能在某些代码库中见过这种情况。看到一些有问题的代码，觉得可以忽略不计。等到工作量不够时，我们才会回来修复。但不幸的是，这只是代码质量下降和严重技术债务的第一步。一个破窗之后，其他破窗会开始更频繁地出现，而这通常就是开发人员开始寻找新工作的时候，留下一堆垃圾。

所以，（请务必）不要让“破窗”（糟糕的设计、错误的决策或糟糕的代码）置之不理。一旦发现，请立即修复。如果时间不够，请创建工单，尽可能修复最严重的问题，注释掉代码，或留下一条令人痛心的评论。最终，您应该采取行动，防止进一步的损害，并表明您已经掌控了局面。

不要陷入旁观者效应，指望其他开发者会解决问题。相反，要主动出击，成为变革的催化剂。

批判性思考

你应该批判性地思考你所读到和听到的内容。你需要确保你的知识和观点不受供应商或媒体炒作的影响。要警惕那些坚持认为他们的解决方案是唯一答案的销售人员；这个方案可能适用于你和你的项目，也可能不适用，或者他们可能只是想向你兜售骗人的“万灵药”。

当你想要弄清楚某件事的真相时，尝试询问并思考以下问题：

• 问“五个为什么” ——提出一个问题，得到一个答案。然后，再问一个“为什么？”，深入挖掘问题。只要合理，就重复这个问题。这样你或许能更接近问题的根本原因。
• 这对谁有好处？ ——这听起来可能有些愤世嫉俗，但追踪金钱可能是一条有用的分析途径。
• 背景是什么？ ——所有事情的发生都有其背景，这就是为什么“一刀切”的解决方案往往行不通。值得思考的问题是“对谁最有利？” 先决条件是什么？短期和长期后果是什么？
• 这在何时何地有效？ ——在什么情况下？不要停留在一阶思维（接下来会发生什么），而要运用二阶思维：之后会发生什么？
• 为什么这是个问题？ ——是否存在底层模型？底层模型是如何运作的？你是否也遇到过同样的问题？

了解你的工具

这看似简单的建议，但我们日常工作中却充斥着各种各样的工具。我当然不了解我所使用的每一种工具的来龙去脉。

例如，几天前，我了解了git add --patch功能，它允许我们仅暂存部分已更改的文件。

虽然我不确定是否应该尽可能多地学习我们用于开发的工具，但学习那些能提高效率的东西绝对是你应该努力的方向。例如，关注你的日常流程，看看你最常执行的手动操作是什么。然后看看这些操作是否可以自动化或以某种方式改进。

这本书告诉我们，在开始开发之前，找到合适的工具至关重要。必备工具不仅指 IDE，还包括编程语言和服务。你对不同技术越熟悉，你的视野就越开阔。

所以，在盲目开始编码之前，请先退一步。首先要理解为什么需要构建这个问题或手头的功能。接下来，找到合适的工具，然后开始编码。

一些作者的建议：

• 所有内容都使用纯文本。避免使用二进制格式（例如 MS Word）来保存信息。
• 学习一些脚本语言以便用它来进行文本操作（Js，Ruby，Python）。
• 学习 shell（awk、grep 等）
• 配置你的点文件并定期备份

精心编程和重构

面对模糊性，拒绝猜测的诱惑。

警惕过早优化。在投入宝贵时间尝试改进算法之前，务必先确认该算法是否存在瓶颈。代码越少，出现 bug 的可能性就越小。

始终保持清醒的头脑——如果你不了解所实现功能的背景，你可能会陷入错误的假设。不要盲目地复制/粘贴你不理解的代码，也不要像本书作者所说的那样，进行散弹枪式编程或巧合式编程。例如，假设你不知道你的程序为什么或如何工作。在这种情况下，你很可能会陷入一种无法理解代码为何失败的境地，这通常会导致你花费大量时间去研究这段代码，直到你（如果）知道它最初是如何工作的。

上述问题的一个试金石是——你能向初级程序员解释你的代码吗？如果不能，也许你只是在依赖巧合。

正如上一节所述，不要立即开始编写代码。相反，要制定一个计划，即使它只是在编辑器中以注释形式或餐巾纸上写下的待办事项清单。之后，优先考虑问题的复杂部分，确定工作的优先级。

不要成为历史的奴隶，这意味着你不应该让现有的代码决定未来的代码。所有代码如果不再合适，都可以被替换。即使在一个程序中，也不要让已经完成的事情限制你下一步的工作，做好重构的准备，但请记住，这个决定可能会影响项目进度。这里的假设是，重构的影响将小于不进行更改的成本。

Martin Fowler将重构定义为：

对软件内部结构进行的改变，使其更易于理解且修改成本更低，而无需改变其可观察的行为。

该定义的关键部分是：

1. 它是重组代码的过程，使其更易于使用、更清洁，并消除代码异味。
2. 外部行为没有改变；现在不是添加功能的时候

为了保证外部行为没有改变，您需要良好（最好）的自动化单元测试来验证代码的行为。

使用版本控制

这条建议听起来有点过时，但还是值得一提。如今的软件开发环境与二十年前大不相同，至少在版本控制方面是如此。版本控制git在开发流程中根深蒂固，我自己也无法想象没有版本控制的项目会是什么样子。

此外，本书建议对我们认为重要的一切事物（例如笔记和文档）使用版本控制。

我的看法是，除了版本控制之外，您还应该努力保持 git 历史记录干净且可搜索（例如，通过使用语义提交），并尽可能利用 VCS 进行自动化。

测试代码

这又是一个常识性的建议。然而，在大多数情况下，它并没有得到应有的重视。二十年前，测试很重要，但如今，考虑到越来越多的程序一旦发生故障就可能迅速 导致 人员死亡，测试就显得尤为重要。

本书作者甚至建议，测试代码应该比程序源代码更大，并且我们应该像对待任何生产代码一样谨慎地对待测试代码。保持测试代码的解耦、简洁和健壮。不要依赖不可靠的东西，例如 GUI 系统中页面的绝对位置、服务器日志中的精确时间戳或错误消息的精确措辞。测试这些内容会导致测试变得脆弱（不稳定）。

务实的程序员会严格测试他们的代码。编写测试代码所花费的时间是值得的，因为从长远来看，这样做成本更低，而且更有可能生产出几乎零缺陷的产品。

自动化一切

自动化是成为务实程序员的核心原则。你应该找出你或你的团队成员一直在做的手动任务，并将它们自动化。自动化可以减少人为失误的可能性，并显著改善流程。

自动化还能与实用入门套件的另外两个“支柱”——版本控制和测试——完美契合。您应该自动化流程，对 VSC 变更进行测试，如果足够稳定，甚至可以按需将代码部署到生产环境中。

你自动化的东西越多，你就越有时间专注于解决真正的问题。但是！不要掉入自动化那些不值得付出努力的事情的陷阱。

务实的团队

“商业上的伟大成就从来不是一个人完成的，而是由一个团队完成的。”
——史蒂夫·乔布斯

团队作为一个整体，不应该容忍破窗——那些无人修复的细微瑕疵。相反，团队必须对产品的质量负责。

最后，书中提到，作为个人，我们应该为自己的工作感到自豪，并在其中留下自己的印记。然而，在团队合作中，我们仍然需要平衡这一点，避免偏袒自己的代码而歧视同事。你不应该嫉妒地捍卫自己的代码免受入侵者的侵害，而应该尊重他人的代码。黄金法则（“己所不欲，勿施于人”）以及开发人员之间相互尊重的基础对于实现这一点至关重要。

匿名性很容易滋生马虎、错误、懒惰和糟糕的代码，尤其是在大型项目中。你很容易把自己看作机器上的一个齿轮，在无休止的状态报告中找一些蹩脚的借口，而不是写出好的代码。

虽然代码必须归个人所有，但不必由个人拥有。事实上，Kent Beck 的《极限编程》一书就建议代码集体所有（但这也需要一些额外的实践，例如结对编程，以防范匿名的风险）。

归根结底，作为一名务实的程序员，你希望自己的职业生涯能够得到其他人的认可。他们看到你构建的功能或程序，并期望它可靠、编写良好、经过测试且有文档记录。

结论

我向所有人推荐这本书；它读起来轻松有趣，即使高级开发人员不太可能从中学到新东西。另外，这只是对本书内容的快速概述，我并没有涵盖从中学到的所有内容，还有很多内容也值得一读，例如正交性、契约式设计、调试、曳光弹技术等等。