今天阅读了《构建之法》的部分主要介绍了个人技术和流程。关于单元测试，邹老师给了我们很多建议。工欲善其事必先利其器，或者说是磨刀不误砍柴工，养成编写单元测试的习惯不仅不会拖累开发进度，反而能让我们的代码更加高效。
软件是由多人合作完成的，不同人员的工作相互有依赖关系。例如，一个人写的模块被其他人写的模块调用。软件的很多错误都来源于程序员对模块功能的误解、疏忽或不了解模块的变化。单元测试能让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证。很多调查显示，在软件开发后期发现的Bug，修复起来要花更多的时间。
在单元测试的基础上，我们就能够建立关于这一模块的回归测试。目的是1. 验证新的代码的确改正了缺陷2. 同时要验证新的代码有没有破坏模块的现有功能。所以，对于“回归测试”中的“回归”，我们可以将其理解为“回归到以前不正常的状态”。回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。单元测试是回归测试的基础。在专注于模块基本功能的单元测试之外，还有功能测试—从用户的角度检查功能完成得怎么样。在微软的实践中，在一个项目的最后稳定阶段，所有人都要参加全面的测试工作，把所有以前发现并修复的Bug找出来，一个一个验证，以保证所有已经修复过的Bug的确得到了修复，并且没有在最后一个版本中“复发”，这是一个大规模的、全面的“回归测试”。
其实在上大学学习了编程之后自己从来没有编写单元测试的习惯。只是一通的编完之后立即编译运行，然后等待报错再一点点的查错。这样也许在之前的小程序面前看不出什么，但是以后要编写更复杂的程序，或者是参加工作之后，这样的低效率立即会让自己大吃苦头的。
所以我要养成单元测试的习惯，从现在就培养自己的专业意识，认真的对待每一次编程，对每一个模块都认真的编写单元测试，扎扎实实的把自己的程序写好。
还有就是编程的时候要注意代码规范，代码规范意味着一个程序员的品德问题，自己虽然在这方面一直做的不错，但是看到邹老师如此强调，上课时听到老师如此重视这一问题，还是提醒自己继续保持。