项目一个版本交付后，我号召把代码重构下。旁边的同志说“不行！没有TDD的测试用例，哪能重构呢？任何改动都可能产生觉察不出的Bug, 测试人员又要全部重新测了！”一听这话，边上的测试人员也过来否定我。
其实我的要求也不高，把变量或函数名称改得有意义点也好，因为赶时间写出来的代码，质量实在很糟糕。难道没有TDD就真不能重构么？或者说我不该提重构这个词，让人感觉好象要动什么大工程一样？
我工作的先两年是没有测试人员为伴的，而且往往单枪匹马做战，质量完全自己保证。因为不存在太多的人合作，所以代码的各个环节都比较清楚，一个地方的改动可能产生的影响大致能判断到（当然也有很多没想到的时候...)，所以即使没有TDD,不改变功能的调整也是常干的事。
以前做Mole项目时，当时对TDD还没太多概念却正好看了Refactoring一书，项目时间又比较宽裕，于是把重构手册好好的炼了一把。很多时候也不是完全为了结构的优化而重构，而是当前实现满足不了需求，需要做大规模的调整，于是呼好几次大刀阔斧的在改善功能的同时改变代码的结构(要被人说成非重构啦*_*)，因为细粒度的功能封装得比较好，每次调整并不会产生太多难以察觉的Bug，当时感觉蛮好的。
当然，项目的性质和环境不一样，同事的话或许不无道理。只是感觉TDD用在复杂的域模型上比较有优势，这个在我看来近似Demo的项目,编码主要在数据存储层和界面层，OO的概念及使用也比较薄弱，怎么才能用好TDD呢？难道开始没有用TDD,后来就只有让系统慢慢的烂下去？
呵呵，期待管理者把《人月神话》再回顾一下，怎么处理项目的第一个版本，建议是完全抛弃掉，或许上述的矛盾就有机会解决了。
