编程习惯

文/Alexey Radul 译/程显峰

近年来，我对编程艺术有很多体会。过后，我发现有些体会是错的；有些体会我遗忘了但又重新感受到；而另外有些则是必然会发现的。我还完善了一套项目管理的好习惯，这些习惯包括我自己的，或者小组的，抑或是更大的,公司内部的。一方面，这些习惯对软件的成功开发是至关重要的(太小或者纯粹巧合的不算)，另一方面，这些习惯也不是什么高深莫测的东西，较小的篇幅就可以说清楚了，第三，这些习惯都没有得到应有的重视。所以我把这些写下来，而你呢，正读着呢。

本文包含很多零散的个人建议，有六大块，各讲一个方面。因为建议很多而且相互联系紧密，所以不太好把他们逐条陈列。这样写还有一个好处就是你可以有所挑选的阅读，把你所知道的部分跳过去，把你想重新思考的部分温习一下，或者只是简略的阅读提纲不深入研究具体内容。

1 版本控制

版本控制是一种在开发的过程中对软件开发的历史系统地跟踪的方法。此项任务由版本控制系统完成，如CVS或Subversion。版本系统保持了一个受控编码的历史痕迹，提供很多操作：获得当前版本代码(通常称为“检出”)；“提交”修改；“更新”工作拷贝来协调他人的修改。版本控制系统还提供一些其他功能，如用不同的方式检查代码的历史，撤销更改，回滚到软件历史的某个点，解决冲突(两个人同时对相同的代码段进行了不同的修改)。

用过文本编辑器的“撤销”按钮，或是用备份文件进行过恢复的人，都能体会到让电脑记住以前的东西的惊奇效果。而代码比普通的文件要复杂的多，自然这种功能在开发中就更加重要了。要是你没有体会过与别人一起开发的乐趣，记住我的话：潜在的混淆和数据的损失是与参与的人数成正比的。因此，版本控制在开发软件的过程中的作用是不可估量的，如果使用得当的话还会发挥更大的效力。

那么，怎样才能用好版本控制呢？

1. 选用一个优秀的版本控制系统 我现在非常中意Subversion，它不但高效，而且免费。它现在非常流行，并且会变得更加流行。它几乎不干扰其他开发过程。我并不是说它是完美的，但在你找到更好的之前确实是一个不错的选择。

2. 一开始就要版本化 要是在项目中有些东西要保存在比草稿纸更加正式一点的地方，那么绝对要将其版本化。

推论：要是你已经开始了一个没有版本控制的项目，马上建立一个，并提交项目。

3. 就算你单干也要版本化 三个星期后的你将大大有别于今天的你。努力实践版本控制使得你实现你的意图的时候非常清晰，要是你忘记了手头做的什么事情(相信我，你会忘的)，那它可有大用处了。此外，你还免费的做了一个备份，【1】看来这么做一点损失都没有，好处倒不少。

4. 只要是人类的智慧就要版本化 代码(肯定是人类的智慧啦)，测试用例，编译脚本，文档，任务列表，解释说明，演讲稿，想法，需求—只要是经过人的大脑创造出来的一切，都应该记录在版本控制系统里，除非你有更好的理由将它们放到别处。

5. 计算机生成的文件就不必了，这样做只能导致项目出现不一致(如有人提交了源文件，却忘记生成了有依赖关系的衍生文件)。比较好的做法是让版本控制系统忽略这些衍生文件，需要的时候再生成就是了。但是万万要把能衍生文件的人类原创途径记录在案，包括执行生成过程的命令之类的。

6. 做好日志 好的版本控制系统都会在每一次更改的时候让你留下日志，目的是解释一下你对提交的代码都做了些什么。千万别忽略这一步，一定要写，并且好好的写。

i. 不光是为别人而写也是为自己，认真细致记录日志会迫使你梳理你的设计，看清问题所在，认清正在做的事情，也会使得想知道细节的人(同样包括未来某时的你)与代码的作者有个交流。

ii. 把“做了什么”记下来(必要时补充“原因”)，而不是“怎么做的”。要是“怎么做的”真的那么令人感兴趣，而且从修改本身很难去理解，当然有必要记一记，但是通常代码本身已经很能说明“怎么做的”了。要是真的有什么地方不清楚的话，那一定是你的思路。

