为什么大家不愿意做重构项目？

我做过很多你所说的重构项目，重构的代码从坏味熏天到相对整齐划一，而且大部分都没有设计文档和代码注释，有的甚至是零文档的项目。

重构项目代码很需要团队成员的功底，包括阅读代码的能力、代码到业务的反推能力，以及对编码规范和各种模式的深刻理解。

同时，做重构工作也很锻炼能力，如果一个程序员能够有机会参与几个项目的重构工作，我想无论是对软件设计能力还是对业务理解能力都是很有好处的。

关键是管理人员无法认识到重构对业务提升带来的效益，重构就没有存在的意义。军队要听党指挥，搞技术的要听效益指挥。几年工作下来搞技术的人很多都还没感到因为重构带来什么显著的效果，不懂技术的人就更无法理解了

不是长期的自主的产品，谁会去弄重构啊，自己找事儿嘛

我刚刚参加了一个重构项目，角色是一个小弟，说实话学到了不少的东西。刚到项目组一年，项目组一直在维护一个PDM项目，升级了N个版本了，这次领导下了很大的决心，对之前的产品进行了“解剖手术”，彻底的改了一下，也是借这次机会充分了解了产品。还学到可一些重构的技术、先关的重构工具。

大多数领导是业务驱动项目开发。。。。

我也喜欢重构，但只限于自己的代码，重构别人的代码只能说是痛苦

如果是已上线项目，当然是不重构的好，因为重构风险更大，毕竟上线以后很多问题已经发现并处理了；最好的办法是由销售忽悠上2.0，3.0，这个是双赢的结局

如果是维护时期重构代码，风险比较大。特别是当这个项目之前是他人做的。

有点别人拉屎，你来才屁股的意味

最近没事干老是回头看自己写过的代码，总会发现有很多地方值得改进，重构让人兴奋！

没有测试代码的重构，还是重构么，所以重构不在于在什么时期，而是是否可以有效的实施，为什么要重构，产品怎么用，首先要更新需求和设计，规划和重新编写测试代码，否则应该更新需求设计后，利用旧的代码和架构重新开发。