在可能的日常工作中，我遇到了这个困境：
“稳定的系统与更好的设计”
在日常工作中，当我修复一些模块时，当我看到糟糕的设计时
-> 写得不好的代码
-> 写得不好的算法
-> 优化可能
我更愿意修复这些以及我正在修复的问题
但是很多人反对我的改变一些支持，反对的人会说
“如果系统稳定就应该以业务为导向，如果您更改某些内容可能会导致回归，因此不要偏向业务”
一段时间：
6 个月后你会看到自己编写的代码，你总是会看到一些改进的机会
虽然支持者会说：
这是持续改进，系统将更加稳定
所以我想知道你们的想法
如果适用，编写一个单元测试（或几个，以涵盖边缘情况）。这让你有信心重构并知道你没有破坏任何东西。
当然，如果代码是紧密耦合的（或意大利面条！），那将是一个问题。
如果它没有损坏，请不要修复它 - 将其包裹起来。在不改变其实现的情况下尽可能多地隔离模块；当/如果真正需要时，它们应该被触及（修复，改进）。
如果旧代码看起来不完美，我的意见是不要修复它，除非它的编写方式会干扰您当前的任务。
大部分代码写得很糟糕。这是事实。如果您不是一个完美的团队，对质量价值有完美的理解，并且对实现和保持此质量水平的方法达成一致，那么您的优化不会改变大局。你现在可以修复一些东西，但下一个人会再次把事情弄得一团糟。
我得出的结论是，在这个行业中，如果它没有损坏，除非有充分的理由，否则不要修复它。
如果您对应用程序了如指掌，或者有全面的单元测试和时间在非生产环境中测试应用程序，那就去做吧。否则，仅在必要时进行。
两者都是正确的，没有简单的出路。
如果您在遇到问题时不解决问题，则并非所有问题都会得到解决。
如果您使用与您当前正在处理的问题不是 100% 相关的修复来破坏某些东西，那么人们会讨厌您。
另一方面，如果你修复了一些无辜的代码（或者更确切地说是看起来很无辜的代码）并且它以意想不到的方式中断，你就会发现一些有价值的东西：脆弱的代码。脆弱的代码通常是没人敢碰的。但是为了让你的产品更稳定，你必须摆脱这样的代码。这条路上的第一步就是找到它。
我不得不承认，这样的修复会在团队中造成很多“不必要的”摩擦。当你接触脆弱的代码时，人们会冲你大喊大叫，因为他们害怕。通常，这段代码会吹到你的客户面前，所以你会从各个方向得到热量。
所以这真的取决于你想要造成多少痛苦以及你愿意忍受什么。如果你在遇到它时修复所有东西，那么到年底代码会更好。但到了一天结束时，情况往往会更糟。
我想支持所有“如果它没有坏，就不要修复它”的答案，但是有一个相关的链接......
你不应该做的事情，第 1 部分 - Joel Spolsky
本质上——有时那些难以理解的代码实际上是一个你没有机会理解的必要的错误修复。
一方面，更改已经或多或少工作的代码可能会冒破坏事物的风险，并且很容易成为一项耗费精力的任务。
另一方面，由于维护坏代码的负担，担心破坏事情而单独留下坏代码可能会扼杀新的开发。
有时代码看起来很糟糕，因为它必须处理复杂的极端情况，正如Joel Spolsky 指出的那样，重写它会因为未能覆盖这些极端情况而产生错误。有时代码看起来很糟糕，因为它确实很糟糕，重写它可以修复你甚至不知道的错误。使用代码库的经验应该可以帮助您确定哪个代码是哪个。
在Boy Scout Check-Ins中，Jeff Moser 讨论了“总是让露营地比你发现它更干净”的想法。即使您无法解决所有问题，也要始终让代码库比您找到的更干净；这些小改进会随着时间的推移而增加。
正如在这个答案中所说，单元测试是一件好事。 Michael Feathers 的《有效地使用遗留代码》是关于这个主题的一个很好的资源。
我个人倾向于花时间修复东西，而不是继续完成所需的任务。不幸的是，开始解决看起来很简单的问题并解开你希望没有的巨大混乱太容易了。
我也曾与相反的人一起工作，只要能完成工作，他们就能忍受坏处。
通常情况下，您可以花费数年时间“做正确的事情”，以便将来更容易使用，您会发现代码在未来永远不会被重用。
我认为最重要的是要平衡对团队的看法，定期与他人讨论问题，并最终满足您的项目要求，因为支付账单的是客户。
对您发现的任何问题保持建设性 - 不要只是为了它而挖洞！随着时间的推移，团队代码审查有助于改进糟糕的代码，因为糟糕的编码人员将开始了解如何编写好的代码。
我建议用“TODO”注释标记错误代码，然后在以后/预算允许的情况下回来修复它。至少你有一个潜在问题区域的标志，而不必（可能）浪费时间在当时不需要的修复上。