系统程序员成长计划-写得又快又好的秘诀(三)

转载时请注明出处和作者联系方式
文章出处：http://www.limodev.cn/blog
作者联系方式：李先静 <xianjimli at hotmail dot com>

代码阅读法

软件工程实践已经证明Code Review是提高代码质量最有效的手段之一，极限编程(XP)更是把Code Review推向极致，形成著名的结对编程工作方式，两个程序员在一台电脑前面工作，一个人编写程序，另一个Review输入每一行代码，写程序人的专注 于目前细节上的工作，Review的人同时要从高层次考虑如何改进代码质量，两个人的角色会经常互换。

可惜我即没有结对编程的经验，也没有在CMM3(及以上)团队中工作过。不过现在我要介绍比结对编程更敏捷更轻量级，但是同样有效的Review方 法。这种方法不需要其他程序员配合，有你自己就够了。为了把这种方法与传统的Code Review区分开来，我把它称为代码阅读法吧。

很多初学者包括一些有经验的程序员，在敲完代码的最后一个字符后，马上开始编译和运行，迫不急待的想看到自己的工作成果。快速反馈有助于满足自己的成就感，但是同时也会带来一些问题：

让编译器帮你检查语法错误可以省些时间，但程序员往往太专注这些错误了，以为改完这些错误就万事大吉了。其实不然，很多错误编译器是发现不了的，像 内存错误和线程死锁等等，这些错误可能逃过简单的测试而遗留在代码中，直到集成测试或者软件发布之后才暴露出来，那时就要花更大代价去修改它们了。

修改完编译错误之后就是运行程序了，运行起来有错误，就轮到调试器上场了。花了不少时间去调试，发现无非是些低级错误，或许你会自责自己粗心大意， 但是下次可能还是犯同样的错误。更严重的是这种debug & fix的方法，往往是头痛医头脚痛医脚，导致低质量的软件。

让编译器帮你检查语法错误，让调试器帮你查BUG，这是天经地义的事，但这确实是又慢又烂的方法。就像你要到离家东边1000米的地方开会，结果你 往西边走，又是坐车又是搭飞机，花了一周时间，也绕着地球转了一周，终于到了会议室，你还大发感慨说，现代的交通工具真是发达啊。其实你往东走，走路也只 要十多分钟就到了。不管你的调试技巧有多高，都不如一次性写好更高效。

我以前也一样，想赶时间结果花了更多时间，在经过很多痛苦的经历之后，我开始学会放松自己，让自己慢下来。写完程序之后，我会花些时间去阅读它，一 遍两遍甚至多遍之后，才开始编译它，只要有时间，在通过测试之后，我还会阅读它们，每读一遍都有不同的收获，有时候会发现一些错误，有时候会做些改进，有 时候也有新的想法。

下面是我在阅读自己代码时的一些方法：

o检查常见错误。

第一遍阅读时主要关注语法错误、代码排版和命名规则等等问题，只要看不顺眼就修改它们。读完之后，你的代码很少有低级错误，看起来也比较干净清爽。 第二遍重点关注常见编程错误，比如内存泄露和可能的越界访问，变量没有初始化，函数忘记返回值等等，在后面的章节中，我会介绍这些常见错误，避免这些错误 可以为你省大量的时间。如果有时间，在测试完成之后，还可以考虑是否有更好的实现方法，甚至尝试重新去实现它们。说了读者可能不相信，在学习编程的前几 年，我经常重写整个模块，只我觉得能做得更好，能验证我的一些想法，或提高我的编程能力，即使连续几天加班到晚上十一点，我也要重写它们。

o模拟计算机执行。

常见错误是比较死的东西，按照检查列表一条一条的做就行了。有些逻辑通常不是这么直观的，这时可以自己模拟计算机去执行，假想你自己是计算机，读入 这些代码时你会怎么处理。这种方法能有效的完善我们的思路，考虑不同的输入数据，各种边界值，这能帮助我们想到一些没有处理的情况，让程序的逻辑更严谨。

o假想讲给朋友听。

据说在Code Review时发现错误的，往往不是Review的人而是程序员自己。我也有很多这样的经历，在讲给别人听的时候，别人还没有听明白，自己已经发现里面存 在的错误了。上大学时，我常常把写的或者学到的东西讲给隔壁寝室的一个同学听，他说他从我这里学到很多知识，其实我从讲的过程中，经常发现一些问题，对提 高自己的能力大有帮助。可惜并不是随时都能找到好的听众，幸好我们有另外一个替代办法，记得刚开始写程序时看过一本书(忘记名字了)，作者说他在写程序 时，常常把思路讲给他的布娃娃听。我没有布娃娃当听众，讲给鼠标听总是有点怪怪的?，所以就假想旁边有个朋友，我把自己的思路讲给他听，同时也假想他来质 疑我。这种方法很效，能够让自己的思路更清晰，据说一些大师也经常使用这种方法。

这种代码阅读法会花你一些时间，但是可以省下更多调试时间，而且能够提高代码质量，可以说是名符其实的“又快又好的” 秘诀之一。至于读几遍合适，要根据情况而定，个人觉得读两到三遍是最佳的投资。