还有 3 个链接，也是我平时的一些想法： https://www.zhihu.com/question/306481351/answer/562237980 https://www.zhihu.com/pin/1334919811172556800 https://www.zhihu.com/question/23757906/answer/605843681

有啊，从老板的角度看的话，每次变更都不计一切代价的让团队重构项目，雇一个团队干这事，也是一种解决方法 但作为维护系统的人，no silver bullet

就是需求变更 一个项目其中一部分代码全程是我自己实现的，持续多年后一样一塌糊涂。 原因就是需求变更。 每次增加新需求都要修改代码，然后老功能还不进行移除，有时候一个逻辑根据多个配置能走多个互相交错的代码路径。 我这还算好，时间足够会同步实现测试。但是后期时间紧张时测试就开始跟不上了。 有的项目乱倒一定程度后，我强硬进行重构，把功能改成插件式的就好多了。 但是一些项目并没有那么好做，特别是为了性能不能封装，或者即时封装也要向上层暴露一定细节就很烦了。

什么，代码被需求渗透了，屎山革命，和平重构了

没有银弹，堆人月就好

优秀的程序员，就算憋不住没厕所要拉屎(需求急)，也会挖个坑(单独一块区域)，拉了坨也会稍微盖一下(尽量做隔离)，再立一块牌子(写重要注释)，免得别人或者自己掉屎坑里。 而有些程序员，每天上班下班不论在哪(管他什么需求)，随地大小便(只管自己方便)，马桶里马桶外地上墙上天花板所到之处都能拉(需求做到哪里垃圾代码写到哪里)，别人问起来就是不关我事(模块不是我负责)、我没有拉(我只是该一点点不算动到)、别人也这样拉的(别说我垃圾代码内谁你怎么不说他)。 peace ～

需求变更来自于世界在变，发布的东西越多就会发现越多对这个世界错误的假设。代码的腐败是熵增的过程，软件系统也需要一直进化，尽量和这个组织对世界（主要是对付费用户）的了解才能保持速度

写代码的人本意是好的，是代码执行时出了差错🌚

熵增是不可逆的，所以定期重构是必须的，降低复杂度。

任何项目，只能想办法减缓变成屎山的速度，并不能杜绝他成为屎山。而且重构这个事情，对中上层，特别是整个公司不是由技术人说话的时候，是毫无意义的。