0

我刚开始从事一份代码非常旧的工作，编译这段代码时即使启用了基本警告也会产生数千个警告，其中许多对我来说真的很可怕。大部分代码是在 80 年代编写的，因此管理层对于让一些新工程师尝试修复它并不感到兴奋。

我的观点是消除这些警告应该是当务之急，但我没有任何数据可以支持我。我理解管理层的想法，即修复所有警告是一项严肃的工作，并且可能不值得为看起来可以正常工作的代码付出努力。我正在寻找一项指向错误/警告或类似内容的研究，因此我可以去找他们并说：“我们有 200,000 个警告，从研究 X 中，很可能有 2,000 个错误隐藏在其中。 "

这里非常相似的讨论：https ://softwareengineering.stackexchange.com/questions/111616/handling-false-positives-and-legacy-code-warnings-in-static-analysis-of-c-code

我认为这不应该因为跑题而被关闭，因为它是一个：“编程行业独有的实用、可回答的问题”。

由于题外话而关闭，但我发现了一项研究： http: //institute.lanl.gov/isti/irhpit/presentations/ensuring-sq.pdf http://collaboration.csc.ncsu.edu/laurie/论文/TSE-0197-0705-2.pdf

4

4 回答 4

4

我认为没有这样的研究。我也将在这里冒昧地说管理层是正确的——试图修复所有这些警告，只是修复所有这些警告，是一个坏主意。

您将通过修复警告来破坏事情！现在该代码可能有很多错误，但它有很多正确之处，并且对于您来说，在“工作”代码中出现问题并不会很好地解决。

在您的情况下，我将着手进行我需要做的任何修改/修复。在此过程中，为您接触的所有内容编写单元测试，并为您接触的所有内容清除警告。

我不知道你的构建系统是什么，但如果可能的话，构建你接触到的所有东西，并打开警告，为旧的东西留下警告，并将你更改的代码移动到新的“干净编译”文件中。

你不会很快掌握它，但你不能只是跳进去改变一堆东西。你必须找到一种工作方式，让你在不破坏最终用户的情况下取得进步。

更新：我将此作为评论开始，但我认为它应该成为答案的一部分。

干净的代码（没有警告的代码、具有单元测试的代码、易于理解的代码）不是也不应该成为任何实际必须在现实世界中完成任务的开发人员的目标。

干净的代码是我们使用的一种工具，它可以让我们的产品变得更好，让我们的生活（以及那些追随我们脚步的人的生活）更轻松。这是一个很好的工具，不，一个很棒的工具，但它只是一个工具。

如果您忽略了实际目标（生产有效的软件），您可能会陷入与您的流程相关的琐事中。这可能感觉很好，但它通常不能满足用户，或按时交付产品。

于 2013-02-23T20:56:32.963 回答
1

我同意 Michael Khone 所说的大部分内容，但这里涉及到相当多的产品/开发管理，评估取决于此。您应该问自己一些（但不是全部）主要问题：

  1. 这个产品的开发模式是什么？它只是不时进行小改进的错误修复，还是您不断开发新功能。
  2. 是否有足够的测试覆盖率？如果您没有像样的回归套件，那么进行重大重写就是自杀。即使这样，仍然会出现一些错误，但总比没有好。
  3. 是否需要更新工具链/平台？这一点很重要，因为许多警告实际上不会显示任何问题，只要您坚持在同一环境中确定这种“有问题的”行为是可预测的（并且可能对您的代码正确）。但是，如果您想彻底更改其中之一，那么花时间解决所有这些警告可能是一个非常好的主意。

所以警告 -> 错误很大程度上取决于您的实际产品。

于 2013-02-23T21:14:58.307 回答
1

警告并不意味着缺陷。每一个没有经过充分测试的产品都包含缺陷。如果产品经过良好测试，则没有缺陷。

由于其他原因，许多警告都是不好的。警告隐藏了新的警告（可能表明新出现的缺陷）以防止维护。因此，维护带有大量警告的代码会更加昂贵。

修复警告，有时甚至是内存泄漏等真正的缺陷都应该小心。它永远不应该机械地完成。这很可能会破坏工作产品。我在实践中见过几十次。

于 2013-02-23T20:51:22.793 回答
0

可悲的事实是，修复旧代码往往是徒劳的冒险。旧代码通常没有单元测试，编写代码的人早已离开公司。如果您在代码中看到一些奇怪的东西，它可能是出于特定原因而完成的，但是从那时起许多因素发生了变化，以至于很难进行任何影响分析。重写旧代码时有太多事情可能出错。相反，您应该专注于以良好的风格编写新代码。

另一个问题是管理层完全不理解为什么要重写代码，因为代码就是功能——时期

于 2013-02-23T21:17:11.630 回答