现在，《构建之法》的一大半已经读完了，在这一大半本书中，这一部分可以说是对我触动最大的，也应该是整本书对我触动最大的。

整个第二章围绕测试展开，用一个很生动的类比告诉了我们测试的重要性：如果有人说，“一个人写写程序玩玩，单元测试似乎不那么重要。”，那么你可以回应他：“你可以大胆对你的女朋友说：‘我们只是玩一玩。’看看效果如何”。

namespace DemoUser{

    public class User{

        public User(String userEmail) {

            m_email=userEmail;

         }

         private string m_email;

     }

}

仅仅对于这么一段代码，作者就给出了四个单元测试，分别测试了普通字符串、空的字符串、长度为0的字符串、都是空格的字符串的情况。测试代码的行数比被测代码的行数多了三倍以上。想想之前几次大作业时对测试的忽视，以及最后代码写完后修改错误所用的大量时间，真是后悔当时没有读《构建之法》。

作者还对单元测试提出了标准：在最基本的功能/参数上验证程序的正确性；由最熟悉代码的人来写；测试后机器状态保持不变；运行时间短；产生可重复的、一致的结果；保持独立性；覆盖所有代码路径。这些标准在以后我们写单元测试时会再三注意。

除了单元测试，作者还告诉我们应该进行回归测试以验证更新版本后有没有“退化”的情况发生，还应该进行效能分析看看代码有哪里值得优化，使自己的代码跑得“又快又好”。

第三章则告诉了我们一位软件工程师应该如何成长，并给出了很多评价标准。使我们的职业成长之路更为清晰，同时也警醒着我们不要目标过高，要认清自己。要通过不断的学习、实践和总结来提升自己，通过考证来肯定自己。

第四章开始着眼于合作中的最低层次——两人合作。一开篇便用很大的篇幅告诉我们代码规范及其重要性，要从缩进、括号、断行与空白的{}行、分行、命名、下划线、大小写、注释等九个方面形成代码风格规范，从而达到便于团队成员阅读自己的代码的目的。

作者对代码设计规范也提出了不少要求，但我自认为这一点做得还不错，不展开了。

接下来，作者则对如何进行代码复审进行了说明，这比之前第二章所说的测试提出了更高的要求，不仅从自审变成了他审，还对具体代码之外的概要、设计规范、代码规范、效能、可读性、可测试性都要进行审核。然后作者还从社交角度为结对编程提供了不少意见。

第十一章则通过大量生动的具体故事，给我们大致呈现了软件设计团队经常遇到的一些问题，告诉我们在各种情况下应该如何应对。也提供了每日构建、小强地狱、构建大师等管理方法。

三读《构建之法》——源代码的设计、实现、控制与两人合作