1、要敢于重构代码
在一个开发团队中，很多人即使发现问题，但考虑到这坨屎不是自己亲自拉的，因此放弃了重构的打算；或者担心修改后引入其它问题， 反而会带来更多的风险，尤其是对已经发布的版本（或历史遗留版本）会更加谨慎，万一屎中有雷呢，万一是连环雷呢？炸一脸该怎么收场？ 就算炸不到自己，万一炸到无辜的同事以及花花草草该怎么办？
因此多一事不如少一事，少一事就等于没有事，管他以后谁维护呢！
对于项目负责人来说，要担负的压力更大，在成本、质量、进度三者之间，进度往往是项目负责人的第一选择，也就是要满足起码的交付需求。重构往往要牺牲进度和成本，长期看虽然有利于项目的持续稳定发展，但在短期利益的驱动下，尤其是在老板（或业绩）的压力下，即使项目负责人发现需要重构的地方，也不会贸然重构代码。对于项目负责人来说，能活过今天就很开心。
2、要及时重构代码
早发现早修改，不要遗留，否则积少成多，积重难返。
由于赶工期，很多时候代码写的不是很优雅，数据结构设计的不是很合理，系统架构设计存在瑕疵，接口间的调用会有冗余，如果不断累积就可能导致屎山。
中国软件项目的特点就是时间紧、任务重，需求变化快，甚至很多需求存在于领导的一念之间，也就是存在三种需求，昨天的需求、今天的需求和明天的需求。
在这种大的背景下，即使是自己亲自拉的翔，你也发现了不合理，但由于一直赶进度，从而没有时间进行修改，最后小翔变成了大翔，大翔变成了自由飞翔，管他以后谁维护呢！
当你能严格遵守上述两点时，你就会发现，当你推倒一座屎山后，又会重构出一座更加漂亮的屎山，一山更比一山高。
最后你会明白：只要代码生命周期足够长，呵护它的人足够多，就总是能长成屎山的。
其实避免屎山只有一条捷径：
永远不要碰业务复杂的大项目！
永远不要碰业务复杂的大项目！
永远不要碰业务复杂的大项目！
重要的事说三遍！