开发过程中是否经常需要进行软件重构？

[zhujinqiang]

重构的好处究竟有多大？
《重构，改善既有代码的设计》，这是一部经典之作，相信很多人都听过或看过。
说起重构对改善既有的设计的帮助，似乎是体现在改变了原本很难理解的流程上面。
更侧重于流程而不是代码。
这本书是用Java写的，而且Java的版本很老。
如果应用到C++开发的效果将会如何？

[忘世麒麟]

好处大不大是相对于效益来说的.假如重构过程不会花费过多的人日,重构后的软件质量比之前的好很多,客户更加满意.这样才可以说好处大. 但是重构是一个比较难的事情,要考虑方方面面,一些老牌的软件是没人愿意动手重构的,情愿修修补补,比如一些老牌金融公司的炒股软件. --- 重构这个概念可以应用到任何一门开发语言上,他腔调的不是开发语言.所以你最后问的问题,感觉挺莫名其妙的.

[cain-won]

代码重构是软件行业的重要知识。不论开发语言，经过重构后的代码，让人一看代码就知道是干嘛的，这样的重构就是成功的。重构并不是所有功能实现完之后再来实施的，而是在代码的编写过程中就实施

[赵4老师]

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。 意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。 试对比 图书馆（对图书的分类够结构化了吧） 和 搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索） 哪个处理信息更方便、更高效。 所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。 结构越复杂，越难修改，越难除错。 有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。 程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George 前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题： ◆“要保证这个问题不会再出现，我该怎么做？” ◆“要想少出些Bug，我该怎么做？” ◆“要保证Bug容易被修复，我该怎么做？” ◆“要保持对变化的快速响应，我该怎么做？” ◆“要保证我的软件的运行速度，我该怎么做？” 如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

[幻夢之葉]

需要经常重构的代码，那一定是写代码的人太水。 1：需要经常重构的那说明扩展性不强 2：经过多次重构还需要经常进行重构的那说明重构的水平也太差 前期自己写代码可以多进行重构，让代码可以较强的扩展性。 中期选择性进行部分重构。 后期都是隔了比较长时间不能满足需求或者再增加功能的时候比较难进行开发，这个时候就需要比较大的重构一次。 这本书我看过，方法都是很常见并且都是小范围的，重点是里面的思维，不仅仅只对Java，对所有语言方面都是有参考价值的。

[真相重于对错]

我觉得问这个问题之前，应该问一下“您是否经常加班？？？”

[angel6709]

需要