劣质代码产生的八个原因

十一假期的第一天，拖完地、洗完衣服，看了一会《The clean code》，想到了一些问题，决定搜集资料对劣质代码是如何产生的整理一番，于是这个上午就写了这篇博文。

一、理论知识匮乏

1、复制粘贴

先从实习生说起。这帮熊孩子刚毕业后，在对生产环境还不了解的情况下，为了完成工作。于是，就从项目中其他的地方复制类似代码，然后修改。如此，大概半年后，就会觉得自己似乎已经无所不能了，即便再学习，也是要赶些时髦玩玩HTML5、芒果DB什么的（要不然出去如何开口是好）。可惜的是，鲜有人会告诉他们长期这么做无异于自毁。可话说回来，谁管你干嘛呢？用你的人只关心项目进度。

回到话题，有一种观点认为Copy/Paste效率更高，并且认为这样做对于程序员的水平要求较低，组建团队相对容易。但是，从项目的角度讲，这样做会让错误蔓延，从而引起更多的代码问题以致影响发布时间，降低质量。从程序员的角度讲…没什么好讲的，既然懒得自己写，我觉得回家卖水果或许是个更好的选择。

2、按照流程图实现代码

有一些项目经理会采用流程图的方式进行代码设计，开发人员会认为只要照着逻辑流程图实现代码即可。但是，采用流程图进行代码设计时会误导开发人员把对象关系、抽象等放在次要地位，这种设计方式容易导致圈复杂度增高，而圈复杂度的提高会导致BUG增多。

3、临时对策

有些开发人员在时间压力下，对于一些代码变更的要求采取了临时对策，并且认为这种临时对策即使留在代码中也没有什么问题，目前的首要任务是完成更多的功能。想一想，自己有没有在某个时刻为了解决某一问题，采取了某一临时对策？

然而，这种临时对策往往会形成技术债务，当技术债务积累到一定程度时，就要开始还债了。毕竟，出来混都是要还的，利息还很高…

4、定式思维

我们在初学某种技术时会参照一些例子，一旦遇到某种和例子相似的情况就会按照例子的方式来进行书写。这是一种快速的学习方法。然而，如果对于所有的情况都按照例子的情况来书写而不敢突破的话，代码就未必能保持最佳风格。

举几个问题，这几个问题我先不解释，如果有兴趣，可以回应一下：

（1）动作一定是方法吗？
（2）状态只能采用整数定义吗？
（3）for循环一定要有下标吗？

二、对编程语言不熟悉

这个很基础，是本，没什么需要讲的，但是不能忽视。比如Java，现在都已经Java8了，其中的许多特性我们未必懂，整天搞来搞去可能就那么几点。其实，Java的使用还是有许多技巧的，推荐读一读《Effective Java》.

三、对开发环境不熟悉

由于对开发环境不够熟悉，有很多很方便、很快捷的功能没有得到良好的利用，以致花了大量的人工去完成机器可能几秒就可以完成的工作。毕竟，工欲善其事，必先利其器。思考一下，如果有以下几种操作，在你的IDE上应该如何实现：

（1）光标的操作
（2）Refactor
（3）添加插件
（4）自动引入外部库
（5）查看外部源代码

四、对设计方法不了解

对于这个问题，我们首先思考一下，是谁把我们这一行变成了“码农”？是我们自己。由于任务划分等管理方面的原因，开发人员被定为为依靠别人的设计进行代码加工的“码农”，以至于开发人员很少能够思考设计方面的事情，只是机械地堆砌代码。可是，不要忘记了，编码本是一种设计行为，项目不仅是产品，更是我们自己的作品。婉约一点地讲，不要因为忙碌而忘记了初衷…

顺便说一下常见的由于对设计不了解而造成的问题：

（1）重复与类似
（2）结构包不清晰
（3）类责任不明确
（4）常量数据类
（5）长方法
（6）复杂分支
（7）类膨胀

项目中的问题远比这个多，重要的是，我们在寻找方法解决问题的同时，也要避免自己犯下类似的错误。

