当前位置: 首页 > 科技观察

如果没有时间重构,我们是否应该为遗留代码编写测试?_0

时间:2023-03-16 11:26:00 科技观察

编者按:本文主要围绕“是否应该为遗留代码编写测试计划”展开讨论。有同事主张“一次性大规模重构”优于多次小规模测试,引来不少网友提出不同意见。以下是几位网友的回答和不同票数的肯定。欢迎朋友们一起讨论!网友被问:工作中遇到问题,我一般倾向于采纳本书中给出的建议《高效处理遗留代码》。我将删除代码依赖项并将一些代码移动到VisibleForTesting公共静态方法和新类中,以使该代码(或至少其中的一些代码)可测试。此外,我编写测试以确保我对新功能的修改或添加不会影响遗留代码的固有效果。但是一位同事不同意我的做法。他的观点是:?首先,原始代码在新环境中可能无法正常工作。为它编写测试可能会使以后的修复和修改变得更加困难,因为开发人员必须自己理解测试并在继续之前修改它们。?如果遗留GUI代码包含某种逻辑(例如,约23行,2-3个if/else块),那么为其编写测试真的毫无价值——毕竟,这部分代码的功能并不重要根本。?代码库的其他部分也可能存在类似的坏情况(我是新手所以没见过);因此通过一次性大规模重构更容易清理它们。把逻辑抽出来,就排除了这部分代码以后出问题的可能性。如果我们没有足够的时间对遗留代码进行全面重构,我是否应该放弃提取可测试部分并为它们编写测试?这样做有什么我没有注意到的缺点吗?请提出你自己的意见。感兴趣的朋友可以点击这里查看关于这个问题的声明原文。这是错觉网友KillianFoth的回答(支持79票):说说我对这个问题不成熟的看法:不写测试的理由看似普遍适用,其实这只是错觉。首先,是的,现有代码可能有问题——但也有可能是正确的。由于所讨论的应用程序作为一个整体对我们有价值(否则我们可以将其丢弃),我们不妨在没有细节的情况下假设它是正确的。“编写测试让事情变得更加困难,因为它在整体解决方案中引入了更多代码”的态度既粗鲁又站不住脚。其次,请利用各种手段,扩大现有重构、测试、改进成果的应用范围,在实现价值最大化的同时,尽可能减少投入所需的精力。使用值格式化的GUI解决方案不应该是首选。但仅仅因为它“很容易”就放弃测试也是不科学的。几乎所有严重的错误都是因为人们认为他们知道真相,而事实恰恰相反。第三点,“我们将来要一次性做一个大规模的重构”,这是一个很好的主意。一般来说,就算你暂时什么都不做,以后总有机会对遗留代码进行如此大规模的清理。但我个人相信“稳扎稳打才能赢”的理念。打好基础网友guillaume31的回答(34票支持):说说我的一些想法:当我们重构遗留代码的时候,我们写的测试偶尔会不会和理想的规范冲突,这并不重要。重要的。真正重要的是他们对项目的当前状态进行了现实的评估。重构的要点是通过一系列小而独立的功能步骤,让代码更加简洁;您当然不想在进行重构时担心错误修复。如果我们在这个过程中发现了一个严重的漏洞,它不会随着时间的推移而消失。我们可以为它编写一组回归测试并暂时禁用它,或者将此错误修复添加到我们的待办事项列表中以备后用。一次只做一件事,这是有条不紊的。我也同意纯GUI代码很难测试并且可能不完全遵循《高效处理遗留代码》书中的重构指南。但这并不意味着我们也应该将与GUI层无关的其他代码放在一边而不对其进行任何测试。另外需要强调的是,“12行,2-3个if/else块”绝对不是小事。任何涉及哪怕一丁点状态逻辑的代码都应该进行测试。以我个人的经验,大规模的重构是困难的,而且通常是无效的。如果不能为自己设定精确、详细的执行目标,那么整个重构过程很可能会陷入无休止的恶性循环,甚至最终陷入拔地而起的绝境。任务。修改程度越高,破坏原有内容的风险就越大,导致我们失败的可能性就越高。通过小型、临时的重构取得渐进式进展并不意味着“破坏未来大规模重构的可能性”,它是一种促进手段——即巩固应用程序所依赖的主干和基础。总之,我们应该采取这种循序渐进的应对策略。网友RobbieDee的回答(支持9票):一些公司固有的文化主张允许开发人员随时增强代码,而不是为其提供更直接的附加值——即新功能。或许自由发表个人意见有点画蛇添足,但在我看来,这种做法确实得不偿失。纯粹、干净的代码肯定会给开发人员带来回报,但回报还不够明显。我个人同意所谓的“童军原则”(加入童军的孩子需要“在离开营地前清理干净”),但其他人(如您所见)往往不同意。换句话说,不可知论和技术工作压力会对软件产生负面影响。也许之前的开发人员时间太紧(或者太懒,甚至没有经验),所以他们可能在有限的时间内想出了一个有缺陷但已经很完美的设计。重构这些开发虽然看似能够取得不错的效果,但也可能给原本正常运行的代码带来新的漏洞,甚至影响用户。相比之下,某些更改的风险可能低于其他更改。例如,我面临的场景有很多重复的代码,可以安全地移出对业务影响不大的子程序。综上所述,我们必须在这样的困境中做出判断:我们必须考虑未来什么时候真正开始重构,我们必须确定从头开始编写自动化测试能够为业务带来哪些有形的价值。译者:Nuka-Cola英语:如果没有时间重构,我应该为遗留代码编写测试吗