Php 向急需重构的代码库添加特性

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

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

谢谢

这就是说，如果有小部分需要清理，通常可以。一旦你在这方面工作了一段时间，你就会更好地了解在哪里进行战略性的、本地化的重写是最有效和最不危险的

---

在生产代码库中，请记住，保持客户的现状比让新东西出门更重要。这不会阻止你的老板对你大喊大叫。但是问问你自己，有多少次你因为bug而选择了另一种产品，而有多少次你选择了另一种产品，是因为你想要的增强功能在其他可行的产品中不够快。

我同意你的直觉：按照你知道的方式写。TDD，如果这是你的方法；无论如何，试着确保你的新东西在测试中得到了很好的覆盖（当然，比现在的东西要少一些混乱）

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

---

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

你所经历的一切都可以通过阅读工作来克服。我知道你说过你的最后期限很紧，但是匆忙和不完全理解核心代码库可能会（而且可能）产生一些负面的副作用

---

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

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

以下是我们选择做的……这可能不适合您的情况。首先，我们的产品开发副总裁花了两周时间，完全重新考虑了数据库结构。他让我们的编程人员根据需要修改现有代码，以适应适当、高效的数据库结构。完成这一（痛苦的）步骤后，我们休息两周，在新功能方面取得进展。然后，我从我的职责中休息一下，完全重构UI，取消使用一个Javascript框架，这样我们就可以在一个共同的平台上（多好的概念，多糟糕的离岸公司…），并有效地利用现代、高效、当前的UI元素。我们将遵循80%-20%的任务组合，直到产品通过测试版——80%实现最终需求，20%重构代码并清理遗留的混乱。每个员工都有一个负责“清理”或提高效率的区域。流程文档也是一项已授权的任务，是每个员工每周工作的必要百分比

我认为我们的过程成功的关键是在第三阶段完成之前就着眼于第四阶段。新代码正在以最大的效率和互换性构建，因此，如果我们离开这个过时的平台，将需要最少的更改。我正在试验一种方法来划分我们的过程（不仅仅是代码），这样理论上，当时机成熟时，它们可以单独移动到一个新的框架中。我们的未来计划已在纸面上，需求列表正在不断发展，寻找最佳工具的研究正在进行中。最重要的是，团队负责人是一个坚持正确有效地做事的人，因此当前或未来不会有不正确的事情发生

很难向管理层证明，你需要倒退才能前进。当你们公司的整个未来都依赖于一款像我们一样处于测试阶段的产品时，这就更加困难了。我把它比作花更多的钱买一个省油的电器……现在它的成本会更高，但最终它会获得巨大的经济回报。我认为，在这种情况下取得成功的诀窍是找到产品的中位数，它“足够好”可以独立运行，同时你要花时间让产品变得很棒。制定一项战略以达到这一中位数将挑战业务部门的耐心，以及