脉脉上看到有人吐槽公司项目代码跟一坨SHI似的。说实话，以前的我，也会有这种想法。
我一开始接触现公司的一个老项目时，也是各种吐槽，一个方法三千多行，那时候我并不是很理解，为什么会写出这样的代码。
现在，根据我的经验，我猜测项目长残主要是以下几种原因。
1.需求多，没时间
我全程参与了一个新项目的开发，从项目的一开始设计、项目架构的搭建就开始参与其中，到现在，已经有半年时间，已经不再是当初设计的那个样子，加了数不清的需求，某些功能改了数不清的次数，连整体的架构都被我改了好几次。
新的需求总是很紧急，每个bug都是很紧急，所以根本没有太多时间让我去好好想如何设计，往往有bug就先解决bug，有需求就赶需求，事情多得需要给它们贴标签排优先级，基本每周一的事情都能安排满这周与下周的时间。
所以说，代码写得烂的原因之一就是需求多且时间紧。
2.需求频繁变动
我记得年后上班的第一个月，是我今年最累的一个月，老项目一堆问题，也一堆需求，各个都标着紧急的标签，同时，那时候又是新项目赶进度上线。
新项目赶进度，但是协议没定好，这个很好理解，一个新的产品存在的变数很大，前期需求盲摸索找准方法。前后端也需要时间磨合，只有踩在一个点上，才能稳定下来。一时间，功能一直在变，一直在变，连数据库表的结构设计都调整好几次，那时候每天都要修改sql，昨天写的代码，今天就得删了重写，天天开会讨论，客户端与后台的接口协议天天变。
所以，这第二种原因，就是需求频繁变动。一开始可能是想做个饼，但是做着做着，觉得饼不好吃，又改成了做包子。
3.无法预测的需求迭代
我之前重构的一个模块，就是一个实现广告单数据过滤的业务逻辑，一个方法写了三千多行代码。
我猜测它的发展历史是这样的：
- 一开始可能只是根据广告单的黑白名单做过滤；
- 后来添加了标签白名单进来；
- 再后来添加了每日收益达到多少就不下发的需求；
- 再后来又需要将黑白名单设置同步给渠道的需求；
- 再后来又添加了对广告进行分类，如果是应用app推广广告，还需要按包名分组的需求；
- 再后来又要能针对应用包名设置黑名单的需求。
我记得后面一个是我加的，所以一个方法三千多行，就是这么来的。
所以，第三种原因就是，无法预测的需求迭代。一开始逻辑很简单，但慢慢的加了很多新的逻辑，所以本来一个方法只有几十行代码的，最终写到了一千多行。
4.以后再优化
很多人都有一种心理，就是先实现，以后有时间再优化。
接到一个需求，一开始都是先实现功能，怎么简单怎么来。例如，原本一开始可以用算法优化的一个排序功能，结果为了快速上线，就写了个简单的for循环。
这不就是埋下了一颗定时炸弹吗？如果忘记去优化，不知道哪天就会爆炸。
5.技术更新太快
我跟同事讨论过，项目中的某某功能为何不用消息中间件，同事的回答真是打脸：16年的时候我都不知道消息中间件。
所以说，就算那时候听说过，但是项目在初建期，时间就是金钱，越早上线越好，没有时间等你们程序员回去学习消息中间件再开发。
至于后面为什么没改，你想啊，可能那位哥辞职了，或者没时间，或者他不学习新技术，还是吃老本。
SO
不要再抱怨你们公司项目的代码写得多烂，因为你不了解它的历史，你没有参与它的成长，你根本就不懂它是怎么长残的。
如何避免代码变成一坨SHI
如果你不想你写的代码也被后来者吐槽，那就从现在开始，写好你的代码，发现或者预测到有烂代码出现时，应及时调整或者重构。
对于第2、3种原因，需要我们主动的去对项目进行优化。看到一个方法写到一千多行，那你就需要主动去进行拆分，可以使用设计模式就改用设计模式，不行就按照功能拆分成多个方法。
当你发现这块功能的代码逻辑太乱，或者想加一个新的逻辑进去很难的时候，说明这个功能模块需要进行重构了。对于这种，越早重构越好，否则越往后拖，别说加入新的需求，就算让你改动某个逻辑都很难，不知道你是否有体会过。
我跟同事就遇到过几个老项目中的不解之谜，其实没有什么不解之谜，只是涉及的东西太多，逻辑太复杂，连调试代码都找不出问题。如果不尽早重构，总是将就着能用就用的态度，吃苦的可能不是你，因为你可以辞职，只是痛苦的往往是后来者，也有很多后来者忍受不了辞职的，可以说，把后继人坑惨了。
我们预知不了，随着业务的发展，会给项目带来哪些巨大的变动，但我们可以预测会有哪些需求，从而在对某个业务模块、某个功能的设计时，尽量满足预测未来可能要实现的，这就是扩展性。所以我们也需要对业务很了解，还是那句话，一味的追求技术是不够的。