如何反对降低传统代码库的质量标准？[关闭]

我们这里有一个庞大的遗留代码库，其中包含您无法想象的错误代码。

现在，我们定义了一些质量标准，并希望在全新的代码库中实现这些标准，而且还可以通过触摸旧代码来实现。

而且，我们使用Sonar（代码分析工具）来执行这些操作，而Sonar已经有数千次违规。

现在开始讨论降低对遗留物的侵犯。因为它是遗产。

讨论是关于可读性规则。像它可以有多少个嵌套的ifs / for..。

现在，我该如何反对降低传统代码的编码质量？

代码只是达到目的的一种手段。最终的目的可能会有所不同，但通常是利润。

如果是利润；然后成功争论任何您想证明它会提高利润的事情-例如通过增加销售，降低维护成本，降低开发成本，降低工资，减少再培训成本等。如果您不能/不表明会提高利润；那么您通常只是说这是一种很有趣的向厕所里冲钱的方法。

我和我本人都是遗留代码的生产者和维护者。如果您的工具产生了“成千上万次违规”（就此而言，甚至是成百上千次违规），那就算了吧，它不适用于这种情况...

我认为原来的开发人员已经走了，并且无法进行讨论。因此，周围没有人了解设计和编码样式的原因和原因。纠正成百上千的违规将不再是在这里和那里重写几行代码的问题。相反，它无疑需要重构/重新功能分解。您尝试对任何现有的大型代码库进行此操作，而无需深入了解其当前设计，您肯定会引入一整套新的bug /问题/ etc。只是一盒新的蠕虫，甚至比您现在拥有的蠕虫更糟（或者比您的工具>> thinks <<您现在拥有的蠕虫更糟）。

解决“成千上万的违规行为”的唯一明智方法是从头开始重写。一项长期而昂贵的工作，几乎不可能卖给管理层。在这种情况下，它们可能是正确的...

旧版代码通常只需要进行调整。就像y2k一样，或者当股票从256位变为小数时。我做了两个cr * p的负载。还有很多其他类似的东西。通常，这是非常“精确的”，因为您可以“读取”有时不良的样式，不良的功能分解，不良等，并找到需要修改的位置的集合。然后，“在那些地方之间”发生的事情，即更高层次的流程，可能仍然是您的一个谜。只要确保您了解要更改的本地化功能，然后进行测试，测试，测试任何副作用等，您的本地化知识将无法预期。

如果您无法通过这样的代码看到自己的方式，那么您可能不是维护遗留代码的最佳人选。有些人可以从空白屏幕开始编写漂亮的程序，但不能以其他人的代码庞大的代码库开始并进行维护。其他人可以维护代码，但不能从头开始。有些可以同时做。确保合适的人维护您的旧代码。

偶尔您可能需要重新设计和重写旧代码库的情况是，当业务（或其他）需求变化到一定程度，以至于无法调整需求时， 。到那时，您最好首先编写一个新的功能需求文档，以确保所有利益相关者都参与其中。基本上，这是一个全新的游戏。

>>错误<<唯一的一件事就是尝试像对待新开发一样对待旧代码维护。那一件错误的事情似乎恰恰是您想要走的路：)相信我，那不是您想做的。

问题不在于代码的好坏。问题是您将从多少投资中获得多少收益。

因此，您拥有一个可以查找数千种不喜欢的东西的工具。您可以选择忽略工具的结果，也可以投入工作来更改成千上万的事物。有很多东西。人们不会集中精力，不会在进行更改时，在审阅它们时就不会集中精力，而且这种方法也不会得到适当的测试，因为要花很多时间才能弄清楚如何测试（或只是尝试）每项更改，因此会出现错误。因此，在找到并修复这些错误之前，您花费了大量的时间和金钱，但总体上还是没有得到回报。

另一方面，工具不仅可以发现自己“不喜欢”的东西，还可以发现错误或潜在的错误。如果遗留代码仍在广泛使用，那么正确的工具实际上可以发现错误。因此，将编译器警告一个接一个地打开，检查它们是否有用（不是全部都有用）并修复这些警告是值得的。

如果没有破裂，请不要修复

实际上，应该在每个软件开发人员和管理人员身上添加纹身，以使他们永远不会忘记它。

是的，它违反了所有现代编码约定。是的，它是用FORTRAN-77用C语言包装的，因此可以从Python调用。是的，这些都是非结构化的GOTO。是的，有一个子程序长三千行。是的，变量名仅对克罗地亚人有意义。等等等

