很多开发朋友接手一个拥有一点历史“沉淀”的项目时可能都有一个共同的想法：我想重构它 -- 我要重构它。
在我刚刚开始工作的时候我就想着在我手中的项目一定不会成为屎山代码，那时候的我觉得写出屎山是对技术，对我这么多年来学习知识的侮辱！那时候的我还是一个新人，接手的项目基本上是一些小模块，或者是一个逻辑非常简单的小项目，比如一些投票系统啊，答题系统啊还有一些基本的后台......这些基本上都是我从0开始搭建所以我写起来很得心应手，感觉不到丝毫难度。那会儿的我一味的追求代码的整洁，简单，易懂可扩展，觉得人怎么可能写出屎山代码呢？！直到后面越来越深入的加入到项目中我才慢慢理解何为屎山，并且深刻知道了屎山的产生过程。
什么时候会遇到屎山呢？在我的经历中无疑是下面这几种情况：
维护老旧项目、升级旧项目。
我第一次接手公司的一个老项目的时候我看到代码的表情几乎是这样的：
祖传代码名不虚传，这个项目不知道以及经过了几个开发小组的手也不知道迭代了几次。因为要添加新功能所以关于那部分业务我得先读一读他们之前写的代码，好家伙一个函数整了六百多行，而且全程都是上帝的秘密--不写注释！直接给我整懵逼了。最可怕的是后面我看懂之后我也不敢去碰它（我内心是非常想重构的）！但是凭着"能跑的代码就千万别去碰"的原则我只能小心翼翼的把我的逻辑写在上面~~没错这就是在屎山上又盖上了一层屎......
需求初步确认的情况下开发到一半突然要转换需求
不知道大家有没有遇到过，在一个新项目需求基本确定的时候，大家高高兴兴地开发突然来了一个跟这个项目的业务逻辑感觉毫无关联但是又有这千丝万缕的联系的需求。这种需求呢对于一开始的业务感觉像是强加上去的一般，其实也可以实现需求--但是一般往往要加新的数据库字段，而且还不只一个。对于开发到一半加数据库字段是我一直比较反感的，因为已经设计好的东西重新加很多字段很不优雅而且造成了比较严重的冗余~嗯对就是这样，还导致很多的代码要去改。这就在无形中加大了屎山出现的概率。
时间紧急，需要快速上线以及出问题后的紧急修改
我入职以来时间要求最紧的项目就是两周，没错从啥都没有到开发测试上线只有两周的时间，一个项目两个人。因为时间紧张所以避免不了加班，但是这样还是依然紧张的，只能怎么快怎么来，在写代码的过程中想到啥，只要能合理就直接写只为了项目赶紧写完上线。但是这么做的后果就是代码有很多地方不怎么规范，虽然达不到屎山的程度但是也比较混乱了。在测试的时候有些地方出错了直接就用粗糙的if else直接改了甚至提交到代码仓库提交的信息只有一个简简单单的1。虽然那时候都想着这些等后面再优化吧但是实际上就是后面就忘记了，因为已经上线就懒得改了。
如何避免屎山的出现
1. 时刻遵守代码开发规范
虽然开发过程中有许多不可抗力的原因但是尽量去遵守代码开发规范，这能很大程度上让代码变得美观、让人容易接受。遵守代码规范在一定程度上大大减少了BUG的出现。如果出现了BUG也能很快的定位修改。
2. 要敢于及时重构代码
早发现早修改，不要遗留，否则积少成多，积重难返。我在上面也讲到了有时候时间紧任务重的情况代码写的可能比较一言难尽，虽然代码上线了但是后续有时间还是要对写的不好、不规范、甚至混乱不堪的代码进行重构的，屎山屎山毕竟是山不是一日形成的所以尽可能的将代码改得规范，至少写的能让人看懂。
如何看待屎山代码
不要抱怨不要排斥：作为一个开发看屎山是很难避免的。所以不要太过于排斥屎山代码，我始终坚信没有哪个项目一开始就是屎山！更不相信一个开发者一开始就写屎山代码。
理解屎山代码出现的原因，多归纳总结，有则改之无则加勉：当我们接手屎山代码的时候我们在理解它的同时也要自己想想为什么会出现这种情况，如果可以还可以去看看提交记录啊什么的，很多时候都是迫不得已。这也是一种吸取前人经验的一种方式。
发现有价值的代码：虽然说是屎山，但是里面可能还有值得学习的地方的，特别是业务流程比较复杂而且项目迭代多个版本的项目，尽量挖掘有价值的代码，把它们变得更好。这将帮助你获得信任并增强你在公司中的价值。
开发路漫漫，诸君共勉之！
