上一篇，以终为始，我们确定了要做什么，做成什么样子，这一篇，我们主要关注怎么做。
解决问题只需要四步
解决问题的方法论可以参考：高手是如何解决问题的-解决复杂问题只需四步。简单来说就是：
- 第一步，明确和理解问题；
- 第二步，拆分和定位问题；
- 第三步，提出解决方案；
- 第四步，总结问题。
当问题被拆分得足够细、足够清晰的时候，你就会发现解决方案原来是这么明显，每个人都可以办得到。
单元测试降低软件变更成本
软件变更成本总是随着时间和开发阶段逐步提升的，这个我深有体会。
目前的项目陆续有交付到项目地，一个新的特性增加进去，如果没有足够的测试保证，你是没有底气去保证软件功能的稳定性的。有可能，一个bug的修复，就会伴随着其他bug的出现。现在有个项目，必须支持oracle和mysql的数据库，其中就有一部分的脚本的处理是不一样的。每次使用mysql版本开发后，都需要人工集成测试下oracle版本的功能。
软件变更成本随着时间的推移而增加：
开发人员想往往想要将测试的工作留给测试人员，写单元测试主要是为了应付公司具体指标的要求。
但这样的做法并不可行。例如，你做一台机器，每个零部件都不保证正确性，却要让最后的结果正确，这实在是一个可笑的要求，但这却真实地发生在软件开发的过程中。
写好单元测试就是确保每一个零部件能够正常工作。单元测试的关注点只有一个单元，而没有其它任何东西。所以，只要一个单元写好了，测试就是可以通过的；而集成测试则要把好几个单元组装到一起才能测试，测试通过的前提条件是，所有这些单元都写好了，这个周期就明显比单元测试要长；系统测试则要把整个系统的各个模块都连在一起，各种数据都准备好，才可能通过。
软件行业最佳测试实践-测试金字塔：
想要理解测试金字塔成为行业最佳实践的缘由，我们需要理解不同层次测试的差异。越是底层的测试，牵扯到相关内容越少，而高层测试则涉及面更广。
这一小节的重点是，多写单元测试。
TDD测试驱动开发
测试驱动开发的核心在于测试和开发之间的相互驱动。
- 代码编写时，如何编写出容易测试的代码；
- 代码编写之后，更加安心的重构代码。
红绿重构
- 红，表示写了一个新的测试，测试还没有通过的状态；
- 绿，表示写了功能代码，测试通过的状态；
- 重构，就是再完成基本功能之后，调整代码的过程。
很多人通过了测试就认为大功告成，其实，这是忽略了新增代码代码可能带来的“坏味道（Code Smell）”。如果你真的理解重构，你就知道，它就是一个消除代码坏味道的过程。一旦你有了测试，你就可以大胆地重构了，因为任何修改错误，测试会替你捕获到。在测试驱动开发中，重构与测试是相辅相成的：没有测试，你只能是提心吊胆地重构；没有重构，代码的混乱程度是逐步增加的，测试也会变得越来越不好写。
编写容易测试的代码
极少有人在写代码的时候，想到是否容易测试。如果想到了，我们甚至可以初步判断，这个人对自己编写的代码有责任心，这个人在编写高质量的代码，而不是为了应付式的完成任务。甚至可以说，这个人有优秀程序员的习惯。
编写测试，是一门技能，是一门优秀程序员必须具备的技能。而一门技能就需要反复练习，刻意去练习才能慢慢掌握。
这一节的重点：多写单元测试；编写容易测试的代码；重视并掌握测试这一门技能。