今天逛v站有人在提问 公司的项目代码太恶心了怎么办？ 这的确是一个 老生常谈的问题
刚好今天上午也有同事在抱怨和吐槽历史的代码各种不合理，维护起来极其的恶心。
论坛里有人提出了 “你不能用现在的标准去衡量以前的产出”的观点，我很认同，互联网公司的团队人员极其的不稳定，业务也是瞬息万变，屎山是无法避免的，作为组里地位最低的打工人，凭借自己的力量去改变这种现状，是不太现实的，重构历史的代码不仅会心力交瘁，而且因为重构引入的任何bug都不能撇清自己的关系。只有技术leader的角色高度才适合去推动重构的改造。
然而，站在打工人的角度，写代码既要考虑产品有限的排期里程碑，又要考虑业务上的各种迭代和变更，如果还要再考虑代码的规范不要写出屎山，在有限的时间有限的精力和几乎为0的容错性下，做到既要又要还要的事情，可以说是对于打工人极大的考验。
在屎山正常运行的情况下，领导怎么能投入人力去做改造的事情，从人性角度去理解，只有造成了实际的重大经济损失，才会意识到重构的重要性，才会有足够的资源投入去做这件事情。
另一个观点 对我也很有启发，别人的代码写的太优秀，反而会对自己有心理负担，怕自己写烂了污染了优秀的项目，而维护屎山，遇到问题解决问题，工作便很容易进行也可以量化。不会既要、又要、还要。
时间紧任务重责任大，新人面对屎山大吃一斤，老人会驾轻就熟，不动最臭的屎，在保证正常运行的情况下再糊上一层新的屎。
最终代码和人有一个跑得快就行。
总结
把价值观拉回来，对自己严格要求不要写屎山，然后自己想办法抽时间重构，出了问题自己担责，对就这样。
