代码重构之TDD的思考

需求的不断变更是重构的最根本原因，代码架构最初的设计也是经过精心的设计，具有良好架构的。但是随着时间的推移、需求的剧增，必须不断的修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改。为了实现变更，不可避免的要违反最初的设计构架。经过一段时间以后，bug越来越多，越来越难维护，新的需求越来越难实现，最初的代码构架对新的需求渐渐的失去支持能力，而是成为一种制约（新需求的开发成本会超过开发一个新的软件的成本）。说白了，不管是devops还是敏捷开发，永远强调的是快速响应（产出）！只有好的设计及代码才能做到快速响应！

1. 既然重构那么重要，那究竟什么是重构呢？

重构就是通过调整程序代码，但并不改变程序的功能特征，达到改善软件的质量、性能，使程序的设计模式和架构更趋合理，更容易被理解，提高软件的扩展性和维护性。 

2. 重构的目标值？

• 持续偏纠和改进软件设计 
• 使代码更被其他人所理解 
• 帮助发现隐藏的代码缺陷 
• 从长远来看，有助于提高编程效率，增加项目进度（进度是质量的敌人，质量是进度的朋友） 

3. 怎样去重构？

代码重构的方法论，这里不做论述，有一本《重构改变既有代码的设计》非常值得一读。

4. 重构的困境，集成化测试谁来做？

重构依赖测试，依赖自动化，集成化测试。Test-Driven Development(TDD)，是Extreme Programming (XP)--极限编程的一个重要组成部分。那问题来了，谁来做，怎么做？

我的结论是开发人员来做，由开发人员编写测试带来的收益，最重要的一点不在于测试本身，而在于它能促进开发、测试以及需求分析人员的交流与沟通。而测试先行的方式也能让开发者跳出实现的窠臼，而从业务角度去看待问题，从消费者角度去思考接口的设计。

5. 集成化单元测试怎么做？

说实话，要做到极致（在jenkins中点发布时代码规范、单元测试、集成化测试等各项指标达标发布成功，发布失败把这些项邮件给负责人）。就但集成化测试还真有点复杂，这里分享一个我之前的一个思路

这里分享一个我之前写的mock-plugin-maven ，这里再拓展一下，要实现集成化测试，其实BDD（行为驱动开发）是个不错的方案。