向急需重构的代码库添加功能答案

【问题标题】：Adding features to code bases which are in dire need of refactoring向急需重构的代码库添加功能
【发布时间】：2011-03-15 02:03:30
【问题描述】：

我正在开发一个有点难以使用的系统。它 99% 未记录，不遵循最佳实践并且相当难以理解（全局变量、跨越 50 行的方法、eval 滥用等）。不幸的是，我对代码库还很陌生，我需要添加功能。

我确信其中有我可以重用的代码，但我必须在最后期限之前完成，而且我担心花在挽救上的时间最终会导致我匆匆忙忙。从长远来看，什么更好？我的一部分想要尽可能地重用，但另一部分说我应该专注于从头开始编写新功能，冒着重复的风险（计划在我有更多时间花在现有代码上时进行重构） ?我倾向于后者，但想听听一些意见。

谢谢！

【问题讨论】：

标签： php oop refactoring code-reuse legacy-code

【解决方案1】：

http://www.joelonsoftware.com/articles/fog0000000069.html

http://discuss.joelonsoftware.com/default.asp?design.4.469415.13

http://www.joelonsoftware.com/articles/fog0000000007.html

http://www.paulgraham.com/hp.html

话虽如此，如果有小部分需要清理，那通常没问题。一旦您进行了一段时间的工作，您就会更好地了解战略性的本地化重写在哪里最有效且最不危险。

在生产代码库中，请记住，为客户保持现状比推出新产品更重要。它不会阻止你的老板对你大喊大叫。但是问问自己，有多少次因为错误而切换到替代产品，有多少次是因为您想要的增强功能在其他可行的产品中不够快。

【讨论】：

是的，我读过一些关于重写与重构的争论……在这种情况下，虽然它并不是真正的重写。我实际上正在添加功能，并且正在考虑是否应该花大量时间寻找可以重用以避免重复的现有代码......或者只是为新功能编写所有内容并在我的时间预算中感到舒适，然后重构稍后重复代码。不会触及旧代码。
不看代码库我能提供的最好的就是从旧代码库中学习。我非常喜欢第一篇文章，因为它提醒我在遗留问题上花费了多少时间和精力来修复错误。为什么那里有这个或那个奇怪的案例？可能是因为有人花了一周的时间找出一个不起眼的错误。除非您需要，否则不要过度使用全局变量 - 有时遗留系统充满了它们，您必须这样做，因为全局变量现在是“接口”的一部分。带回很多关于 20 年前 fortran 2 工作前的回忆。 :-)
我同意，我意识到有很多变数正在发生，而且不是那么简单，我想这就是我提出这个问题的原因。我想我可能会尝试从这两个世界中获得最好的结果 - 给自己 x 的时间来找到要重用的代码，然后从那里开始。
我认为这是明智的。特别是在新的代码库中。在您计划征服它之前了解这片土地的布局。孙子会自豪的。 :-)

【解决方案2】：

我会按照你的直觉去写：用你知道的方式写。 TDD，如果那是您的方法；无论如何，请尝试确保您的新东西经过合理的测试覆盖（当然，比现在的东西少）。

以后，您可能确实有机会进行重构，找到重复的功能，并选择要保留的方法和类；在这些情况下，您很可能会发现自己是守门员。

当然，“未来”完全有可能永远不会到来。至少你的新东西是有效的、可读的和可重用的——这比你花时间在现有代码库中追踪一个函数（如你所描述的那样）并重用它要好。

【讨论】：

【解决方案3】：

阅读Working Effectively With Legacy Code可以克服您所经历的一切。我知道您说您的截止日期很紧，但匆忙而不完全理解核心代码库可能（并且可能）会产生一些负面影响。

此外，您提到计划在时间允许时进行重构。我已经说过很多次了，让我告诉你，几乎总是那个时候永远不会到来。第一次做对，为下一个开发人员或稍后添加新功能时帮自己一个忙。

【讨论】：

