稳定系统与更好的设计

Question

在“五月日报”中，我遇到了这样的困境：

“稳定系统与更好的设计”

在日常工作中，当我在修复某些模块时，当我看到糟糕的设计时

->编写不好的代码

->写得不好的算法

->优化可能的

--我更愿意解决这些问题，同时解决我正在修复的问题

但是很多人反对我的改变一些支持，反对的人会说

“如果系统稳定，您应该面向业务，如果您更改了某些东西可能会导致倒退，因此不支持业务”。

一段时间：

您将在6个月后看到您自己编写的代码，在这个中您总是会看到一些改进的机会。

而世卫组织的支持者则会说：

这是一个不断改进和系统将更加稳定的

所以我想知道你们怎么想

Answer 1

如果适用，编写一个单元测试(或几个，以覆盖边缘情况)。这给了你重构的信心，并知道你没有破坏任何东西。

当然，如果代码是紧密耦合的(或者意大利面！)，这将是一个问题。

Answer 2

如果没有坏，就别修理-包起来。尽可能多地隔离模块，而不更改其实现；当/如果出现实际需要时，应该对它们进行修改(修复，改进)。

Answer 3

我的观点是，如果旧代码看起来不完美，就不会修复它，除非它的编写方式干扰了当前的任务。

大部分代码写得很糟糕。这是事实。如果您不是一个完美的团队，对质量价值有着完美的理解，并且对实现和保持这一质量水平的方法达成一致，那么您的优化将不会改变大局。你现在可以修理一些东西，但下一个人会把事情弄得一团糟。