2

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

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

谢谢！

4

5 回答 5

4

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

话虽这么说，如果有小部分需要清理，那通常没问题。一旦你研究了一段时间，你就会更好地了解战略性、本地化的重写在哪里最有效和最不危险。

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

于 2010-07-13T00:40:20.820 回答
2

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

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

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

于 2010-07-13T01:17:43.153 回答
1

通过阅读有效地使用旧代码，您所遇到的一切都可以克服。我知道你说你的截止日期很紧，但匆忙而不完全理解核心代码库可能（并且可能）会产生一些负面影响。

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

于 2010-07-13T01:27:13.867 回答
0

Don't worry about this small piece of functionality you are adding. Do it quick and dirty.

If your team is planning a refactoring of the source code, make sure you have the support of your management. Let your management know about the issue you are now facing: the current codebase is not following best practices. The more unstructured the application becomes, the more time it will take to add functionality. Building the new functionality will not cost the most time, but making sure it will behave as expected in every situation will, and fixing the problems when something goes foobar will also cost valuable time.

If you were to refactor the application, think about the gains you would have if you would choose some readily available solutions to better implement parts of your application:

  • An MVC framework like Zend Framework
  • The Zend Framework Class library for often-used components like Auth/ACL/OAuth/etc.
  • A database abstraction layer or ORM like Doctrine or Propel
  • Just one javascript library: JQuery (perhaps combined with JQuery UI)
  • Automatic deploy systems like Phing and Ant
  • Unit testing for your classes
  • Acceptance testing based on Use Cases using Selenium
  • A well though-out version-control system and strategy

I could go on for a while. Sometimes a complete rebuild of an application is two steps back, but four or five steps forward.

于 2010-07-13T15:20:02.367 回答
0

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

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

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

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

于 2010-07-13T15:05:33.163 回答