关于丑陋代码
工作中经常看到很多丑陋的代码，或者，自己写的代码过一段时间之后自己也觉得很丑陋，促使你不断的去重构。
那么，这些丑陋的代码是什么时候编写的呢？它们到底存在多久了呢？
大多数情况下，这些丑陋代码已经存在有些年头了。即使是你一手支撑的产品或项目，经过几个版本的迭代之后，1-2年也过去了。
在这些看起来丑陋的代码中，很多没有进行单元测试，可测试性不高，或者根本不可测。或者它们也有可能是 TDD 实践后的产物，有着不错的单元测试覆盖，但依旧是丑陋的代码。
但经过漫长的生命周期后，它们存活了下来，并且至今仍发挥着效力。因为，这些丑陋代码所实现的业务逻辑是有效和有用的，而业务逻辑所描述的产品还仍然很有生命力。
所以，丑陋代码有其存活的理由。只是，这些丑陋的代码增加了维护的难度，你需要不断的偿还这些技术债务，甚至一直拖欠着。
何时单元测试
在新的项目中，我通常不会直接编写单元测试代码，直到：
- 当我知道如何构建我正在尝试构建的系统时
- 当我知道我们的客户是真正的需要我们所要构建的系统时
- 当我知道我所写的代码将存活一个月以上时
直到此时，我才能明确的表达所构建系统的原型，并且通常其已经不再是一个将被抛弃的原型。
难道这就意味着我有权说我可以不写单元测试吗？是的。
因为在此之前，我们一直在不断的等待各方反馈，以确认我们正在做着正确的事情。而一旦我们已确认所做的事情是正确的，那么就可以启动自动化测试了。
单元测试的作用
- 帮助理解需求
- 对设计的快速反馈
- 提高实现质量
- 测试成本低
- 利于重构
- 文档作用
本文转自匠心十年博客园博客，原文链接：http://www.cnblogs.com/gaochundong/p/when_we_need_write_unit_tests.html，如需转载请自行联系原作者