但是，如果经过十多年或更长时间的愤怒测试，并且已经通过了，那就别说了！如果需要的修改很小，则使其尽可能小并尽可能地局部化。其他任何事情都有更大的风险来破坏不需要修复的内容。

当然，有时您会发现它确实是无法维护的，并且适应“小”修改的唯一方法是从头开始重写。在这种情况下，您必须回到要求更改的人处，并告诉他更改的费用（以美元或工时为单位进行重写，并为不可避免的新错误付出大量的汗水和眼泪）。

很久以前，Digital公司的一个磁盘驱动器出现了很多故障。他们最终召回，并在戈德更换了所有这些，他们知道要花多少钱。显然有一滴胶在HDA内部固定了一个过滤器。工程清单中称胶水为“非参数指定，无替代品”。通过购买其他胶水，每个磁盘驱动器的bean-counter节省了不到1美分。在使用了几年之后，它在HDA内散发出蒸气，从而杀死了驱动器。直到他修好它，才打破。毫无疑问“这只是一个微小的变化……”

绝对没有必要降低遗留代码的质量级别。也无需立即修复警告。只要确保您在项目的每个组件中进行的所有“新”更改都遵循高质量标准即可。即没有提交应该增加警告计数。

这是一种统一且简单的方法。

它允许旧的旧版代码按原样工作（因为无需对其进行不必要的修改）。它确保了新代码的高质量。无需额外费用。

风险控制...。

• 大型遗留代码库中的代码至少已通过软件的实际使用情况进行了测试。
• 大型遗留代码库中的代码被自动化的单元测试所覆盖，这是非常不对的。
• 因此，大型遗留代码库中的任何更改都会带来很高的风险。

成本…。

• 在编写代码时使代码通过代码检查器很便宜
• 在以后的状态下执行此操作会花费更多

效益

• 您希望遵守编码标准可以更好地设计代码。

• 但是，要让某人花很多星期更改代码只是为了消除来自编码标准检查工具的警告，这不太可能会改善代码的设计。

• 除非复杂的代码被不懂的人分割成简短的方法，否则简单的代码会更清晰 易懂。

建议…。

• 如果一段代码显示其中包含许多错误，或者需要进行大量更改以添加其他功能，则花100％的时间了解它的作用。
• 也要花时间在该部分代码中添加良好的单元测试，因为您已经证明了他们的需求。
• 然后，您可以考虑重构代码（您现在已经了解了），因此它也通过了新代码检查。

亲身经历...。

• 在从事程序员工作的其他20年中，我从未见过这样的情况：盲目改变旧的代码以从新的编码标准检查器中删除所有输出，除了增加被指示这样做的承包商的收入外，还没有任何好处。
• 同样，当必须使旧代码通过代码审核时（TickIt / ISO 9001做错了），这要求旧代码看起来像新的编码标准。
• 我已经看到很多情况，在新代码上使用编码标准检查工具通过降低现行成本而获得了巨大收益。
• 我从未见过有一家公司会为维护拥有大量客户的产品中使用的旧代码付出代价。
• 我已经看到公司失败是由于未能以太慢的速度从客户那里获得收入……。

是否正在讨论降低该工具的阈值？...还是我误会了它。它以一种令人困惑的方式编写。如果不是，请放弃我的答案。

恕我直言，降低工具的敏感性是一个好主意。为什么？因为它将突出显示最繁琐的代码。另一种方法是生成带有数千个违规行为的报告，但由于规模庞大而变得毫无用处。

...除此之外，只需与相关人员讨论，并听听他们的原因。

我会尝试将旧代码与新的干净代码分开。在例如Eclipse中，您可以通过将它们放置在相互使用的不同项目中来实现此目的。“ 清洁”项目和“旧式”项目。

这样，您可以使用不同的质量标准分析声纳中的两个项目。这些标准仅在规则的重要性上有所不同。规则本身应该相同。这样，您就可以在看到 “legacy'项目需要采取什么‘固定’，以满足标准 ” clean'项目。

只要您设法将一些旧代码提升到更高的标准，就可以将其移至“干净”项目中。

在每天的工作中，由于时间的延迟，您无法完成将您接触的每个班级提高到“清洁”项目标准的目的。但是，您应该尝试通过每次尝试改进旧代码来逐步实现这一目标。