想象一下,你 90% 的工作只是在一个非常庞大、非常破碎的网站上对问题进行分类。想象一下,这个网站是用你所见过的最紧密耦合、最不内聚的 PHP 代码编写的,这种代码类型会将原始开发人员添加到你的“一见钟情”列表中。想象一下,这个 Web 应用程序由 4 个非常不同的部分(1 个商业部分、2 个“重新利用”和 1 个定制部分)和一大堆虚拟胶带和垫片组成。想象一下,它包含一种编程实践,其中网站的主要组件实际上依赖于无法正常工作的东西,而修复这些损坏的东西通常会破坏其他东西。想象一下,您从太多糟糕的经历中了解到,更改网站中看似无害的部分,例如拆分“名称” 字段分为两个单独的“第一个”和“最后一个”字段,这将使网站陷入瘫痪,需要数小时的回滚、合并和补丁。想象一下,多年来一直恳求客户放弃代码并重新开始,但却遇到了企业级的绝望和绞尽脑汁。然后想象一下获得 ASAP/EMERGENCY 票来实现在任何其他网站上需要 4 小时的新功能,但您对这个网站了解得更好,所以您报价 40 小时,然后按此收费并收取 80 小时的费用,但这没关系,因为客户习惯了他们的网站。想象一下,多年来一直恳求客户放弃代码并重新开始,但却遇到了企业级的绝望和绞尽脑汁。然后想象一下获得 ASAP/EMERGENCY 票来实现在任何其他网站上需要 4 小时的新功能,但您对这个网站了解得更好,所以您报价 40 小时,然后按此收费并收取 80 小时的费用,但这没关系,因为客户习惯了他们的网站。想象一下,多年来一直恳求客户放弃代码并重新开始,但却遇到了企业级的绝望和绞尽脑汁。然后想象一下获得 ASAP/EMERGENCY 票来实现在任何其他网站上需要 4 小时的新功能,但您对这个网站了解得更好,所以您报价 40 小时,然后按此收费并收取 80 小时的费用,但这没关系,因为客户习惯了他们的网站。
以下是您还应该想象的其他一些事情:
- 现在根本没有测试
- 有 googleteen 不同的登录层。有些客户实际上对网站的不同部分有 3 个不同的帐户
- 当我说“紧密耦合”时,我的意思是 include/require 语句的循环可能会像凯尔特结一样映射出来
- 当我说“最不凝聚力”时,我的意思是有些东西的组织方式有点像 MVC,但它并不是真正的 MVC。在某些情况下,您可能需要几个小时才能了解 URI A 是如何映射到文件 B 的
- UI 写得像“突兀”和“不可访问”是当时的流行语
想象一下,是否值得尝试达到中等水平的测试覆盖率?或者你是否应该,在这个想象的场景中,继续尽你所能用你得到的东西,希望,祈祷,甚至牺牲,客户会同意在这些日子里重写,然后你就可以开始写作了测试?
附录
自从你们中的许多人提出以来:我已经接近了在我必须约会的每一次机会中重写的可能性。与我一起工作的营销人员知道他们的代码是垃圾,他们知道这是他们最初选择的“最低出价”公司的错。我可能已经超越了我作为承包商的界限,指出他们花了一大笔钱在我身上为这个网站提供临终关怀,而且通过从头开始重新开发,他们会很快看到投资回报率。我也说过我拒绝按原样重写网站,因为它并没有真正做到他们想要它做的事情。计划是重写 BDD 风格,但将所有关键玩家集中在一个地方很难,我仍然不确定他们是否知道自己需要什么。无论如何,我完全希望这是一个非常大的项目。
感谢您迄今为止的所有反馈!