不引入足够的额外能量，熵增是必然的。 不花很多力气去额外维护代码，腐败就是必然的

本来有些地方是可以重构的，但是重构没有收益，还要承担发版的风险，所以最后就变成了，能跑就行

代码的优雅和 用户的需求是天生矛盾的 特别是业务端的, 100% n 年后就要重写 当然有人说 sap 这样的活了多少年, 其实你们没看到 isv 写了多少代码, 然后被废弃的

我：好产品是需要打磨的 领导：不是时间短就做不出好产品 🥲

熵增定律，无处不在。

如果一个服务一直是一个人做那估计不会变 shit 山

只要在一个模块上面开发的能力不同就会腐烂，这个能力主要受两个方面影响 开发人的技术 和 时间。 这两个很明显基本不可能具有同等效能

根据需求变化，重构是一个相对来说，可以延缓代码持续时间的，可行性最高的方法，但是，屎山依旧是一定的；

我以前以为是技术不强导致的，现在看来是人性+制度+环境所造成的不可避免的必然结果

“既然需求肯定会变，那么找到一种能适配需求多变，并且不会破坏已有代码的方法就好了，一种始终具有稳定性的方法。”这样可能就导致过度设计了。