iii. 描述点滴所做 版本控制系统能帮助你找到你所做的更改，要试着将所有的修改都详细的告诉系统。推论：不要做自己都解释不清的事情。要将其分割成很多比较小的步骤，然后一个一个的来。

7. 不能搞破坏 每一次你提交了代码，系统应该是好用的。也就是说，其他人此时更新代码后应该能够编译(可能的话)，执行测试套件，并通过测试。将错误提交了是对与你协同的人(还是包括未来的你)极大的不尊重。这会让他们搞不清楚到底是因为自己的问题还是你提交的一些垃圾导致了系统不能运转)。【2】

推论：要是你真的搞破坏了，要道歉，并立刻修复。

8. 修改要小到原子 理想的情形下，每一次修改只包含一个意图，每条日志只是说明一个问题的单句段落。这有一条傻瓜法则用以判断两个相互联系的事情到底是一个还是两个原子修改：问问自己会不会有人只想撤销其中一个而保留另一个。如果答案是肯定的，就要分开来提交。

9. 不要改而不交 拖延修改的提交时间越长，你越容易忘了自己都做了什么，越容易产生BUG,也越容易与其它人的相关工作不协调。要是你没有提交修改，其实一天的活儿就不算干完，除非你有更好的理由。

2 构建系统

构建系统是很多自动完成软件开发任务。其中最常见的就是编译代码。运行测试组件也是构建系统提供的功能。还有很多其他的功用，像根据代码注释生成可浏览的文档，将组件合并用以发布，等等。将这些工作自动化可以节省很多时间和人力，还会防止有无误操作或是由于懒惰疏忽而产生的错误。

已经有这样的工具了。UNIX工具make已经成为构建自动化的标准好多年了，而且相当好用。Ant在Java领域内非常流行，我个人喜欢rake【3】。现代IDE也有部分这样的功能，或是有调用这些标准工具的接口。无论你最终使用哪一种工具，编译，测试，或是其它什么别的，应该简单到只是按一下按钮。

构建系统建议：

1. 使用真正的构建工具 学习一个全新的工具是有些令人却步，但却很值得。简单的脚本总是能搞定你的项目。不会有项目小到不适合应用这些标准工具，只有极少数特大号的项目不适合。【4】

2. 使一切自动化 编译和测试应该从一开始就精心地自动化了。同样当你开始生成文档或者代码，做清理，安装等等的时候，也要使其自动完成。总的来说，要干第二次的任务最好就要自动化。

3. 自动过程要明晰 尤其要注意，当大家提交东西的时候，应该有一个精心定义的“构建”，一种大家都不应该破坏的“构建”。通常，这会包括成功的编译结果和测试结果，但是，一定要说清楚哪些命令用来执行，保证其总是能干活。并确保在任意一次执行都能清楚地知道它是否运转正常。

3 自动化的测试套件

测试套件是很多验证代码有效的测试。如果其能够完全由计算机来执行并评估结果，那么就称其为自动化了的。

可以将测试按照测试代码的多少分类：“单元测试”检验单一组件的功能，比如一个函数或者一个类。“集成测试”检验若干组件，也可能是整个系统是否能协同工作。“功能测试”检验系统(通常是全部或大部分)在一个较高的层次上能否正常运转。后两个概念有些重叠，但是从不同的角度，和我个人的经验来说，还没有一个统一的说法到底如何区分。这两条术语经常用来区别于单元测试。

我不会详细讨论优秀自动测试的好处。当前，自动测试问题分得很细：谁应该负责测试，怎样测试，进行多少测试，以及如何将其自动化，何时创建测试，等等。在Internet上有很多此项议题的讨论，我就不浪费大家的时间在这里啰嗦了。肯定的讲，我个人觉得良好的测试套件，包括足够的单元测试和集成测试(功能测试)，对任何项目都是非常重要的。这些应该与主要代码同步完成，还必须是同样的人(要是项目很大能请得起专业的测试人员帮助他们那就更好了)。

已经有一些用于编写测试组件的工具了，Java有JUnit,Python 有PyUnit, Ruby有Test::Unit, 等等实际上每一种编程语言都有xUnit风格的测试库，绝大部分还提供别的方法。不要被这么多选择吓着，是否使用测试组件比到底用哪种组件重要的多。

那么，如何建立一个优秀的测试组件呢？

1. 要提交组件 要知道测试程序也是代码的一部分，和那些在产品中真正运行的东西一样重要。将其版本化。像其它部分一样，共享，备份，跟踪都要进行。另外，所有人都要使用相同的组件。

