阅读《驯服烂代码》

在新做一个项目之前阅读了本书，记录下印象深刻的部分。
作者刚开始描述的做酒店时钟系统的开发流程。由文档到设计到系统，完全按照正常的开发流程。作者采用领域模型订阅和术语表定义的方式明确需求。然后用领域模型图和用例图进行分析，采用适当的设计模式。这些过程都感觉没什么问题。当系统采用main函数进行调用验证结果的时候，感觉开发的过程中应该有单元测试的（这也是开发思维的进步）。这种开发的过程中，文档跟不上代码的修改，大多数情况下都会发生。
在测试驱动开发重做系统的过程中，事情变得很不一样。我了解到，采用用户故事来描写产品特性。（用户故事：作为<角色>,我想<实现目标>来<获得收益>。 不牵扯细节，作为沟通的指路牌）。通过预先定义预期结果的方式，来反推生产代码。以前一直以为让测试很快通过的方式很丑陋，现在来想，这是作者表明小步开发思想的方式。在相应的位置，记录要进行的任务，然后不断的实现特性，重构代码。(重构，要不断进行，书也应该不断阅读，能够发现代码的坏味道，并且知道解决方案）。
测试驱动开发，那么，新增加的测试，应该是能够促进生产代码的修改的。其他的全面性测试，可以放到后面做。这时作者也提出，随着对系统不断的加深理解，可以不根据编译错误来解决问题。
凡是没有全面测试代码的代码都是遗留代码，那么，我好像到现在开发的都是遗留代码。
对遗留代码的重构过程中，应该以接口为阅读切入点。此时，我们不能急于修改代码，而应该是记录可以重构的地方和原因。最后再逐个解决需要修改的问题。
在开发过程中，我们要针对抽象编程：高层模块不依赖于低层模块；抽象不依赖于细节。所以测试的代码，应该针对用户意图和公共接口这样的抽象编写。函数中的语句都要在同一抽象层次上。
Stub是提供被测系统提供输入，Mock在提供输入的同时验证输出。提取接口，派生子类都可以构造stub。
单元测试要快，不应该：
1.与数据库交互
2.进行网路通信
3.调用文件系统
4.对环境做特定准备（编辑配置文件等）才能运行。
全面重构：
1.审视并更新TODO列表，删除已经完成的任务，添加新发现的任务。确保该列表反应当前最新情况。
2.根据经验，选定合理的下一个任务
3.编写或修改测试代码(固化行为，调用当下生产代码接口）
4.频繁测试修改。
想做好一件事情，真的需要用心的长期坚持。10000个小时，我们真的差得好远。在某一个特定领域用一生的时间来刻意完善自己的表现，与君共勉。