稳定的系统与更好的设计

Sat*_*bir 4 optimization stability

在每日工作中,我遇到了这种困境:

"稳定的系统与更好的设计"

在我正在修理一些模块的日常工作中,当我看到糟糕的设计时

- >编写错误的代码

- >写得不好的算法

- >优化可能

我更愿意修复这些以及我正在解决的问题

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

"如果系统稳定,你应该以业务为导向,如果你改变某些东西可能会导致回归,因此不喜欢业务"

一段时间:

6个月后你会看到你自己的书面代码,总是你会看到一些改进的机会

虽然谁支持会说:

这是持续改进,系统将更加稳定

所以我想知道你们的想法

Mit*_*eat 7

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

当然,如果代码紧密耦合(或意大利面条!),那将是一个问题.


Otá*_*cio 5

如果没有损坏,请不要修理它 - 包装它.尽可能多地隔离模块而不改变其实现; 当真正需要出现时,应该触及(固定,改进)它们.