五、编程方法不佳

为了快速实现某个功能不顾现有架构，采用了临时的解决方案。下面的这些常见的编程习惯将会造成技术债务：

（1）迷信IDE自动生成代码
（2）命名习惯不好
（3）没有管理好代码的职责
（4）对照教材照本宣科
（5）不考虑调用时的样子
（6）不设计就编码

六、英语能力不足

代码的命名都是通过英文来进行。采用本地语言命名（包括俚语和俗语）会导致对应文化背景的读者无法理解代码的意思。但是由于英语不是母语，再加上不使用英语会导致开发人员在书写代码时无法正确使用英语，导致难以写出高可读性的代码。

英语不好不是我们选择中文拼音的理由，英语不好，我们就去学。

许多优秀的资料，也都是英语，所以还是补一补英语比较好。

七、管理人员误导

1、形而上学的编码规范

我相信每个公司都至少有一套编码规范，我以前也提倡过，我和一些同学同事交流的时候，也有不少推崇的。

但是，推崇可以，不能把它当成一把无所不能的瑞士军刀，有比没有好，但是有了未必就是最好。

编码规范的制定是为了形成一种统一的编码风格，从而保持代码的整体一致性和质量。可是，我们可以看到，许多开发人员使用了编码规范后，就认为代码的质量提升上去了，从而对被遮蔽的问题视而不见，或浑然不知。

我更喜欢的一句话是：风格上尽情的随波逐流，原则上必须稳若磐石。

如果我们都能把代码写得一级棒，那代码规范就可以寿终正寝了。

2、时间压力下的催促

管理人员在时间的压力下会催促编码人员更快地完成工作。然而，速度更快往往意味着采用临时方案，意味着对质量的放弃，欠下技术债务。

我们真的那么着急吗？就像人生那样，我们都那么着急结婚干嘛呢？准备好婚后的人生了吗?可是我们就这么急。这方面最常听的话就是，我们没有那么多的时间去想那些问题。

可是，我们不要忘了，如果我们在开发的时候急功近利，欠下的技术债务都将在未来变本加厉的加倍偿还。在一个软件的生命周期中，运维的时间要远长于开发阶段。就好比建造一座大厦，也许建造它只需要五年，可是它有可能要服务五十年，不能因为某个领导要验收就偷工减料草草了事。

当国内的某些食品或建筑出现安全时，我们常常会不假情面的搬出道德和人伦的大旗对食品厂商和施工单位加以口诛笔伐。

可是，安静地想一想，我们自己又怎么样呢？我们难道和他们不是一类人吗？我们让各位领导安心了，可是我们的心往哪里安放？项目落地了，我们的脸也要跟着落地吗？

3、过分限制开发人员

当开发人员认为增加一个代理类可能会更好地解决这个问题时，管理人员却提出不允许增加类；

当开发人员提出数据库表的一些字段应该拆出去另作一个表，以降低耦合性的时候，管理人员却提出不允许修改表结构；

当开发人员提出增加一个全局变量，使数据更容易传递时，管理人员却提出不允许增加全局变量。

…

也许，上述行为出于某些正当理由，但是，如果武断地划定范围而不是对每个修改行为进行探讨时，就是一种懒人式的管理，是造成好的方法不能够应用的障碍。

当本该管理项目的的管理人员对技术干预过多的时候，我们年纪轻轻的开发人员就会失去本该有的活力、积极性和创造力，最后和项目一起烂掉。

八、自己不想好了

如果知道了前面的种种问题后，仍然不去思考、不去改变，不想方设法做得更好，那就是我们自己的问题了。

如果我们现在不改，等到我们将来当上了项目管理人员，会害了手下的一帮兄弟，因为我们其实不懂技术，却还要在下属面前装一把（相信我，你一定会这么干的），还会让项目和一些关系捆绑在一起，做事最后就成了“做人”。

抛开所有的立场，想一想，改变，可能吗？

可是，什么是劣质代码呢？我写的代码都很棒啊？！