在处理遗留代码时，如何克服自己的编码偏见？[关闭]

作为程序员，我们经常以我们的技能感到无比自豪，并对什么是“好”代码和“坏”代码持有非常强烈的意见。

在职业生涯中的任何时候，我们可能都会遗留下一些遗留系统，并以为“我的天哪，这段代码很烂！” 因为尽管它可能是功能完善，可维护的代码，但它不符合我们对好的代码的看法。

当您试图掌握其他程序员的工作时，如何做好心理准备？

对于任何遗留代码库，为自己做好心理准备的正确方法是从为其编写单元测试开始。

不管它是否烂，您首先需要有信心能够在不损坏任何东西的情况下进行更改！

我无法告诉您我说过几次“哦，这是完全错误的”，然后将其重写，然后找出了为什么要这样编写代码的困难方法。通常，这是一些非显而易见的未写/未记录的要求。至少在我当前正在处理的旧代码中，这是正确的。

您要等到足够长的时间才能遇到自己糟糕的旧代码。这是一种谦卑的经历，也是学习过程的一部分。我渴望了解一切的时间。

我认为Fosco非常有能力将其置于潜在的时间和功能限制的背景下。有时，您不得不工作。

最后，要了解这就是为什么找到工作的原因。

嘲笑它，尽力不要对它判断太多，而要通过它。成为一个真正的纳粹分子并不好……肯定有“足够好”甚至“当时足够好”这样的东西。在很多情况下，为了解决危机而开发或包扎了某些东西，然后再也没有重新讨论过。

如果确实很糟糕，请查看是否可以重新编写它。如果不重要，请进出。

选择你的战斗。知道“我不会这样写”和“这会带来严重的维护或支持挑战”之间的区别

通常，我觉得了解原始开发人员认为不错的东西很有用。

寻找模式和主题以适应他们所做的事情，很多时候您会发现首先有一些奇怪决定的原因。

有时您会发现原始开发人员实际上是坏人，但是您对他们当时卖出的坏人有一个想法。

无论哪种方式，执行完此操作后，您都应该更好地了解可以在哪里开始重写，或者无需进行任何重构即可快速修复的情况。

最重要的是，不要马上就因为丑陋而认为不好。没有什么让您看起来更愚蠢了，花时间对某些东西进行现代化只是发现它的功能不及原始功能。

如果有时间，我会攻击它并杀死编写不好的代码。

这是战争。

我总是认为丑陋的代码是经过多次调试的代码，并且有许多细微之处在粗略的检查中并不明显。如果要替换它，或者进行深刻的重新设计，则需要确保我完全理解代码的各个方面。如果我没有时间进行深入了解，则必须采取最小风险的方法，并进行最小的更改以实现目标。

通常，我会做一个小小的修正/更改，并为以后的开发提出一个功能，该功能可借以深入了解事物并重构整个事物。然后，我会尽力忽略代码，直到该功能最终出现在路线图上为止。

当遗留代码使用了两年以上时，由于编写代码时所存在的语言或操作系统等方面的限制，可能已采用这种方式编写了代码。嘿，现在看起来很糟糕，但是当时很糟糕吗？我试图假设开发人员有理由做他或她。该原因可能不再适用，但是假设存在的原因不只是普遍的不胜任（年轻的程序员会在5年内对您的代码考虑相同的事情，甚至更少的时间）会使您对此感到不满。如果它可以正常工作，并且没有任何问题，那么不管它多么难看，请珍惜该遗留代码，因为它将使您继续解决更令人兴奋的问题。

过去，当我没有时间生气别人的代码并将其打造成“我的”风格时，我不得不诉诸于任务驱动型：

我要在此代码/修复程序/工作中添加什么？

我正在为此目标而努力吗？如果没有，请停止这样做，并恢复到我上次进行面向任务的更改时。

我完成了这项任务吗？如果是这样，即使看起来好像是由无知的火星模具编写的，也请停止修改代码。

除非您准备将来拥有代码和任何必要的修复程序，否则请不要触摸它。当您破坏没有写的东西时，您会克服想要修复某些东西的趋势，因为您在学习之前没有对它进行足够的研究，这需要您花费2天的时间并进行一次防火练习才能使其重新工作。

别误会我...重构代码是有正当理由的，但是如果企业要求代码能够正常工作，而您在不了解后果的情况下“修复”了代码，那么您将遭受重创。

一次稍微重构可能会很有用，但是要特别注意更改代码实际行为的任何细微方面，除非您了解为什么会有这种行为以及它会产生什么影响。不幸的是，最糟糕的代码有时很难在不触及该行为的情况下进行更改，尽管您通常可以整理一部分代码，或者至少对其进行注释。

如今，我几乎只在处理遗留代码，而我一直认为“哦，他们在想什么？” 。然后，我开始为代码编写单元测试，这就是我真正必须分析控制流和依赖关系的地方。

有时不可能轻松编写单元测试。但是当我尝试时，我会获得有关代码的信息，并且会理解为什么按原样编写。有时那会证明代码确实是一团糟，有时我会了解原始开发人员的思维过程，并且当我想添加新功能时可以添加有用的文档或重写一段代码。

对我来说，当我在12个月内重新使用它时，可以认为我的代码对我自己来说是相同的。

有了经验，就可以判断什么时候代码真的很糟糕，什么时候才以不同的风格编写代码。如果它功能完善且可维护，并且具有良好的自动化测试覆盖率，那么它还不错，您只需要敞开心mind。您可能会学到一些东西。错误的代码不起作用且不可维护。

这是一些真正错误代码的标记：

• 大的逻辑块已被复制而不是重构。
• 类或包之间的循环依赖
• 高耦合；内聚力低
• 未使用的变量，写入永不读取的变量，无法访问的代码。
• 重新实现标准库功能，例如日期格式。
• 不必要的复杂逻辑；即50行代码，其中10行会很好。
• 没有注释描述类或方法的目的。
• 误导性评论。

缺乏自动化测试并不意味着代码不好，但这意味着项目很糟糕。

这些都不是滋味。这些做法使程序维护更加昂贵。

您如何做好准备？

接受这样的事实，即在新代码库上成功工作需要花费一些时间。如果它是“完全可维护的”并且测试覆盖率很高，则花费的时间更少，但仍然不会立即发生。如果代码不好，那么我要做的第一件事就是警告利益相关者，它的状态不好，并且初始进度会很慢。如果他们对此表示怀疑，那么我将通过向他们展示实际代码中的问题样本并解释其与行业最佳实践的差异来支持我的主张。