如何成为一名优秀的程序员

由于我没有能够看到本书的完整内容，也由于时间和能力有限，我没有对全书进行整体的分析，而是采用了引用一部分原文再加以评论的方式。对于一本厚达964页的大书来，这无疑是管中窥豹，我只能希望读者能够从一斑中窥视到全豹的彪炳花纹。

第20章，软件质量概述
大部分研究都发现，检查比测试的成本更小。NASA 软件工程实验室的一项研究发现，阅读代码每小时能够检测出的缺陷要比测试高出80%左右（Basili and Selby 1987），另一个组织则发现使用测试来检测缺陷的成本是检查的6 倍（Ackerman, Buchwald and Lewski 1989）。后来，IBM 的一项研究又发现，检查发现一个错误只需要3.5 个工作时，而测试则需要花费15-25 个工作时（Kaplan 1995）。

在净室（ClearRoom）方法中，尽量将缺陷消灭在编码阶段而不是测试阶段是一个基本的思想。这种思想也许在更早的时代就已经有人提出过了，但似乎没有人把它运用到这样近乎极端的地步。在净室过程中，通过严格的代码复查（Code Review）来保证最少的缺陷。代码在进行复查之前甚至没有编译过（这意味着程序员不能再依赖编译器的强制语法检查），而通过复查的代码可以不经过模块级别的测试，就直接进行集成测试。程序员的表现由代码最终的缺陷数量来决定。

也许这种方法确实过于极端，但是这个基本方向是确凿无确的。依赖编译器和测试人员来找出缺陷，是程序员最大的恶习之一，即使不通过净室方法，也应该通过其他方法来加以避免。考虑到现实情况，完全的代码复查可能几乎无法实现，最大的原因在于生产率。

实施净室过程后，一个程序员每月最终完成的代码量可能在200-300行，但是在我们面对的项目中，往往一个程序员一天完成的代码量都要远远超过这个数字。能够采取的平衡措施是，实行代码抽查，并且仍然在更大的程度上依赖测试人员（在本书中也提到，综合多种方法可以获得更高的缺陷排除效率）。这样至少可以尽量地提高代码的质量。

第23章，调试
就解决问题的表象而言，一种方法是随机的修改代码，直到你的代码看起来能工作。典型的思维逻辑是这样的：“这个循环好像有问题。可能是一个off-by-one 错误。让我先来写一个-1 试试。哦，这样不行。那么我就写个+1 试试。哈，看来程序正常工作了。我可以宣布问题搞定了。”

尽管这种方法受到了很多程序员的追捧，但它非常低效。随机地修改代码就如同是把一辆Pontiac Aztek 汽车转来转去，以为这样能修复它的引擎故障。你学不到任何东西，你只是在晃来晃去地浪费时间。你会争辩说随机修改程序是有效的，因为“我不知道这段代码到底出了什么事，我想试试这样修改，希望它有用。”不要随机修改代码。这就是所谓的“voodoo programming（巫毒编程）”。在没有理解代码的时候对它所做的修改越大，你对它能正确工作的信心就越低。

这是在初学者，甚至在某些有多年经验的程序员身上都能见到的习惯。据我个人的经验，在程序员者失去对解决问题的兴趣或感到疲惫的时候，最容易被这种习惯所左右。而某些程序员对解决问题从来就没有兴趣——他们并不试图理解问题，他们只是试图写出一段代码可以生成一个正确的结果而已。这种习惯是导致代码缺陷的最大来源之一。如果他们不改正这种习惯，将永远也无法成为优秀的程序员。

某次代码复查时，在进入代码的细节之前，一位程序员先向别人介绍他解决这个问题的思路。但他一开始就遇到了问题，他无法清晰地表述他的思路。进入代码层次之后，大家发现，他使用了一种非常古怪的方式来实现需要的功能。这种方式是如此古怪，以致于别人难以阅读他的代码，甚至他自己也无法清晰地表述。很明显，这是 “随机的修改代码，直到你的代码看起来能工作”的典型例子。

在编码之前，必须透彻地了解需要解决的问题，并且找到清晰的解决思路。如果在编码过程中发现原有的思路不够清晰，或者无法达到目的，必须先停下来重新思考，即使这样做的结果可能导致重写全部代码。