漫谈代码规范对开发组织的重要性

08/08 14:49
阅读数 44

某项目程序员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基金会下那也十几年不倒的项目。

一行烂代码,三千烦恼丝

公众号回复:规范

下载google 和 alibaba java开发手册

本文分享自微信公众号 - 互联网后端架构(fullstack888)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
在线直播报名
返回顶部
顶部