02《构建之法》阅读笔记之二

在过去，我在完成一个代码后几乎从未进行复审过，同时在对部分功能进行测试后也没对系统整体进行复查等操作在读了构建之法后，又让我有了很多体会以及学到了很多。

第4章 两人合作

1.在复审前：

1.代码必须成功地编译，在所有要求的平台上，同时要编译Debug|Retail版本。编译要用团队规定的最严格的编译警告等级。
2.程序员必须测试过代码。什么叫测试过？最好的方法是在调试器中单步执行。
3.程序员必须提供新的代码，以及文件差异分析工具。用Windiff或VSTS自带的工具都可以。VSTS中可以通过Shelveset来支持远程代码复审。
4.复审者可以选择面对面的复审、独立复审或其他方式。
5.在面对面的复审中，一般时开发者控制流程，讲述修改的前因后果。但是复审者有权在任何时候打断叙述，提出自己的意见。
6.复审者必须逐一提供反馈意见。注意，复审者有权提出很多看似吹毛求疵的问题，复审者不必每一件事都要亲自调查，开发者有义务给出详尽的回答。
7.开发者必须负责让所有的问题都得到满足的解释或解答，或者在TFS中创建新的工作项以确保这些问题会得到处理。
8.对于复审的结果，双方必须达成一致的意见。（打回去/有条件地同意/放行）
2.在代码复审中还要做什么？
好的复审者不光是要注意到程序员修改了什么，还要把眼光放远，问一些这样的问题：

“这么修改之后，有没有别的功能会受影响？”
“项目中还有别的地方需要类似的修改么？”
“有没有留下足够的说明，让将来维护代码时不会出现问题？”
“对于这样的修改，有没有别的成员需要告知？”
“导致问题的根本原因是什么？我们以后如何能自动避免这样的情况再次出现？”
有些修改看似聪明有效率，实则可能会加大以后的开发和维护的难度。

3.在代码复审后要做什么？
人不能两次踏入同一条河流，程序员不能两次犯同样的错误。在代码复审后，开发者应该把复审
过程中的记录整理出来：

更正明显的错误。
对于无法很快更正的错误，要在项目管理软件中创建Bug把它们记录下来。
把所有的错误记在自己的一个“我常犯的错误”表中，作为以后自我复审的第一步。