最近对代码有一种已经很难改动的困境，看了那么多如何写好代码的文章和书，依然没能避免出现了烂代码。正印证了一句话：听过很多道理，却依然过不好这一生！下面也来分享下，是如何出现烂代码的。
一、代码有点随意了
在自由的环境下，可以发挥出程序员的创造力和有较高的生产效率，在组队前期可以进行快速产出，这是自由的力量。但因为没有统一规则的指导，每个人的风格自然是不一样的；在另一方面，每个程序员的水平也是不一样的，代码也会“参差不齐”；再者，加上自身缺少自律，往往也会出现个人风格的不统一。在这几种情况下，一个项目的整体代码必然会出现“混乱”，往往一小片一小片看是没有太多问题，但是整合在一起的时候，代码自然就烂了。所以在项目推进到一定程度的时候，团队就不得不为自己的“任性”，偿还债务。
二、重复代码
尽管我个人在极力避免出现重复代码，但是在一个项目中包含众多模块，而模块间有相同逻辑，在缺乏统一把控、程序员缺乏全局意识和相互沟通的情况下，重复劳动的情况必然出现，重复代码也应景而生。
三、过多的关注业务应用
作为提供纯数据的接口后端--零件厂家，是必然无法摆脱业务应用（消费市场）的逻辑，尽管业务应用还是有自己的后端--组装工厂，作为最终数据提供者。由于过多关注业务应用逻辑，导致业务应用的后端只是作为单纯的中间“代理商”，而让作为“零件厂家”变成了“组装工厂”。在面对单一应用的时候，当然是没有问题，但是当面临十几个应用的时候，这个“零件厂家”的压力和混乱可想而知，在一个项目中拥有太多不该是自己拥有的代码，负累过重，导致修改困难重重。而当业务应用撤销的时候，“零件厂家”又不知道的情况下，又会造成代码荒废。在项目负累过重和输出不明情况，代码也会随之慢慢变味。
四、突发情况太多，There's always plan B
计划总是用来被打乱的，而B计划往往就成了拯救世界的可行方案。当你在信心满满的准备着完美计划的时候，突发了一个客户的需求，而这个需求可能决定了客户为不为你的产品买单。自然，你会匆匆忙忙的加上一段规则之外的代码，迅速实现了需求。而紧急的需求，往往是不靠谱的，但最大的问题是，这段代码你往往不能删，一方面删除代码的代价太大，因为你不能确定需求是否还存在，另一方面也不值得你花时间去删，那意味着你要花大量时间去重新将一个可能没有价值的事情变得完美。所以这段代码，往往被我们遗留在角落了，慢慢地腐烂。而最可怕的结果是“积劳成疾”！
五、没有出现bug，最好不要改动
当项目进行到一定稳定的情况下，大家会进入一个状态：为了避免出现问题，尽可能的少改动。但是正正因为这种心态导致不断产生新的代码，进而导致代码越来越难理解。这个时候你去动原来的代码，往往会发生一个笑话：修复了1个bug，产生了99个bug。为了避免笑话，你通常不会去动原来的代码，只会不断加入新的代码，恶性循环就是这样来了。那感觉就像你陷入了泥沼里面，越动弹陷入的越深。
六、架构没有及时变更，适应现行的业务
当一个项目成长为一个庞然大物的时候，往往是团队中的所有人很难察觉的，因为是我们不知不觉中创造了这个庞然大物。因为参与项目的人被划分在不同的领域进行编程，每个人都有自己的想法，而想法不断在被实现。所以在原来的架构上，某些部分会不断膨胀。就像一家小公司的部门一样，负责了属于自己过多职责之外的事情，变得尾大不掉。
总结
回顾一下，其实代码腐烂原因还是那么几点，没有规范的约束，没有专注自身，不能及时修改。奈何，这个世界的套路太深，套路的表现形式也会因为时代的改变而变，然而，往往一不小心就给套路了。而且最近发现一个现实，程序员总是想要把一切都变得完美，但现实却是矛盾的均衡体。在慢慢接受这一现实情况下，发现对周围一切的不完美，越来越容易接受。是否这样，导致了越来越多的腐烂？
