作为程序员，写代码是我们工作的主要内容。最初，看到代码库有些代码写的混乱，我也会有些反感，甚至是埋怨前辈为何不写好点。后来我发现我太天真了，写出高效整洁代码真不是一件容易的事情，写代码就是在挖坑，给后人和自己踩的坑。

写了一年代码，我以亲身经历在此告知后辈，有整洁强迫症的人慎当程序员。为什么这么说呢？是什么让程序变得混乱呢？

1、历史遗留问题

之前见到有人吐槽12306的前端代码，吐槽他们用Jquery版本是1.4.2，Jquery最新版本是2.1.1（2014.9.12）。若是去扒代码的话，你会发现很多公司用的Jquery版本都不高，京东主页用的是1.2.6（2014.9.12）。这就是历史遗留问题，由于版本之间多多少少会有些差别，升级版本有着不可估量的风险，且项目越大风险越大。为了规避风险，再加上代码跑着没问题，一般来说负责人也就不愿去冒险升级了。不去升级会导致什么问题？一些比较新的方法不能用，这对开发人员来说有时是挺痛苦、挺无奈的。

上面只是历史遗留问题的一种情况，实际中还有很多，比如公用的方法逻辑杂乱冗余却没人敢去清除整理、系统架构过时、APP升级后对历史版本的兼容支持与维护等等。总之，写代码时你会遇到各种历史遗留问题。

2、系统架构的问题

实际来看，系统架构最初就考虑全面挺难的，需要经验极其丰富的架构师，即便是这样也只能保证在一定时期内架构满足需求。

抛开业务增长致架构无法满足需求不谈，有多少公司敢站出来说自己系统架构完美呢？一来，很多事都是需要权衡后取舍，技术也不例外，会出现为了解决一个问题引入另一个问题的情况。二来，互联网公司整体的浮躁，恨不得有想法就开始做，且新的技术不断出来，有些人管理为了追新不调研清楚就开始用，引入到系统架构之中，但新技术的引用往往会带来未知的风险。一旦引入的新技术在系统架构中出现了问题，造成的后果是极其严重的。这里不是说新技术不能用，是要慎用。

总结来说，系统架构问题主要原因有三点。一是有些系统架构搭建时需要根据项目需求做一些取舍，致在项目中做部分处理时较麻烦。二是系统架构师经验不足。三是有些项目管理者不够负责，想一出是一出。

系统构架问题也是代码混乱的原因之一，且问题一旦出现就不是几个程序员能够扭转的。

3、需求本身复杂

有些需求本身就很复杂，需要众多人分工协作来完成。这种大项目的代码逻辑注定不会简单，加上是由多人完成，也就很少有人懂得所有逻辑。

对于互联网企业来说，人员变动频繁，项目开发完，甚至是开发一半是说不定就有人走了，最恐怖的是走的人离开时连文档都没有留下。

遇到这种情况，接手的人只能的去扒代码找逻辑。非码农绝对不会了解扒代码找逻辑的痛苦。若是代码写的规范还好一些，若是写的不规范，再加上不是出于一个人之手，那对接手的人来说绝对称得上灾难了。

4、项目催得紧

互联网讲究的是快，仿佛不快就会死。对于这种情况，不知道真的是‘天下武功唯快不破’，还是老板压榨员工劳动力的借口而已。

快，必然导致项目迭代速度快，需求被催来催去，产品、测试以及经理都在后面催。遇到这种情况虽心里不爽，但我知道产品、测试以及经理也不容易，能够理解就理解，毕竟大家也都是为了工作。

需求被催的紧会导致代码质量完全没有保证。由于时间不够，看到需求想到实现方案就要开始动手写，根本没时间去考虑是不是最优的，后续的扩展性，这样写了会不会引起其他的问题等等。

由于最初没有时间考虑周全，开发时有可能会遇到一些完全没有预料到的问题，但仍旧是由于没有时间，根本没法返工重新设计，只能随便找一个能够解决问题的hack方法解决了。

由于项目时间紧，开发文档几乎不会有。一来可能是项目一个挨着一个根本没时间写。二来是需求做完了，开发都不清楚代码为何要那样写了。因那段代码可能是开发连续高负荷工作十几个小时下写出来的，那段时间开发的精神是恍惚。也许有人会说精神都恍惚了，为什么还不去休息啊，只能说需求不允许，开发比较敬业，不是老油条。

