在五月的日常工作中，我遇到了这个困境：
“稳定的系统与更好的设计”
在日常工作中，当我修复某些模块时，当我看到糟糕的设计时
->代码写得不好
->算法写得不好
->可能的优化
我更愿意修复这些以及我正在修复的问题
但是很多人反对我的更改，少数人支持，反对的人会说
“你应该以业务为导向如果系统稳定，如果你改变一些东西可能会导致回归，因此不利于业务”
有时：
你会在6个月后看到你自己编写的代码，你总是会在这方面看到一些改进的机会
而支持者会说：
这是持续改进，系统会更加稳定
所以我想知道你们的想法
In may Daily Job i come across this Dilemma :
"Stable System Vs Better Design"
In routine job when i am fixing some module, When i see bad design
-> Badly written code
-> Badly Written Algorithm
-> Optimization possible
I would prefer to fix these also along with issue i am fixing
But many people opposes my changes a few supports, People who opposes will say
"You should be business oriented if system is stable, If you change some thing may cause regression, Hence do not favor business"
some time :
you will see your own written code after 6 months, Always you will see some improvment opportunity in this
While who support will say:
This is continual improvement and system will be more stable
So i would like to know what you people think
发布评论
评论（9）
如果适用，请编写一个单元测试（或多个单元测试，以覆盖边缘情况）。这让您有信心进行重构，并知道您没有破坏任何东西。
当然，如果代码是紧密耦合的（或意大利面条式的！），那就会是一个问题。
If applicable, write a unit test (or several, to cover edge cases). This gives you the confidence to refactor and know that you haven't broken anything.
Of course, if the code is tightly coupled (or spaghetti!), that's going to be a problem.
如果它没有损坏，请不要修复它 - 将其包裹起来。在不改变其实现的情况下尽可能地隔离模块；当/如果确实需要出现时，应该触及（修复、改进）它们。
If it ain't broken don't fix it - wrap it. Isolate the modules as much as you can without changing its implementation; they should be touched (fixed, improved) when / if a real need arises.
我的意见是，如果旧代码看起来不完美，则不要修复它，除非它的编写方式干扰了您当前手头的任务。
大部分代码写得很糟糕。这是事实。如果您所在的团队不是一个完美的团队，对质量价值没有完美的理解，也没有就实现和保持此质量水平的方法达成一致，那么您的优化将不会改变大局。你现在可能会修复一些东西，但下一个人又会把事情搞得一团糟。
My opinion would be not to fix the old code if it looks not perfect unless the way it is written is interfering with your current task at hand.
Most of the code is written badly. It is a matter of fact. If you're not in a perfect team with the perfect understanding of quality value and the agreement on the approach to achieve and keep this quality level, your optimizations will not change the big picture. You may fix something now but the next guy will make the mess of the things again.
我得出的结论是，在这个行业中，如果它没有损坏，就不要修复它，除非有充分的理由。
I have came to the conclusion that in this industry if its not broken, don't fix it unless there is a damn good reason to.
如果您对应用程序了如指掌，或者有全面的单元测试并且有时间在非生产环境中测试应用程序，那就去做吧。否则，只在必要时才进行。
If you know the application inside out, or have comprehensive unit tests and time to test the application in a non-productive environment, go for it. Otherwise, do it just when it's necessary.
两者都是正确的，并且没有简单的出路。
如果你在遇到问题时不解决问题，那么并非所有问题都会得到解决。
如果你用与你当前正在解决的问题不 100% 相关的修复来破坏某些东西，那么人们会讨厌你。
另一方面，如果您修复了一些无辜的代码（或者更确切地说，看起来无辜的代码）并且它以意想不到的方式损坏，那么您就发现了一些有价值的东西：脆弱的代码。脆弱的代码通常是没人敢碰的东西。但为了让你的产品更加稳定，你必须摆脱这样的代码。这条路的第一步就是找到它。
我不得不承认，这样的修复会给团队带来很多“不必要的”摩擦。当你接触脆弱的代码时，人们会因为害怕而对你大喊大叫。通常，这些代码会当面吹向你的客户，因此你会受到来自各个方向的热量。
所以这实际上取决于你想要造成多少痛苦以及你愿意忍受什么。如果你在遇到问题时修复所有问题，那么到年底代码将会变得更好。但到了一天结束时，情况往往会变得更糟。
Both are correct and there is no easy way out.
If you don't fix problems as you encounter them, not all problems will be fixed.
If you break something with a fix that is not 100% related to the issue you're currently working on, then people will hate you.
On the other hand, if you fix some innocent code (or rather code that looks innocent) and it breaks in unexpected ways, you've found something valuable: Brittle code. Brittle code is usually something that no one dares to touch. But to make your product more stable, you must get rid of such code. The first step on this road is to find it.
I have to admit that such fixes cause a lot of "unnecessary" friction in the team. People will yell at you when you touch brittle code because they are afraid. Often, this code will blow into the face of your customers, so you will get heat from all kinds of directions.
So it really depends on how much pain you want to cause and what you're willing to endure. If you fix everything as you encounter it, the code will be better by the end of the year. But it often is worse by the end of the day.
我想支持所有“如果它没有坏，就不要修复它”的答案，但有一个相关的链接...
你永远不应该做的事情，第 1 部分 - Joel Spolsky
本质上 - 有时那些难以理解的代码实际上是一个你没有机会理解的必要错误修复。
I want to second all the "if it ain't broke, don't fix it" answers, but with a relevant link...
Things You Should Never Do, Part 1 - Joel Spolsky
In essence - sometimes that incomprehensible code is actually a necessary bugfix that you have no chance to understand.
一方面，更改已经或多或少可以工作的代码可能会面临破坏事物的风险，并且很容易成为一项耗时耗力的任务。
另一方面，由于担心破坏代码而留下不良代码可能会由于维护不良代码的负担而扼杀新的开发。
有时代码看起来很糟糕，因为它必须处理复杂的极端情况，正如 Joel Spolsky 指出的，重写它会因为无法覆盖这些极端情况而产生错误。有时代码看起来很糟糕，因为它确实很糟糕，重写它可以修复您甚至不知道存在的错误。代码库的经验应该可以帮助您确定哪个代码是哪个。
在童子军签到中，Jeff Moser 讨论了“让露营地永远比你发现时更干净”的想法。始终保持代码库比您发现时更干净，即使您无法修复所有问题；这些微小的改进随着时间的推移而累积起来。
正如这个答案中所说，单元测试是一件好事。 有效处理旧代码，作者：Michael Feathers ，是关于这个主题的一个很好的资源。
On the one hand, changing code that's already more-or-less working can run the risk of breaking things, and it can easily become an all-consuming task.
On the other hand, leaving bad code alone for fear of breaking things can stifle new development, due to the burden of maintaining bad code.
Sometimes code looks bad because it has to deal with complicated corner cases, as Joel Spolsky points out, and rewriting it will create bugs by failing to cover those corner cases. Sometimes code looks bad because it really is bad, and rewriting it can fix bugs that you didn't even know were there. Experience with your code base should help you determine which code is which.
In Boy Scout Check-Ins, Jeff Moser discusses the idea of "always leaving the campground cleaner than you found it." Always leave the codebase cleaner than you found it, even if you can't fix everything; those little improvements add up over time.
As was said in this answer, unit tests are a good thing. Working Effectively with Legacy Code, by Michael Feathers, is a great resource on this topic.
我个人倾向于花时间修复问题而不是继续完成所需的任务。不幸的是，开始解决看似简单的问题并解决你随后希望没有解决的巨大混乱实在是太容易了。
我也曾与一些相反的人一起工作过，只要能完成工作，他们就能忍受不好的地方。
通常，您可能会花费很长时间“把事情做好”，以便将来更容易使用，并且您会发现代码将来永远不会被重用。
我认为最重要的是在你的团队中保持观点平衡，定期与其他人讨论事情，并最终满足你的项目的要求，因为是客户买单。
对你发现的任何问题都保持建设性的态度——不要只是为了解决问题而挖洞！随着时间的推移，团队代码审查有助于改进糟糕的代码，因为糟糕的程序员将开始了解如何编写好的代码。
我建议用“TODO”注释标记错误代码，然后在时间/预算允许的情况下回来修复它。至少您已经对潜在问题区域进行了标记，而不必（可能）浪费时间在不需要的修复上。
I personally have a tendency to spend time fixing stuff rather than getting on with the required task. Unfortunately it is all too easy to start fixing what looks like an easy problem and unravelling a huge mess that you then wish you hadn't.
I have also worked with people who are the other way round, and can live with the bad bits as long as it gets the job done.
More often than not, you can spend ages 'getting something right' to make it easier to work with in the future and you'll find that code is never reused in the future.
I think the main thing is to have a balance of views on your team, discuss things regularly with others and ultimately, meet the requirements for your project, since it's the customer paying the bills.
Be constructive about any problems you find - don't just pick holes for the sake of it! Team code reviews help improve bad code over time as poor coders will start to understand how to make good code.
I would advise marking bad code with 'TODO' comments and then coming back to fix it later time/budget allows. At least you've got a flag for potential problem areas then, without having to (possibly) waste time on a fix that's not required there and then.