代码不规范？985,211也不要！

为什么写代码要规范？可以说代码是程序员的第二张脸

场景：

要讨论这个问题，我们首先得说点其他的。我们来假设一个场景：相信每个朋友最开始都有这种感受：哇，今天状态超好，简直是文若铅华，丝若泉涌。敲起键盘来简直感觉不要太顺畅。随着一连串的编写，可能写完抬头一看一上午或者一下午就过去了。要么是饭点，要么就该要下班了。在想一想自己今天的状态，那感觉不要太好。然后高高兴兴就回家或者吃饭去了。之前的事情告一段落。。。。。。。然后时间慢慢过去.....

问题来了：

3个月后，项目经理在团队里面问道，之前的这个项目是谁负责的来着，然后顺利的找到你，现在客户有一些新的需求，既然之前是你写的，那么你来改一下吧。。。

想着也确实是自己写的，也没有多大问题，稍微看下改了就是，于是乎痛苦的事情来了。下载了自己当初写的源码，打开一看，API注释没有写全，代码注释基本没有，当时的变量取名也比较随心，是什么意思来着。。。。。。当初怎么想的，在大量的工作堆积下早已想不起来。花了半天时间看代码，越看脸越黑，我相信此时这个代码要是不是自己写的，恐怕就已经要骂人了。

怎么解决：

那么此时的你改怎么办呢，如果这是一个小项目，只有几千行源码，也许你会觉得重写一遍远比去理解当初的意思来的更快，然而，如果这是一个大项目呢，涉及的代码量可能有几万行的时候怎么办？毫无办法，只能一步一步去尝试理解，然后重新添加注释，你会发现这需要花的时间成本太高了 ，长时间的加班就显得不可避免，还会给领导落下个工作效率低下的映像。这都不是你所想要看到的结果。

实际案例：

在前不久，我们团队接到一个项目，粗略的看了一下，源码大概在1.3W+的样子，

简单的通过公司的质量检测工具做了份质量评估报告：

　　API注释率35%；

　　代码注释覆盖率10%；

　　不符合编码规范问题1W+；

　　存在严重阻断100+；

拿到这个质量检测报告我的内心是崩溃的，这等于这项目的源码基本是看不了的。尝试去阅读理解然后对其进行维护的可能性基本等于零。

这使得我们不得不思考重写整个项目的可能性，在用了大半个月的时间做可行性分析（包括原维护部门的人员交流，原开发部门的文档补全，测试部门的测试用例。。等等）之后，我们得到了可以重写的结论。接下来就是对新环境的搭建，新测试用例的搬迁，新单元源码的重写。。。。为此又付出的4个月左右的时间。前前后后加起来就是小半年。而这些时间本身是有必要付出的吗？答案当然是否定的。

即使明白代码规范的好处，但是有的迫于项目压力，有的因为繁琐的规范作出很多额外的工作，更有的不重视维护的问题，而很难贯彻代码规范。

那么，我们需要了解，规范开发最大的受益人其实是自己！

你有没有花费很多的时候查找自己的代码呢？尤其是出现bug的时候需要逐行的debug？自己写的代码乱了头绪的确实也见了不少。我们应该做的就是规范开发，减少自己出现的错误。很多时候项目的压力一部分也是由于前期开发中遗留的众多的问题。

还有的人觉得自己可以完成高难度的算法，就认为自己能力很强，不把规范放在眼里。很多人确实是这样，追求个性，大概让别人看他的代码一头雾水更觉得得意。殊不知复杂的算法确实可以体现你个人的逻辑能力，但是绝不代表你的开发水平。我们知道一些开源项目，一些大师级人物写得程序都是极其规范的。并非规范了就代表高水平，实际上是规范的代码更有利于帮助你理解开发语言理解模式理解架构，能够帮助你快速提升开发水平。不明白这点，即使你写的再高明的算法，没准哪天也被当作乱码别处理掉。

记住！每天垒乱码（或许你不觉得，但是大多时候在别人眼中确实就是乱码）并不能使你获得更多的进步，相反要达到高水平的程序员，养成良好的开发习惯是绝对必需的。

不要沉迷表面的得失，看似无用的东西要经过慢慢的累积由量变达到质变的时候，你才能感受到其价值所在。

欢迎更有感触的朋友留下自己的心得分享吧~