在五月的日常工作中，我遇到了这个困境:
“稳定系统与更好的设计”
在日常工作中，当我修复某个模块时，当我看到糟糕的设计时
-> 代码写得不好
->写得不好的算法
-> 优化可能
我更愿意修复这些以及我正在修复的问题
但是很多人反对我的改变一些支持，反对的人会说
"如果系统稳定，你应该以业务为导向，如果你改变一些东西可能会导致回归，因此不利于业务"
一段时间:
你会在 6 个月后看到你自己编写的代码，你总是会在这个 中看到一些改进的机会
支持的人会说:
这是持续改进，系统会更稳定
所以我想知道你们是怎么想的
最佳答案
如果适用，编写一个单元测试(或多个，以涵盖边缘情况)。这让您有信心重构并知道您没有破坏任何东西。
当然，如果代码是紧耦合的(或意大利面条!)，那将是一个问题。
关于optimization - 稳定的系统与更好的设计，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1486556/