你们的项目经常重构代码吗？

我一般边写边重构，因为一开始为了让思路快速展开，很多时候不能够很好的考虑代码结构和执行效率等问题，等写的60％成型后，就会逐渐的发现前面写的代码的不足之处，然后就开始一边写新代码，一边重构。

如果到了最后的代码review了才发现有很多问题，需要重构，那这个开发过程就比较失败了。因为这样的重构代价很大，但是不重构往往问题更大。

逻辑封装为一组 业务封装为一组
即使在小的业务模块里，仍然可以做此划分。

重构的前提，建立在一开始就有充分的最大化解耦的思想。
重构才体现出 高复用的效果。

否则只是在做无谓的 代码拆分工作而已。

一段时间后（有空），回头再看、再想原来的代码，一定会有不好地方，重构是必须的。如果不重构，一直推着做，大家就会养成“只实现功能”的习惯，常吃以往代码可想而知。

重构好处：
1.使用新的代码模式，新的框架，新的类库。
2.取老项目的优点，去其不好的地方。
3.新的思路，新的想法，会部用上。
4.一些看不上原代码质量的（因此而没有积极性的员工，或因此而要离职的员工），会留下（重要呀），而且会增加这些程序狂人的“激情”。

注意：如果是大项目或长时间的项目，重构好。如果是小项目或一次的项目，不要冲动，重构是需要成本的。

然后等客户说“第一期做得不错呀，你们接着做第二期吧”的时候抓栏杆撕床单

如果不用TTD一般的需求是怎么记录的?
用buglist这种方式有点冗余.
需求说明书又缺很多需求变更.
实在是不知道作二期的那群人
是怎么把一期的需求
从代码中扒出来的?

上个项目最失败的几点都是由于需求扒出来的时候走了样

重构。。。。。。 重新构思。


          目的：改善原有的，不合理的，影响性能的问题。

按你说法 需求难道应该用tdd来保存？

先出个需求说明书，然后分解成功能点或jira的task或用户故事或随便什么东西，
然后每次迭代实现一些功能，改一些bug，如此反复，直到没啥可做的了。
貌似跟tdd没啥关系。

真的不知道用什么来保存
上家上上家都是用人脑来保存这些信息......

没有自动化测试，就不能重构了吗？

不太合理吧。自动化测试与重构有必然关系吗？