由于记不清当时为什么那样写，加上人都是有惰性的，没有人催促自然就不会去从仓促赶出来的垃圾代码扒逻辑了，况且一般来说开发根本没有完全的清闲时光，自然也就不会去补文档了。

除了文档，项目需求被催得紧也会导致代码注释不全。编码习惯好的可能会随手写些注释，编码习惯一般的就极有可能由于时间仓促而不写注释了。

项目需求被催得紧也会造成代码review形同虚设。因代码还未提交就有一帮人在后面催，想一想这样的情况还能愉快地走代码review吗？但对于新人来说，代码review是规范代码风格的必要步骤，是从师父的review中学习编码技巧的重要途径之一。

前三种令代码不整洁的情况在一定程度上不可避免，只能做到尽量的减少其对代码的影响，但催促项目需求这一点完全可以避免。

虽可避免，但从实际来看很少有互联网公司去注意这一点，似乎大家仍旧觉得只有快才能在‘拼杀’中胜出，根本不去考虑代码一旦混乱，后续的维护以及二次开发增加的时间、人力以及财力成本。

混乱的代码烂账也是跳槽的诱因之一，面对一份杂乱的代码时间长了会觉得恶心，恶心到受不了也就走了。

有时快是胜出的关键，但盲目的追求快也就是急功近利了，而急功近利往往是在自掘坟墓。

5、特殊需求

有时业务或产品会提出一些常人难以理解的逻辑。这可能是由于业务或产品想要实现某个功能，但当前的系统架构、技术实现或开发时间不允许，他们又非要想实现该功能，于是便整出了一个最初需求的阉割版，马不像马牛不像牛的阉割版需求。

一般来说这种需求会拟定后续版本，但这就犹如程序员说这个方法先实现了，后续有时间再优化一样，很少有下文了。造成这种现象的原因之一还是项目迭代快、时间不允许，另一点就是人的惰性。

除了阉割版需求称得上特殊需求，还有可能是想一出是出，但根本不了解实际情况的老板，或者高层提出来的需求，一般来说由于提需求的人地位在那里，做事的开发与产品等也就很难拒绝做了。

6、好代码需经验：

写出高效整洁的代码一来是程序员需要很高的素质、很好的习惯，二来真的需要经验。由于程序员缺口众多，新人不断的涌入近来。想一想网上之前的嘲讽段子“我们有一个非常好的idea，什么都准备好了，就缺一个程序员了”。从这一段子可以看出，有想法的人很多，但能够将想法实现的程序员很缺。

指望着没有经验的新人能够写出高效的，逻辑性非常强、没有任何冗余逻辑的代码我觉得不现实。新人代码风格不错就是比较好的了。其实，这个时候若是有一个好的代码review机制就非常好了，可是上面也提到了，由于种种原因，不知道多少公司的代码review根本形同虚设。

7、代码风格因人而异：

每个人的编码风格都不一样，习惯阅读的编码风格自然也就不一样了。实际项目开发往往又是由多人共同完成的，也就造成代码库内会包含各种风格的代码。风格一多，就自然有了与自己习惯风格不符的了。

虽这也算是阅读代码的一个障碍，但相对于上面的问题来说，它似乎不是什么大问题，除非遇到写代码完全不注意的人，再加上第四条提到的没有人review。

总结：

以上算是介绍了代码之所以杂乱的七点原因。说到这里，对代码多多少少有些认识的人，你们应该了解我最上面的“有整洁强迫症的慎当程序员”绝非危言耸听了。

在这里，我再次告诫所有后辈们，若是你有整洁强迫症，或者说你属于急性子，慎入程序员这一条路。否则会被代码虐千百次，虐的你心力憔悴，牙口胃口都不好了，心情也不好了，觉得整个世界都是灰暗的，人嘛，何必那么自找没趣，对不起自己呢？

最后，说点工作中的感悟。工作大家谁都不容易，部门不一样工作中考虑的出发点也就不一样，所以相互理解非常重要。若是真的遇到强横无理、不可以商量的，我会选择离开，省的整天与这种人生气添堵。工作毕竟是工作，令工作太过影响心情真的划不来。