感谢推荐书。我确实意识到“我以后再做”的态度是危险的，我认为这是我犹豫不决的一个重要原因。

【解决方案4】：

我们的业务在同一条船上：第一阶段的方向可行，但并不理想。第二阶段改变了商业模式和逻辑……这个阶段是离岸的，如果公司真的了解他们选择建立的框架，这本身就不会成为问题。所以，在这里，我们正在努力完成第 3 阶段（消除第 2 阶段的混乱，按预期正确使用框架），同时为不得不在编写如此糟糕的代码库上工作而感到遗憾。存在重大挑战 - 使用两个 javascript 框架、笨拙的旧 UI、垃圾代码以及对框架的重大更新，这使得我们使用的版本过时并且几乎不可能迁移到新版本。

这是我们选择做的事情......它可能不适合您的情况。首先，我们的产品开发副总裁花了两周时间彻底重构了数据库结构。他重新安排我们的编程人员根据需要修改现有代码，以适应适当、高效的数据库结构。完成该（痛苦的）步骤后，我们休息了两周以在新功能上取得进展。然后，我从我的职责中休息，彻底重构 UI，取消使用一个 Javascript 框架，以便我们在一个通用平台上（多么概念，暗示可怕的离岸公司......）并制作有效使用现代、高效、当前的 UI 元素。我们将遵循 80%-20% 的任务组合，直到产品完成 beta 测试——80% 实现最终需求，20% 重构代码并清理遗留的混乱。每个员工都被分配了一个他们负责“清理”或提高效率的区域。流程文档也是一项已被委派的任务，并且是每个员工每周工作的必需百分比。

我认为，我们流程成功的关键是即使在第 3 阶段完成之前，也要关注第 4 阶段。正在以最大的效率和可互换性构建新代码，因此如果以及当我们离开这个过时的平台时，将需要进行最少的更改。我正在尝试一种方法来划分我们的流程（而不仅仅是代码），以便理论上可以在适当的时候将它们单独移动到新框架中。我们未来的计划是纸上谈兵，需求清单不断发展，研究正在进行中，以寻找最佳工具。最重要的是，团队负责人坚持正确和高效地做事，因此当前或未来的任何事情都不会做得不好。

很难向管理层证明您需要后退才能前进。当您公司的整个未来都依赖于像我们一样处于测试阶段的产品时，情况就更加困难了。我把它比作花更多的钱买一个省油的电器……它现在会花更多的钱，但最终它会获得巨大的经济回报。我认为在这种情况下取得成功的诀窍是为你的产品找到“足够好”以独立存在的中位数，同时你花时间让产品变得更好。制定满足该中值的策略将挑战业务部门的耐心，并最终在成功时使您成为英雄。制定一个强有力的计划，传达该计划，与他人相处融洽，并努力工作。很快，您将再次享受生活！

【讨论】：

【解决方案5】：

不用担心您要添加的这一小块功能。做起来又快又脏。

如果您的团队正在计划重构源代码，请确保您得到管理层的支持。让您的管理层了解您现在面临的问题：当前的代码库没有遵循最佳实践。应用程序越是非结构化，添加功能所需的时间就越多。构建新功能不会花费最多时间，但确保它在每种情况下都能按预期运行，并且在 foobar 出现问题时解决问题也将花费宝贵的时间。

如果您要重构应用程序，请考虑如果您选择一些现成的解决方案来更好地实现应用程序的某些部分，您将获得的收益：

像 Zend Framework 这样的 MVC 框架
Zend 框架类库，用于 Auth/ACL/OAuth/等常用组件。
像 Doctrine 或 Propel 这样的数据库抽象层或 ORM
只有一个 javascript 库：JQuery（可能与 JQuery UI 结合使用）
自动部署系统，如 Phing 和 Ant
类的单元测试
基于使用 Selenium 的用例的验收测试
完善的版本控制系统和策略

我可以继续说一会儿。有时，应用程序的完全重建会后退两步，但会前进四到五步。

【讨论】：