聊Code review(下)
如何进行Code review?
见过很多架构师、高级软件工程师抱怨过Code review没什么效果,这次review出现的错误,下次review时还会出现。也碰到过猿猿抱怨的情况:Code review 浪费时间,很多业务还等着开发呢;或者,Code review那就是某人装X。为什么Code review 那么不好做,没有效果,而且很多公司做不好呢?我的观点是,思路比方法重要,Code review 是为了推广代码的最佳实践,而不是挑出代码存在的问题。
读过上篇应该能得出这样的结论——代码审查是要找出程序代码中问题,提高代码质量。那我们是不是code review 就是去挑错?相信很多人的回答是肯定的,因为我见过很多公司就是这么去做的。 如果你仔细读过上篇,应该还会得到一个结论:提高程序员的技术水平! 挑错只是针对即将投入生产线上的环境的一个战术层面的方法论。让程序员技术水平提高,保持对优秀代码的追求意识,才是确保代码质量的关键和最终目标,属于战略层面。团队技术水平,才是解决代码质量的关键。 按这个思维方式,不仅可以达到确保和提高代码质量的目的,并且在Code review实施过程中减少猿猿们的抵触心理和心理压力,阻力没有了,才可以取得持续和高效的效果。对此借用George Perkins Marsh 的一句话。
看,是与生俱来的本领;发现,则是一门艺术。——George Perkins Marsh
我最喜欢的梵高画作,因为他对自己认定的东西有着固执的追求的性格。 优秀的代码, 和美的东西东西一样,人打心底是渴望,而不是排斥的。Code review 就是要激发猿猿们对美的(代码)追求。在猿猿们还没有这种意识之前,最好的Code review方式是把尽可能多的人召集起来,如果代码涉及效率、并发、安全等问题,可以邀请相关方面的专家一起review。以上篇提到的代码规范和专家的意见作为衡量标准,在指出问题的同时,将经过优秀的代码即时的扩展到整个团体。同时,建议邀请对代码有洁癖的”固执“者,在辩论中,加深印象、碰出火花。合理有效的利用观点冲突,可以很好地发现问题,解决问题。犹如这幅画作,就是冲突的结果。
当猿猿们有追求优秀代码的自觉,较强软件质量意识培养起来的时候,才可以采用结对编程的方式。特别是互联网行业这两年的膨胀的情况下,团队成员总是处在磨合期的情况,更应执行团体review的方式。把Code review 做为成员磨合的一个团队建设活动。在追求美代码思想的引导下,避开针对个人,在猿猿之间形成以代码规范为基础的语言体系;不仅可以Code review取得良好效果,而且可以快速融合团队,提高团队工作效率。及时的Code review还可以在代码交付测试前,发现功能遗漏、逻辑缺失,范围蔓延的问题,确保满足需求,不增一分,不减一毫。
何时进行Code review,每周一次还是每周两次?个人认为,最少每周一次,以项目紧张程度,见缝插针。时间紧张的时候,可以将代码审查时间缩短一些,但是一定要维持一定的频率,以时刻提醒,让猿猿们养成最求好代码的习惯。
代码review, 不只可以review项目成员代码。也可以安排阅读学习开源项目优秀的代码,例如Java 源码,Apache 下的项目。通过对它们的阅读,了解什么样的代码才是优秀的,也了解到优秀项目的代码也是会有瑕疵的。这样猿猿们看到别人代码有瑕疵的时候,不会过于代码洁癖,培养猿猿们相互之间的包容心。
激发猿猿们追求美(优秀代码)的意识,是Code review的终极目标。猿猿有了艺术的追求,这没准能帮助他们找对象呢。:)
![聊Code review(下) 聊Code review(下)](/default/index/img?u=aHR0cHM6Ly9waWFuc2hlbi5jb20vaW1hZ2VzLzc2OC8zOTU1ZjUyMGQzOGY1NWE1NjNlNzViM2RhYjFiZjY0MC5KUEVH)
见过很多架构师、高级软件工程师抱怨过Code review没什么效果,这次review出现的错误,下次review时还会出现。也碰到过猿猿抱怨的情况:Code review 浪费时间,很多业务还等着开发呢;或者,Code review那就是某人装X。为什么Code review 那么不好做,没有效果,而且很多公司做不好呢?我的观点是,思路比方法重要,Code review 是为了推广代码的最佳实践,而不是挑出代码存在的问题。
读过上篇应该能得出这样的结论——代码审查是要找出程序代码中问题,提高代码质量。那我们是不是code review 就是去挑错?相信很多人的回答是肯定的,因为我见过很多公司就是这么去做的。 如果你仔细读过上篇,应该还会得到一个结论:提高程序员的技术水平! 挑错只是针对即将投入生产线上的环境的一个战术层面的方法论。让程序员技术水平提高,保持对优秀代码的追求意识,才是确保代码质量的关键和最终目标,属于战略层面。团队技术水平,才是解决代码质量的关键。 按这个思维方式,不仅可以达到确保和提高代码质量的目的,并且在Code review实施过程中减少猿猿们的抵触心理和心理压力,阻力没有了,才可以取得持续和高效的效果。对此借用George Perkins Marsh 的一句话。
看,是与生俱来的本领;发现,则是一门艺术。——George Perkins Marsh
图片说明 :《梵高割耳朵自画像》,1888年梵·高邀请高更来阿尔同住,但两个固执的艺术家却是不断的争吵。在一场剧烈争执后,高更大怒而去,梵·高无法阻止,亦无法抑制自己的激动,竟割下自己的右耳。
我最喜欢的梵高画作,因为他对自己认定的东西有着固执的追求的性格。 优秀的代码, 和美的东西东西一样,人打心底是渴望,而不是排斥的。Code review 就是要激发猿猿们对美的(代码)追求。在猿猿们还没有这种意识之前,最好的Code review方式是把尽可能多的人召集起来,如果代码涉及效率、并发、安全等问题,可以邀请相关方面的专家一起review。以上篇提到的代码规范和专家的意见作为衡量标准,在指出问题的同时,将经过优秀的代码即时的扩展到整个团体。同时,建议邀请对代码有洁癖的”固执“者,在辩论中,加深印象、碰出火花。合理有效的利用观点冲突,可以很好地发现问题,解决问题。犹如这幅画作,就是冲突的结果。
当猿猿们有追求优秀代码的自觉,较强软件质量意识培养起来的时候,才可以采用结对编程的方式。特别是互联网行业这两年的膨胀的情况下,团队成员总是处在磨合期的情况,更应执行团体review的方式。把Code review 做为成员磨合的一个团队建设活动。在追求美代码思想的引导下,避开针对个人,在猿猿之间形成以代码规范为基础的语言体系;不仅可以Code review取得良好效果,而且可以快速融合团队,提高团队工作效率。及时的Code review还可以在代码交付测试前,发现功能遗漏、逻辑缺失,范围蔓延的问题,确保满足需求,不增一分,不减一毫。
何时进行Code review,每周一次还是每周两次?个人认为,最少每周一次,以项目紧张程度,见缝插针。时间紧张的时候,可以将代码审查时间缩短一些,但是一定要维持一定的频率,以时刻提醒,让猿猿们养成最求好代码的习惯。
代码review, 不只可以review项目成员代码。也可以安排阅读学习开源项目优秀的代码,例如Java 源码,Apache 下的项目。通过对它们的阅读,了解什么样的代码才是优秀的,也了解到优秀项目的代码也是会有瑕疵的。这样猿猿们看到别人代码有瑕疵的时候,不会过于代码洁癖,培养猿猿们相互之间的包容心。
激发猿猿们追求美(优秀代码)的意识,是Code review的终极目标。猿猿有了艺术的追求,这没准能帮助他们找对象呢。:)
后面的话:Code review 所有优秀代码,形成的规范,除了形成规范文档外。还可以进一步将规范落实到各种代码检查工具之中。以JAVA为例,关于代码样式:可以将代码样式在check style里定义,并定义成template文件;也可以将代码语法,编译错误检查放到 Find bugs里去;也可以Jeking + 定制sonar 的方式来完成代码的检查。更高级的玩法是代码通过模板来生成,采用DSL来生成代码,这里不展开。其它语言也是大同小异。
分享者简介
易荣平,架构师,总体规划成员, 负责国美在线总体架构规划,技术规范制定和技术研发推广。善于分析解决复杂业务需求,提出技术解决方案。了解产品设计、敏捷开发,对技术充满热情,关注电商、互联网、云计算、大数据、人工智能。
个人公众号:荣平中生代技术群微信公众号