2. 测试组件要自动化 应该有一个清晰的按钮(比如说‘make test’命令)可以执行所有的测试，并得出结果报告。

3. 测试组件应该是清晰明确的 运行了测试之后，通没通过应该一目了然，如果没通过，那一部分没通过也应该显而易见。绝对不要参砸任何的人为判定到底是通过了还是没通过。测试也不要产生任何可能会使报告费解的输出。

4. 一定要通过测试 提交未通过测试的东西无异于对“构建”进行破坏，是要绝对禁止的(如果不巧发生了，要立即修复)。如果你知道代码是正确无误的，是测试出了问题，那就要修改测试。如果你的确要提交，但是有些测试就是毫无道理的通不过，你也没时间立即debug，那么暂时将其从组件中去掉，过后要马上弄好。

5. 经常测试 修改的时候要测，提交前要测，开发期间要测。运行测试套件(至少也是其中的相当的一部分)应该成为你开发周期的一部分。

6. 测试先行 不要惊讶，我是说真的。当修正bug的时候，先要写一个能针对它的测试，然后再修复bug。要是测试通过了，就成了。添加新的功能的时候，先写好针对它的测试。不仅会帮助你理解这个功能到底应该干什么，还会在干成了的时候通知你。

7. 测试是可以执行的文档 与普通文档不同，测试从不说谎，因为人人都运行还总得通过。如果你觉得一段代码难于理解，那么就写一个单元测试。如果你写了实际的文档，写写测试来验证一下其中的陈述。

8. 依靠阅读来测试代码能否工作显然是行不通的，所以还是写测试来检验到底是否正常运转。你将会惊讶地发现找到很多bug，也会惊讶于避免了相当多的bug产生。

9. 只做有效的测试 很容易写如下的测试：“当我运行这个程序时给这个输入，就会产生10，000行我这个文件里的输出”。通常这样做比没有好，但绝对是一个糟糕的测试，因为除了真正起作用的东西外，也测试了许许多多无关的细节(如浮点舍入误差)。改进类似的测试来适应程序中的修改，要么极其痛苦，要么很可能引入bug.

4 代码审核

代码审核是通过阅读别人的代码，来寻找错误，提出改进意见等的过程和实践。使得代码更清晰，设计更合理，综合性能更好是条很漫长的路。另外一双眼睛，另外一种审视问题的角度会极大的促进方案更清楚，更优异。代码审核还会帮助程序员相互传授有用的技术，方法，风格等。只要一个项目的开发者多于一个人，那么立即开始相互审核代码。理想情况下，每一行代码都要被两个人看过，作者和审核人。

对代码审核的实践有很多东西值得探讨：何时审核，如何整体审核，由谁来审核。在很多全职的程序员共同参与的大工程中，每一段代码都应在提交的时候送评(如果有更好的工具支持，则应在提交之前)。审核人要清楚与之相关的代码，并要理解其作用(还有，更重要的，可能会发生的错误)。在此过程中，审核要快速的完成(一到两天内)，作者在评论完成之前，不要试图改动这段代码，以避免把事情搞乱。

参与人数少的小项目则不必如此。要是代码不多的话，进展的速度会很快，要是每一次提交都审核的话耽误不起。但是，代码审核对代码和写代码的人都很有益处(因为，不说别的，这使得至少两个人都理解这段代码。)用什么样的风格做项目，只要适合就好，但一定要养成审核代码和让人审核代码的好习惯。

如果你是审核人：

1. 及时 如若有人请你审核一段代码，要么马上开始，要么痛快的告诉人家不行(并转交给更有资历的审核人)。千万不要让人家等。

2. 尊重 代码审核的目的是确保代码的质量，不是为了显示出谁比谁高明。作为审核人，你的确有很大的权力，但是不能乱用。

3. 详尽 若是有些东西你搞不清楚，要么是代码写的就不够清楚，要么是注释不够，也可能二者兼有。请作者澄清(不单单是对你私下里的解释，要写进代码里)。要是什么不对劲，这很可能，或者是对的但看上去是错的，或是晦涩的，都要告诉作者使其修改。

4. 执行规定 要是项目中有些规定或规范(代码风格，命名规范，测试等)，发现不符的地方一定要让作者修改。有些时候这样做显得吹毛求疵，但是定下这些规定和规范是有缘由的，所以应该遵守。

如果你是被审核代码的作者：

1.