一期项目接近尾声,后半周一直奉命组织代码评审。作为平台部成员,一直很庆幸自己不用太过于考虑繁琐的业务,可以尽量专注在平台功能的开发优化和支持。这样项目开发过程中所需要的各种琐碎杂事也就理所当然落到我们头上,比如Code Review、发布脚本、上线方案等等。这其实倒也挺好,从本位中暂时脱离出来,去做一些编码之外的事情,既可以拓展自己知识面,又可以从多种维度去了解项目,加深对系统各个方面的理解。
道理总是在有了经历之后,才会有真切的体会。之前只作为局外人参与过一次评审会,而且当时会上气氛并不算太热烈。这次吸取前人“失败”的教训,流程上略微作些变动,结果也比之前稍微理想点。大概有以下三点,略作记录:
1)提前四天把评审要求和代码发给所有成员。不只是让经验丰富的老员工作评审,也给新人作评。可以调动新人参与的积极性,为四天后的正式讨论会活跃气氛作基础。就跟在学校上课一样,课前预习总是更易于保证课程质量;参与的人越多,才越容易有思考的碰撞。
2)会上让所有人轮流发言,有问题集体讨论。之前的评审会,只有主席一个人在从头讲到尾,其他人过于被动导致现场气氛不够热烈。同时这个发言方式也从另一方面督促大家在之前认真做好自己的评审工作,不然会上没什么讲的可就尴尬了。
3)拉头头作阵。一方面可以保证评审会秩序,另一方面会上遇到一些比较纠结的问题,也可以由他给予较为合理的解释,类似于专家评委。
这次评审会应该还算是比较充实丰满的,至少会上气氛还比较活跃,荣誉归于现场压阵的头头。之前参与的项目,因为各种原因,貌似都没有做过代码评审。这次经历,感觉很好,总结下我想到的几个优点:
1.保证代码质量。
这点是从项目本身来讲的,不用多说了,代码评审会检查出一些隐藏的BUG。而高质量的代码是工程牢靠健壮的基础。
2.讲述自己的处理逻辑,整理思维。
“当初写下这段代码的时候,只有我和上帝知道为什么这么写。现在,只有上帝才知道了。”
—来自某同事的MSN签名。
09年8月份左右,我在河南CRM现场开发了几个业务新需求。今年上半年再回去参与另一个项目时,当时交接的同事拿着当初我的代码找到我,问为什么这样写。我一脸茫然,无言以对…我想很多Coder应该都遇到过这样的尴尬吧。评审过程中,一些比较复杂的逻辑处理会被揪出来,这时你可以好好整理下自己的思维,想想自己当初为什么这么做,顺便练习下怎么说服那些评委了,讨论过程中也许还有会更好的解决方案出来,也是一个提高的过程。
3.评审交流中可以答疑解惑,学习到更多技术知识。
我觉得对于Coder来说,这是一个大大的好处,尤其是新人。Java平台的一个优点是有很多现成的框架产品可以使用,开发人员并不需要关注技术细节,专心业务处理就可以了。而正由于这种不透明性,对于很多技术细节的实现,很多人是一知半解的,只是记住怎么去使用组件。这有几个弊端:a.过于依赖别人提供的框架,脱离底层实现。改天换个框架,自己又是啥都不懂。b.如果不是很理解平台封装的一些具体实现过程,一旦开发过程中出现一些平台引起的Bug,没法跟踪定位,就只能望洋兴叹了。c.长期偏离技术,侧重业务,会将自己限死在行业里,限制发展(当然这条不适合已经确定了自己终身方向的同学)。
在评审会中,可以提出自己对一些组件使用的疑问。为什么要这么用?底层是如何实现的?有大牛们在,应该会得到很好的解答。另外在评审过程中,往往也会牵扯出一些业务知识,可以加深自己对系统的理解。
4.可以帮助建立知识库。评审中记录下大家在开发过程中经常暴露出来的问题,可以在下次项目中进行重点宣贯,一定程度上避免同样的问题出现。
这次评审中暴露出很多问题,对部分常见的做个小结,整理成tips如下,后面尽量Update:
1.关于异常的处理。提交的代码应杜绝类似代码:
e.printStackTrace(); 或者 System.out.println("...");
,运行期性能消耗较严重。可以使用log4j作日志记录。另外,异常不应跟业务逻辑处理扯上太多关系。类似于如下代码也是尽量不应出现的:
if(obj == null){ throw new Exception("......."); }
同时记录异常日志时,应尽量详细地描述导致异常的原因,可以大大方便日后定位问题。
2.开发过程中,应尽量写上有意义的注释,尤其是接口和比较复杂的处理逻辑!
3.类名和方法名的定义应尽量做到一目了然,看到名字即大概知道是用来实现什么功能的。
4.尽量使用系统中已有的功能实现,做到最大程度上的代码复用。比如
if(null != aa && !("").equals(aa)) ... 可以使用 if( StringUtils.isNotBlank(aa) ) ...
5.提交代码前确保已完全删除自己的调试代码。
6.尽量用接口去做实现类的声明。
7.在jsp中打算引入某文件时,应确认该文件是否在公用文件中已经引入,避免重复加载。
最后,推荐一款Eclipse插件:Jupiter。集成在IDE中,作代码评审就方便多了。Jupiter可以记录问题代码行号,还可以定义评审出问题代码的状态,类似于一般bug系统中的bug跟踪。缺点是使用起来有点略微不够流畅、不能支持导出记录文档、不能与SVN或CVS中的用户同步、缺少权限控制等。
此文首发于AQuarter,作为签到帖。欢迎讨论,不足之处,请提建议,谢谢。