构建之法第二章
本章为个人技术和流程，主要介绍了单元测试、回归测试、效能分析和个人软件开发流程等内容。
单元测试：如何能让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证，单元测试就是一个很有效的解决方案。
1、用VSTS写单元测试：在写技术模块的规格说明书的时候，要越详细越好，最好各项要求都可以表示为一个单元测试用例。
2、好的单元测试的标准：
1>单元测试应该在最基本的功能/参数上验证程序的正确性
2>单元测试必须由最熟悉代码的人（程序的作者）来写
3>单元测试后，机器状态保持不变
4>单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）
5>单元测试应该产生可重复、一致的结果
6>独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性
7>单元测试应该覆盖所有代码路径：100%的代码覆盖率并不等同于100%的正确性
8>单元测试应该集成到自动测试的框架中
9>单元测试必须和产品代码一起保存和维护
3、回归测试：可以理解为“回归到以前不正常的状态”，单元测试是回归测试的基础
4、效能分析工具：两种分析方法为抽样和代码注入；一般做法为先用抽样的方法找到效能瓶颈所在，然后对特定的模块用代码注入的方法进行详细分析；如果我们不经过分析就盲目优化，也许会事倍功半
5、个人开发流程：根据数据显示，从学生到职业程序员，并不是更加没完没了地写程序，花在写代码的时间反而少了许多，而在“需求分析”和“测试”这两方面明显要花更多时间，在具体编码上花费时间少。
虽然，在实际软件开发中，需要团队的合作，但是在团队中，每个人都应该到达一定的水平，也就是这章讲述的个人技术和流程，可以说这是基础，只有每个人的技术和开发流程打到一定的标准，有一定的规范，才有利于团队之间多人的合作，才能保证配合开发出来的软件的各个模块都是符合标准的，具有一定健壮性的，利于维护和更新。
个人感受部分：
1、我过去怎么做的；有的时候写程序一写就是一大片，总是出了bug无从下手
2、结合书中所讲，这样有什么不好：针对一个程序的完成，应该进行相应的测试，分析其效率，以及时间复杂度和空间复杂度等，否则单纯写代码并没有什么经验上的收获
3、提出一个解决办法，避免再次掉入陷阱：写程序先屡清楚他的逻辑结构，按照功能模块进行测试，有助于及时的修改和找到相应bug所在