代码规范及其推广

        目前国内代码规范的标杆应该是阿里出的代码规范了，洋洋洒洒的50多页，几乎把开发中能考虑的东西都考虑进去了。普通发开发人员光理解上面的内容每个一两年的功底都是件很困难的事情。现在很多公司也是以那个规范为基础来设计自己公司的规范。我们公司也是这样做的，刚来开始进公司的时候就那个30多页的规范，连看完的心情都没有了。等进入工作状态后做的第一件事情就是重新整理这个规范。

        代码规范也属于制定规则的部分，规则就要考虑普适性，就是要让最差的那个人也能遵守，或者最差的人通过努力也能遵守。另外就是好不好管理的事情，最好的状态就是每天早上打开邮箱就能看到昨天提交代码的报告，谁提交了多少违法规则的代码，程度怎么样，如果再高级一点还可以把一段时间内一个人的情况汇总展示一下，柱形图什么的。如果要做成这些来看下需要具备那些要素，首先要有一套规则，第二要有一套程序能够自动的去检测代码，生成报告，既然能自动检测的，那么这个规则一定要可以量化，你说一个方法不能超过50行这个可以量化。但你要说代码注释要简单明了，这个就很难说了，什么是简单，什么是明了，对于熟悉设计模式的人来说看到一句采用观察者模式就够了，不熟悉的人来说就需要观察者的完整教程了，这个自动程序就很难自动检测了。

        上面是从管理者角度来说的，从开发者角度来说应该就只有一个会不会增加工作量的问题了，一个功能平时需要4个小时完成，使用规范以后得用5个小时，这个就不能接受了，有这一个小时刷会手机不香么。

总结一下，代码规范就需要符合这些条件才行了

        1、有没有用。

        2、好不好量化，能不能自动检测

        3、使用了会不会大幅增加工作量，会不会需要大量的学习成本

按照这三个条件再去刷选阿里的代码规范，下面就是筛选完以后的规范了，

代码规范

        规范有了，下面就是推广使用的事情了，上面提到最好能够自动化检测，并生成报告。这个要求有点高，我们只做到了自动化检测，团队开发工具是IDEA，就使用checkStyle插件，自定义了一个检测脚本，每个人都按照上，上传代码的时候先自检一下，这上面无法自动检测的内容有后缀‘、前缀以及多态的方法放到一起。这样项目管理人员只要每天获取代码运行一遍脚本，然后再重点关注一下脚本无法检测的地方就行了。这样做就能满足基本要求了，

        如何推广没问题了，接下来就是看推广过程中最大的拦路虎是什么了。第一个就是老代码的维护问题，首先老代码不管不行，但大规模的全部按规则优化一遍也不现实。只能采用零敲牛皮糖的策略了，每次有ticket的时候，修改相关代码的时候要以方法为单位把代码规范化，具体的做法是以方法体（函数）为单位，如果改过某个方法：

        1、方法的参数，变量必须按格式修改完成。

        2、方法体注释必须补全。

        3、自己加的代码必须有注释，

        4、屏蔽的代码必须删除掉。

        另外如果改过某个类，这个类也必须进行格式化处理，就是缩放的那条规则。再解释一下为什么老代码不用遵守50行的规则，首先历史代码有很多核心的方法都超长，没人敢动，另外老代码还是维护改ticket为主，不相关的代码原则就是能不动就不动，如果强制要求的话就会造成为了拆而拆的情况，不光达不到优化代码的目的，反而会增加代码的混乱度和阅读理解难度。

        第二个拦路虎就是常量，魔法值的问题了。从某种意义上说，枚举、静态常量都可以做成常量值的实现方案，其中静态常量又可以根据使用范围分为类内常量，模块内常量，全局常量。他们还会随着项目进展而变化，类内变量可能会升级为模块内变量，全局变量可能会降级为类内变量，光是维护就头大了，

        对于常量来说要管么，要。但怎么管就需要灵活把握一下了，我的做法是老代码不管，全靠自愿。新代码核心的公共代码必须遵守，业务代码尽量使用枚举，不用能使用枚举的不做要求。因为公司有自己的开发框架，业务代码影响范围有限，使用写死的值也不会又太大的影响。使用了反而会增加开发时间，投入和收益不匹配。