我之前待过一个非常糟糕的团队，糟糕到什么程度呢，代码不要提什么设计，注释了，全靠猜，打开一个文件都是几千行打底的，由于团队没有做文档积累，基本上需求都是靠口口相传的，印象中接了一个需求，结果这个需求牵连到之前的一个需求，需求评审的时候产品不清楚之前的需求，只有测试团队的某个人才清楚，但是这个测试又不在需求评审中，导致了提测后测出了很多跟之前需求相关的问题，开发想推进需求，只能修，于是无限delay。
PM也是非常难沟通，一个可能只有几百人使用的功能，PM只想要完全按照设计稿去实现，设计稿的实现步骤非常复杂，跟PM沟通用简单方法去实现也是不行，PM的PRD设计有缺陷，开发提出来，但是PM是不负责的+只想甩锅，因为项目是靠开发去推进的。
这时候怎么办呢？基本上无解。需求需要推进，重构又不清楚之前的产品逻辑，很多产品逻辑是需要开发从代码去看才能知晓的。
不得不说这样的团队真是能"锻炼"人，不仅要脑袋灵光，避免背锅，而且要时时注意屎山代码的代码陷阱。
当时的leader也是空降的，他尝试开发了一套系统去梳理了发布的逻辑，但是这套系统的开发时间太长了，没有拿到很好成效的情况下，他也很快被干掉了。
后面又换了新leader，但是我这时已经离开了这个团队，后面怎么发展就不清楚了。
其实很多人都会遇到这个问题，进入新团队，屎山代码，怎么办？
最好的方法，就是开启一个新项目重写代码，跟leader争取资源后去推进，整理相关代码需求的功能，但是万一在重构的过程中有一些点没考虑，项目上线客户反馈就得背锅。这也是为什么很多人说不要动屎山代码的原因。
这时候leader的作用就体现出现了，让小的们大胆去干。
工程化这个事情还是很重要的，好的架构，好的设计，好的代码规范，一步步遵循下去，随着业务量的增长，代码才能更好的维护，或者说能比不遵循工程化的项目所耗费的心力更少。
当然了，也有一种情况，明明这个代码架构是为A功能设计的，但是产品在需求的堆叠过程中，提出了B设想，导致了代码违背了本来的设计，就像嫁接植物一样，能用，但是很奇怪。 长此以往，屎山代码就形成了。
这时候，要不就跟PM沟通，尝试顺着A模块去继续设计，如果PM不同意并且要赶工期的话，可能会写一些临时代码。 这时候可以记个TODO，等以后有时间的时候，把这块好好重构一下。
我刚毕业的时候，时时被当时的导师纠正工程化的问题，回过神来，发现确实重要呀。