这是一篇移民文章，标题是借来的，文中不少观点来自业内！但我对这些观点非常认同，也曾经为此付出代价，故分享一下感受！
某项目程序员A因为xxx原因，写了一行烂代码（如图1一行烂代码），项目千辛万苦熬到交接。B接手项目，增加功能，修改代码；然后C继续维护…… 直到某一天X接手这个项目，项目已经很难维护了，成本飙升，甚至有些新的功能已经无法加入，为此不得不重构项目，投入大量人力回归测试，如“图2 擂鼓击花，看谁倒霉”。
一个没有代码规范的项目，就算不换人，过些时间作者本人也不一定记得当初程序的意义，尤其如图1示例中的变量n1、ct、cd谁知道存储的是什么内容呢？更何况现实情况是软件项目换人率很高，如软件中心采用自有人员加外员的混合模式开发，换人是必然。代码规范落实不好，项目维护一两年就会变成灾难，成本飙升、效率下降、没人愿意接手。因此软件组织很重视代码规范（组织也会有其它规范建设），但为什么代码规范落地过程中并不如意呢？我调查一些项目，以及一些软件开发人员，主要有下面一些原因，导致代码规范落实不到位：
1. 代码规范比较枯燥难以记忆，个人都是按自己理解做。尤其是对变量、方法等命名上，有人喜欢用下划线、有人喜欢用大小写区分、至于缩写就更是因人而异。一次，数据库中重要的备份表被删除，原因是这个维护项目组喜欢用人名缩写做备份后缀。某新人来了以后，给“营口局”做备份用了“YKJ”后缀，这个后缀恰好是另一个同事名字缩写，那个同事分析完数据，就自然给删除了。
2. 通过培训可以加强组员对代码规范的认识，只是中心自有人员不足，外员流动较大，规范培训效果大打折扣。而且程序员在成长过程中，慢慢会形成自己的编程习惯，这种习惯很难通过一两次培训就改变。
3. 有些程序员不愿意改变自己的习惯，短期内也不是问题，因为每个人都能完成自己的工作。尤其一些技术较好的“大牛”，会很好的完成自己的工作。很多时候会认为自己的习惯更“优秀”而不愿意改变。对于一个组织，如果有岗位变动，那么这个“大牛”的工作往往需要几个人才能接下来。
4. 迫于工期压力，放宽标准。有时确实是项目进度要求太紧，这时自然不自然的就会从质量上找时间，而代码规范属于内部质量范畴，一般客户感知不到。至于将来维护麻烦，那也不一定落到自己头上。
5. 有的人觉得自己可以完成高难度的算法，就认为自己能力很强，追求个性。殊不知复杂的算法确实可以体现你个人的逻辑能力，但是绝不代表你的开发水平，用大炮打蚊子，就算打中，又能怎样？杀敌一千，自损八百，比之羽扇纶巾，强虏灰飞烟灭，差距就不是一点半点了。
6. 规范不好落实，投入、产出实在不成比例。往往花了大量的力气培训、考试、抽查，但是问题依然不断。在权衡代码规范与工期之后选择了放宽标准。
7. 如果原项目比较烂，在软件后续维护过程中，很少有人因程序不符合代码规范维护程序，后续的更改基本都是将计就计，不断打补丁。这个项目也沿着烂代码之路不断循环如图3，最终走向死亡，项目的一坨烂代码带坏了一群人。
一个产品对于一个组织，就是这个组织的生存根本，组织对待产品就像农民对待庄稼一样，要从头负责到尾，没有农民愿意看到自己的庄稼死掉，也没有组织愿意自己的产品死掉。因此，很多组织都有自己的代码规范，并且花大力气培训自己的员工，努力保持人员稳定。可是人员流动难免，如何落实代码规范？如何保持项目持续发展？
我认为除了培训、考试、抽查等传统方法外，还应该增加自动化的代码规范辅助落实工具，代码规范检查工具，这样才能在提高效率的同时降低成本。代码规范落实工具分四个阶段介入开发过程：首先通过传统方式培训人员，讲解代码规范的作用，通常业内认为代码规范有如下作用：
1. 规范的代码可以促进团队合作
如果没有统一的代码规范，每个人的代码风格迥异。即使是分工十分明晰的，等到要整合代码的时候也有够头疼的了。大多数情况下，并非程序中有复杂的算法或是复杂的逻辑，而是去读别人的代码实在是一件痛苦的事情。统一的风格使得代码可读性大大提高了，人们看到任何一段代码都会觉得异常熟悉。显然的，规范的代码在团队的合作开发中是非常有益而且必要的。
2. 规范的代码可以降低程序后续维护成本
随着我们项目经验的累积，会越来越重视后期维护的成本。而开发过程中的代码质量直接影响着维护的成本。在第一点中提到，规范的代码提高了程序的可读性，可读性高的代码维护成本必然会大大降低。 但是，维护工作不仅仅是读懂原有代码，而是需要在原有代码基础上修改。
3. 规范的代码可以减少BUG处理
大多代码是绘制人机交互界面、描述业务流程。在规范的开发中，BUG不但可以有效减少，查找BUG也变得轻而易举。 规范不是对开发的制约，而确实是有助于提高开发效率的。
4. 规范的代码简化自动化测试的实施，降低自动化测试案例维护成本
自动化测试案例实际是另一种程序。编码无序的程序首先很难编写测试案例；其次开发中没有规范，测试的时候，很多案例就无法复用，增加案例编写成本；最后，当代码变更时，会导致大量测试案例变更，增加自动化测试案例的维护成本。
5. 规范的代码有助于代码审查
代码审查，可以及时纠正一些错误，可以监督代码规范落实情况。团队代码审查也是一个很好的学习机会。但是，开发随意，加重了代码审查的工作量及难度，并且使得代码审查工作没有根据，浪费了大量的时间却收效甚微。
6. 养成代码规范的习惯，有助于程序员自身的成长，规范开发最大的受益人其实是自己！一些开源项目，一些大师级人物写的程序都是极其规范的。并非规范了就代表高水平，实际上是规范的代码更有利于帮助你理解开发语言、理解模式、理解架构，能够帮助你快速提升开发水平。著名的Python框架Django的核心开发者JacobKaplan-Moss，在PyCon2015年度聚会上，“Hi，I`m Jacob，and i`m mediocreprogrammer”。记住！每天垒乱码并不能使你获得更多的进步，相反要达到高水平的程序员，养成良好的开发习惯是绝对必需的。真正的价值不是你写了其他人都看不懂的代码，而是你写的代码大家都觉得好用。代码规范看似无用，经过慢慢的累积由量变达到质变的时候，你才能感受到其价值所在。
其次给开发人员提供代码美化工具，帮助开发人员提高效率，提供代码检查工具，协助开发人员查找违反开发规范的地方，提醒修改；再次通过代码入库时即时检查强制代码规范落实；最后通过入库后源码综合分析查找更深层问题。这四个阶段使用相同规则，前一个阶段解决的问题，在后一个阶段就不会发生了。示意图如下：
第一阶段属于企业文化加上，培养员工基础素质，让员工意识到代码规范的重要性，主动重视代码规范。
第二阶段程序员自查主要是在Eclipse的CheckStyle插件完成（检查规则和入库前检查相同）代码入库前检查。为了减轻程序员调整代码格式的负担，同时定制了Eclipse的sourceformat配置文件和注释模板文件，格式类的问题都可以自动解决。在程序员自查通过后，第三阶段是不会报错的。
第三阶段就是程序员提交代码时强制检查，不分析程序逻辑，主要检查代码规范。无论提交成功与否，日志都将留作后续分析用。
第四阶段是代码综合检查，业内可用的工具很多，我们目前使用Sonar做集成工具，内部使用FindBugs、PMD、Check Style三种规则集，通过定制检查规则集落实复杂的代码规范，编程规约。
第四阶段检查属于事后检查，为了简化工具使用难度，提高问题反馈及时性，开发了一个结果报告，并且与自动提醒系统结合。自动推送项目检查结果报表给相关同事。有朋友戏说“这个东西是不是搞项目排名”，其实不然。虽然代码检查结果汇总表有排序规则，但不同的项目背景、不同的项目复杂度、不同的人员、不同的技术、不同的工期等因素导致项目之间同一个指标并没有可比性，但是对于同一个项目，同一个指标不同时期应该是处于逐渐收敛状态。
使用代码规范工具后，如图1中的代码就无法入库，程序员必须修好然后才能提交，修改后代码如图5.代码可读性却比图1中的代码好很多（如果还能有合理的注释，那么这个代码可读性就更好了）。
落实代码规范不但能够提高产品质量，还能够降低软件后续维护成本，减少革命式重构代码的大量投入。真心希望能够通过规范开发，提供软件企业总体水平，也创造出如Apache基金会下那也十几年不倒的项目。