【问题标题】:How do you remove/clean-up code which is no longer used?你如何删除/清理不再使用的代码?
【发布时间】:2010-03-19 13:35:55
【问题描述】:

我们有一个项目必须进行彻底的检查才能按时发货。它里面有很多没有实际使用的代码。我想清理代码,删除所有枯木。我有权这样做,我可以让人们相信这是一个商业上明智的做法。 [我有很多自动化单元测试,一些自动化验收测试和一个可以手动回归测试的测试人员团队。]

我的问题:我是一名经理,但从技术上讲我不知道该怎么做。

有什么帮助吗?

【问题讨论】:

  • 您问的是rm 命令吗?或者询问如何使用 Subversion 从存储库中删除文件?

标签: refactoring


【解决方案1】:

我认为问题是如何找到未被使用的代码,对吗?不同语言的答案略有不同,但有一些通用的方法。我离开学校的第一份工作是在一个大型交付项目中查找并删除数万行未使用的代码。

第一个原则是关注那些从不调用的东西,而不仅仅是不必要的。查找和删除前者是一种非常机械且风险较低的方法。后者是一项重构工作,并且更复杂一些。总是最好先取出简单的东西。

鉴于此,您想要的是静态分析的一部分,并且维基百科上有大量 available static analysis tools 列表。您还应该在堆栈溢出中搜索“死代码”和您的语言(C++、Java 等)。过去,人们曾以多种不同的方式提出过这个问题。通常,您运行一个工具,查看它所说的未使用的内容,删除它,然后再次运行该工具以查找只有死代码正在使用的东西。重复。

从经理的角度来看,您绝对是正确的。你有很多单元测试的事实意味着两件事:你可能正在为你不使用的东西维护单元测试(这需要花钱),你拥有的测试会让你进行这些机械更改信心。最好的选择是在您的团队中找到喜欢自动化事物的人;他们通常有正确的心态来做这种工作。如果您有多个人在研究它,我会让一个人学习静态分析器并制定一个可以遵循的模式。然后将团队分成不同的代码部分,这样它们就不会发生冲突。

这种工作可以进行得非常快,而且通常有很好的回报。只要确保人们一次删除一件,编译,做一些简单的测试,然后在继续之前提交。定期(通常在大改动之后,或至少每天)进行一次完整的干净重建和“大”测试,以确保您真的没有破坏任何东西。您可以做的最糟糕的事情是尝试找到系统中的每一段死代码并一次将其全部删除然后提交。我保证删除其中一个会破坏系统,你永远无法弄清楚它是哪一个。但是,如果您有条不紊地工作,这可能是一项风险非常低的工作。

【讨论】:

    【解决方案2】:

    确保将其全部签入到您的源代码控制系统并标记为特定版本(预发行版或您能记住的版本)

    在现场和非现场备份代码

    对代码运行静态分析工具以识别枯木

    删除枯木

    重建并重新运行所有测试

    或者你可以忽略它;-)

    【讨论】:

    • 如果它没有坏,就不要修理它! ... +1 就“教条”和“务实”方法提出合理建议!
    • 然而,我认为死代码是坏代码:不管有没有这样的应用程序都可以工作,但死代码会给您的开发人员增加额外的工作,特别是从长远来看,当老手转移到其他项目和新开发人员难以理解该应用程序。
    • 谢谢拉尔斯。我经常遇到令人绝望的令人费解的代码,这些代码是因为害怕实际修复他们不理解的代码而开发的,并且无休止地试图找到风险最小的更改来解决“今天的问题”。格言“如果没有损坏,就不要修复它”在实践中经常导致代码变得更加脆弱和不可维护。这并不意味着不断重写工作代码是一个好主意。 Martin Fowler 写了很多关于何时应该和不应该重做“工作”代码的好东西。但是删除未使用的代码应该是轻而易举的事。
    【解决方案3】:

    我不认为有任何简单的方法。我喜欢的一个想法是编写相当完整的自动化验收测试,然后使用覆盖率工具查看哪些代码没有被执行。

    【讨论】:

      【解决方案4】:

      首先,我假设您的代码已签入某种版本控制。如果不是,那么您的问题比未使用的代码要深得多。鉴于此,请按照link 的建议删除它。

      【讨论】:

      • @tikiboy - 我不忍心对你投反对票。但您可能会考虑删除这个对严肃问题的荒谬答案。
      • @Sky,感谢您没有在我的第一篇文章中对我投反对票。我并不是说这是一个荒谬的答案,而且这个问题本身有些含糊。我引用的链接可能不够明显,我已经稍微编辑了我的答案以使其更清晰。该链接本身解决了我有时会发现自己正在做的事情 - 无法实际删除代码。它可能无法准确解决这个问题,但正如我所说,这个问题有点模糊。如果您仍然觉得这个答案很荒谬,那就投反对票吧。
      • OP 按删除键没有问题,他正确地关心破坏构建,并正在寻找有关如何负责任地进行此操作的指导。对于小型应用程序,这是一项微不足道的任务,但在更大的范围内,它可能是焦虑和失去睡眠/工作/工作的根源。所以 - 也许并不荒谬,但并没有真正解决 OP 问题,并且可能被解释为轻率。我的 0.02 比索。欢迎来到 SO。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-04-15
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多