为什么要规范编码
前言：
为什么要规范编码，我相信这是每个程序员都曾经思考过的问题，每个人都应该有每个人的答案，在这儿我只是想谈一下我个人的感受，希望对刚入行的朋友能有所帮助。至于大神神马的，可以略过~~~~~
场景：
要讨论这个问题，我们首先得说点其他的。我们来假设一个场景：相信每个朋友最开始都有这种感受：哇，今天状态超好，简直是文若铅华，丝若泉涌。敲起键盘来简直感觉不要太顺畅。随着一连串的编写，可能写完抬头一看一上午或者一下午就过去了。要么是饭点，要么就该要下班了。在想一想自己今天的状态，那感觉不要太好。然后高高兴兴就回家或者吃饭去了。之前的事情告一段落。。。。。。。然后时间慢慢过去.....
问题来了：
3个月后，项目经理在团队里面问道，之前的这个项目是谁负责的来着，然后顺利的找到你，现在客户有一些新的需求，既然之前是你写的，那么你来改一下吧。。。
想着也确实是自己写的，也没有多大问题，稍微看下改了就是，于是乎痛苦的事情来了。下载了自己当初写的源码，打开一看，API注释没有写全，代码注释基本没有，当时的变量取名也比较随心，是什么意思来着。。。。。。当初怎么想的，在大量的工作堆积下早已想不起来。花了半天时间看代码，越看脸越黑，我相信此时这个代码要是不是自己写的，恐怕就已经要骂人了。
怎么解决：
那么此时的你改怎么办呢，如果这是一个小项目，只有几千行源码，也许你会觉得重写一遍远比去理解当初的意思来的更快，然而，如果这是一个大项目呢，涉及的代码量可能有几万行的时候怎么办？毫无办法，只能一步一步去尝试理解，然后重新添加注释，你会发现这需要花的时间成本太高了 ，长时间的加班就显得不可避免，还会给领导落下个工作效率低下的映像。这都不是你所想要看到的结果。
实际案例：
在前不久，我们团队接到一个项目，粗略的看了一下，源码大概在1.3W+的样子，
简单的通过公司的质量检测工具做了份质量评估报告：
API注释率35%；
代码注释覆盖率10%；
不符合编码规范问题1W+；
存在严重阻断100+；
拿到这个质量检测报告我的内心是崩溃的，这等于这项目的源码基本是看不了的。尝试去阅读理解然后对其进行维护的可能性基本等于零。
这使得我们不得不思考重写整个项目的可能性，在用了大半个月的时间做可行性分析（包括原维护部门的人员交流，原开发部门的文档补全，测试部门的测试用例。。等等）之后，我们得到了可以重写的结论。接下来就是对新环境的搭建，新测试用例的搬迁，新单元源码的重写。。。。为此又付出的4个月左右的时间。前前后后加起来就是小半年。而这些时间本身是有必要付出的吗？答案当然是否定的。
规范编码的重要性：
通过以上的假设与实际例子我们不难看出，规范的编码书写习惯是一个程序员自我修养的必要素质。也许在我们一开始的时候会觉得这些条条框框是那么的烦人，以及没有作用。但这是经过时间推敲的，是前人为我们总结下来的宝贵经验，而且一旦你养成了良好的书写习惯你会发现，看着有规范的代码是一件多么让人赏心悦目的事情~！（PS：如果你书写的代码都是高质量的代码，那么你离涨工资就不远了哦~~~~）
结尾语：
这篇文章主要是想跟刚入行的朋友们分享一下，在这个你原本可以以肆意书写的世界，为什么要制定那么多的条条框框来束缚你的编码。也是希望能警醒自己在编码的过程中能始终如一的追求编码的质量。而不是仅靠数量的堆叠。
欢迎更有感触的朋友留下自己的心得分享吧~