我们公司曾经展开过code review的相关工作,由我负责,
持续时间,大概有半年左右。
首先,我们公司是小公司。
在我开展这项工作的时候,每个人都是想怎么写,怎么写,没有什么约束。
当然,代码维护工作量也非常巨大。甚至说几乎不具备维护性。
如果一个人离职,让另一个人接手,会特别困难。
而且代码有很大性能问题。
当时借助了不少代码评审的工具,比如reveew board,eclipse findbugs插件等,
花了很大的时间,研究这些工具的使用,并给每个人培训。
但是,用上这些工具之后,发现一个问题,
问题不是在发现问题,还在发现问题之后,如何处理。
代码不规范,注释几乎没有,代码冗余,运行性能差等等一堆问题。
我当时根据实行中越到的实际情况,做了一下三个方面的努力:
1.对于代码规范的问题
我自己起草了一份代码规范,
当然这个参考了网上的一些东西和自己实际的编程经验,
强制执行,每次发现不合理的地方,立马更新。
渐渐的这个代码规范,使越来越多的人可以接受。
2.关于性能问题。
每个人水平参差不齐,
我把共性的问题,作为一个专题,进行专项整治,
自己写出性能,效率高的,重用性高的代码,进行专项培训。
并且优化代码提取公共模块,公共模块的编写,参考很多资料,
和本人的经验,来实现,并做专项培训。
3.关于执行
采取教育+强迫的方式,
一方面强调代码评审的作用和好处,让每个人认可,有很多是口头上的认可。
另一方面,杀鸡儆猴,有一个关系不错的哥们,因为没有按时完成代码优化任务,
被我当众批评,其他人自动的都约束自己完成优化任务。
21天养成一个习惯,90天巩固一个习惯,
最初一个月,
根据编码规范和公共实例,修改自己之前的代码。
并且强制要求按照代码规范编写,
后面三个月主要采取抽查的方式,我也有我的工作,不可能永远扑到这个任务里。
就这样,慢慢的个人都养成了编写规范代码的习惯,
公司的代码比较规范,也比较易于维护。
之前的难点,都总结成了专题文档,有不会也易于查看。
前面起到一些软件工具,我觉得只能起到辅助作用,
起决定作用的还是人。把人的习惯培训好了,
自然团队的力量也大了。
当时的失误:
1.由于当时采用了杀鸡儆猴的策略,
搞的那个哥们,挺郁闷,最后离职。
如果不采取这种方式,code review根本推行不下去,两难的选择。
2.没有起草形成一个良好的制度。
从新人培训开始,到规范的积累,到公共类得积累的机制,评审会议的积累。
我已经离开那家公司,
我走了之后,估计那些东西没人维护,慢慢的都丢了。
总结:
1.最适合自身情况的方法才是好方法,
2.工具能提高工作效率,但只是死的工具,只会做规范的有规律的事情,恰恰很多事情很特殊,工具无法满足,所以不要迷信工具,起决定作用的还是人。
持续时间,大概有半年左右。
首先,我们公司是小公司。
在我开展这项工作的时候,每个人都是想怎么写,怎么写,没有什么约束。
当然,代码维护工作量也非常巨大。甚至说几乎不具备维护性。
如果一个人离职,让另一个人接手,会特别困难。
而且代码有很大性能问题。
当时借助了不少代码评审的工具,比如reveew board,eclipse findbugs插件等,
花了很大的时间,研究这些工具的使用,并给每个人培训。
但是,用上这些工具之后,发现一个问题,
问题不是在发现问题,还在发现问题之后,如何处理。
代码不规范,注释几乎没有,代码冗余,运行性能差等等一堆问题。
我当时根据实行中越到的实际情况,做了一下三个方面的努力:
1.对于代码规范的问题
我自己起草了一份代码规范,
当然这个参考了网上的一些东西和自己实际的编程经验,
强制执行,每次发现不合理的地方,立马更新。
渐渐的这个代码规范,使越来越多的人可以接受。
2.关于性能问题。
每个人水平参差不齐,
我把共性的问题,作为一个专题,进行专项整治,
自己写出性能,效率高的,重用性高的代码,进行专项培训。
并且优化代码提取公共模块,公共模块的编写,参考很多资料,
和本人的经验,来实现,并做专项培训。
3.关于执行
采取教育+强迫的方式,
一方面强调代码评审的作用和好处,让每个人认可,有很多是口头上的认可。
另一方面,杀鸡儆猴,有一个关系不错的哥们,因为没有按时完成代码优化任务,
被我当众批评,其他人自动的都约束自己完成优化任务。
21天养成一个习惯,90天巩固一个习惯,
最初一个月,
根据编码规范和公共实例,修改自己之前的代码。
并且强制要求按照代码规范编写,
后面三个月主要采取抽查的方式,我也有我的工作,不可能永远扑到这个任务里。
就这样,慢慢的个人都养成了编写规范代码的习惯,
公司的代码比较规范,也比较易于维护。
之前的难点,都总结成了专题文档,有不会也易于查看。
前面起到一些软件工具,我觉得只能起到辅助作用,
起决定作用的还是人。把人的习惯培训好了,
自然团队的力量也大了。
当时的失误:
1.由于当时采用了杀鸡儆猴的策略,
搞的那个哥们,挺郁闷,最后离职。
如果不采取这种方式,code review根本推行不下去,两难的选择。
2.没有起草形成一个良好的制度。
从新人培训开始,到规范的积累,到公共类得积累的机制,评审会议的积累。
我已经离开那家公司,
我走了之后,估计那些东西没人维护,慢慢的都丢了。
总结:
1.最适合自身情况的方法才是好方法,
2.工具能提高工作效率,但只是死的工具,只会做规范的有规律的事情,恰恰很多事情很特殊,工具无法满足,所以不要迷信工具,起决定作用的还是人。