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

也许还有那本书” Working effectively with Legacy Code “值得一读吗?

编辑

我也建议你看 this presentation from Uncle Bob 其中涉及到这个场景,以及如何使用“渐进式加宽”将坏代码基转换为好代码基

从找到任何自包含的函数开始。函数只引用传入的参数。将它们移动并组织到辅助类中。这可能只是暂时的,因为很多人以后会在不同的类中结束,但这将有助于识别一些重复的代码,并开始组织工作。然后,看看它们是如何使用的,根据这些用途编写测试。拍拍自己的后背。现在,您已经开始使代码具有可维护性。

InfoQ发布了另一篇文章 How To Do Large Scale Refactoring 特别是这类东西,还有一篇更古老的文章叫做 Refactor or Rewrite? 还有一些技术,比如 Mikado Method 当你必须意识到你不可能总是在一步中做出你想要的行动,你必须采取其他行动来建立和实现你的目标。

绝对不是。

如果你说多个事物依赖于其他事物 不起作用

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

我会从一个非常坚定的建议开始重新编写代码库。有些时候必须告诉那些手足无措的客户直截了当的事实。还有多少开发者会在基础不健全的情况下工作?做一些漂亮的成本/收益图表。

写 . 不要忽视这一点。我是说我不会试图在现有的代码库上编写测试。

试试看

在站点的一小部分(我知道您无法完全隔离任何部分,但您仍然可以针对部分)尝试一下。

给自己定一个时间预算 (这取决于您确定什么是负担得起的/值得的),然后进行一些测试和重构。如果不成功,退后。如果有,继续。

首先,如果你的客户习惯于你的估价是实际需要的一半,那就修正你的估价吧!客户对评估结果不满意是件好事,但关键是你要让你的评估更符合实际需要的努力。如果没有这些,哪位客户会同意进行重大的重构,更不用说重写了。因此,获取一些正确估计的历史记录,然后着手重做项目。

如果这和我一直在处理的类似,那么它的顺序是将一个方法拉到一个helper类中,然后将它修补回现有的代码中,这似乎不值得——但每次您必须再次接触系统的这一部分时,它确实会得到回报。就像他们说的那样——“离开它比你发现的更好”,你会发现它在你每次回到它的时候都会变得更好。测试是最好的方法让它比你发现的更好。

但是,说真的,在客户对你处理返工的能力完全有信心之前,要让他们对你的估计的准确性有信心。

现在,要意识到这可能不是一个微不足道的任务。为了编写测试,您需要修改代码使之可测试。为了修改代码,您需要进行测试。所以你陷入了一个依赖循环。。。

然而,看看潜在的好处。这会告诉你它是否值得。

记住,你不需要100%的保险来获得收益。每次测试都会增加意义。。。

你不能废了它。客户不会让你这么做的,而且这可能不是最好的途径。

因此,与其报价40小时,而不是一个本应花费数分钟的修复。。。引用60。客户觉得还可以。用40来修复,用20来重构。。。并对重构的内容编写测试。如果60到100,那么花费120;80修复,40重构/测试。

及时改进你的正常估计,或者找新的工作;现在的情况,听起来,会让你讨厌我们的领域。

完全 ,你必须从头开始重写系统的某些部分,这不可避免地会在这个过程中导致大量的错误。

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

最重要的事情(购买后 Working efficiently with legacy code )从小事做起。我在几个项目中工作,每一个项目都有几千行PHP代码,而且常常没有一个函数(甚至不考虑对象),每当我需要更改代码时,我都会尝试将该部分重构为一个函数并为其编写测试。这是与广泛的手动测试相结合的部分,所以我可以确定它的工作与以前一样。当我有多个函数用于类似的事情时,我将它们作为静态方法移动到一个类中,然后一步一步地用适当的面向对象代码替换它们。

从将其转换为函数到将其转换为实际类的每一步都要进行单元测试(这不是很好,因为90%的代码都是SQL查询,几乎不可能建立一个可靠的测试数据库,但我仍然可以测试它的行为)。

因为有很多代码重复(我发现一个SQL查询在一个文件中重复了13次,在该项目的其他50个文件中重复了很多次),所以我可以更改所有其他地方,但我不能更改,因为这些地方既没有经过测试,也不能确定周围的代码是否以某种方式依赖于该代码(想想看 global

这是一项漫长而乏味的工作,每当我看到代码时,我都觉得离精神崩溃更近了一步(或者更确切地说是一个飞跃),但是代码质量会提高(缓慢但主要是可靠的)。

你的情况看起来很相似,所以也许我的想法可以帮助你编写代码。

简言之

从小处做起,只改变你所做的,开始只写有限的单元测试,并随着对系统的了解越多而扩展它们。

首先做黑盒,功能测试,连接的部分或零碎的东西。这使得继续开发和重构/重写变得更加容易。

但我们最终还是需要一个单元来测试。

它还远未防弹,但当您知道有一个测试套件在等待验证您的代码更改时,所有开发人员都更有信心敢于更改/修复某些东西。

如果事情表现可靠,你就可以测试它们,对吧?您的系统大部分时间都在工作,因此您可以测试这些成功条件。

…网站无害的部分,例如 将“名称”字段拆分为两个 分开“第一个”和“最后一个”字段, 会让网站屈服

把一个字段分开,比如名字和姓氏,听起来像是一件巨大的事情,但听起来你已经吸取了教训。至少,试着为一个全尺寸的测试系统获得一些资金,并将程序落实到位,使生产数据自动转移到它,这样你就可以完全测试这件事了。

听起来很可怕。是时候把旧简历付之东流了?