Php 是否值得尝试为世界上耦合最紧密的站点编写测试？

想象一下，你90%的工作仅仅是在一个非常庞大、非常破碎的网站上对问题进行分类。想象一下，这个网站是用你见过的最紧密耦合、最缺乏内聚性的PHP代码编写的，这种代码会将原始开发人员添加到你的“一目了然”列表中。想象一下，这个web应用程序由4个完全不同的部分（1个商业部分、2个“重新调整用途”部分和1个自定义部分）以及大量虚拟管道胶带和垫片组成。想象一下，它包含一种编程实践，在这种实践中，网站的主要组件实际上依赖于工作不正常的东西，而修复这些坏东西通常会破坏其他东西。想象一下，你从太多糟糕的经历中了解到，改变网站的一个看似无害的部分，例如将“名称”字段拆分为两个单独的“第一个”和“最后一个”字段，将使网站崩溃，需要数小时的回滚、合并和修补。想象一下，多年来恳求客户放弃代码，重新开始，但却遭遇了企业级的绝望和绝望。然后想象一下，在任何其他网站上，获得ASAP/紧急通知单来实现新功能都需要4个小时，但你对这个网站更了解，所以你引用40个小时，然后就这样做了，并支付80个小时的费用，但这没关系，因为客户已经习惯了他们的网站

这里还有一些你也应该想象的事情：

• 现在根本没有测试
• 谷歌有不同层次的登录。有些客户实际上在网站的不同部分拥有3个不同的帐户
• 当我说“紧密耦合”时，我的意思是include/require语句的循环可能会像凯尔特结一样映射出来
• 当我说“最不内聚”时，我的意思是有些东西是有组织的，有点像MVC，但它不是真正的MVC。在某些情况下，您可能需要几个小时才能找到URI A是如何映射到文件B的
• 用户界面写得像“突兀”和“不可访问”是当时的流行语

想象一下所有这些，甚至值得尝试实现中等水平的测试覆盖率吗？或者，在这个想象的场景中，你是否应该继续尽你所能利用你所得到的，并希望、祈祷，甚至牺牲，客户会同意某一天重写，然后你就可以开始编写测试了

附录

自从你们中的许多人提起这件事以来：我一直在寻找机会重新写一封信。与我共事的营销人员知道他们的代码是垃圾，他们知道这是他们最初合作的“最低出价”公司的错。作为一名承包商，我可能已经超越了我的界限，我指出他们花了一大笔钱在我身上为这个网站提供临终关怀，通过从头开始重新开发，他们会很快看到投资回报。我还说过，我拒绝按原样重写网站，因为它并没有真正做到他们希望它做的事情。我们的计划是重写BDD风格，但是把所有关键球员集中在一个地方是很困难的，我仍然不确定他们是否知道他们需要什么。无论如何，我完全希望这是一个非常大的项目

感谢到目前为止的所有反馈

绝对不是。 如果你说很多东西都依赖于其他不起作用的东西，那么你怎么能开始测试它呢

就我个人而言，我会说放弃它，重新开始。需要80分钟的4小时功能？我希望这是夸大其词。你一定很头痛

我将从一个非常坚定的建议开始，重新编写代码库。有些时候，必须把直言不讳的事实告诉那些心急如焚的客户。有多少其他开发人员将在一个破碎的基础上工作？制作一些漂亮的成本/效益图表

务必为您编写的代码编写测试。不要忽视这一点。我是说我不会尝试在现有的代码基础上编写测试。

试试看 编写测试使您能够重构。如果您以足够高的级别编写测试，那么您可能会成功地进行重构，而无需每次重新编写测试

在站点的一小部分（我知道您将无法完全隔离任何部分，但您仍然可以将目标部分作为目标），这是最不值得尝试的

也许给自己定一个时间预算（由你自己来决定什么是负担得起的/值得的），然后进行一些测试和重构。如果不成功，请回滚。如果有，请继续

---

祝你好运

这听起来像是为了使其完全可测试，您必须从头开始重写系统的某些部分-在这个过程中不可避免地导致大量的错误

从你描述的情况来看，旧系统不值得投入这种努力

在任何情况下，我都不会尝试为此引入测试，但会尝试尽快获得重写的许可

---

如果你的客户没有看到光，考虑重构这个项目是否值得你自己花些时间：用干净的代码工作对你的幸福来说是更好的……维护过程中的耦合越紧密、bug越多，测试就越重要。在实践中，走开，过上新的一天

您可能在一段时间内无法获得全面保险。但您可以为实现的新代码/功能编写测试。从小处做起。不要试图同时做所有的事情

也许这本书值得一读

编辑 我还建议您观察哪些内容涉及到这个场景，以及如何使用“渐进式加宽”将一个糟糕的代码库转换为一个好的代码库

编辑2 首先查找任何自包含函数。只引用传入的参数的函数。将它们移动并组织到帮助器类中。这很可能只是暂时的，因为许多人最终会陷入困境