code review的感想

我们公司曾经展开过code review的相关工作，由我负责，

持续时间，大概有半年左右。

首先，我们公司是小公司。

在我开展这项工作的时候，每个人都是想怎么写，怎么写，没有什么约束。

当然，代码维护工作量也非常巨大。甚至说几乎不具备维护性。

如果一个人离职，让另一个人接手，会特别困难。

而且代码有很大性能问题。

当时借助了不少代码评审的工具，比如reveew board，eclipse findbugs插件等，

花了很大的时间，研究这些工具的使用，并给每个人培训。

但是，用上这些工具之后，发现一个问题，

问题不是在发现问题，还在发现问题之后，如何处理。

代码不规范，注释几乎没有，代码冗余，运行性能差等等一堆问题。

我当时根据实行中越到的实际情况，做了一下三个方面的努力：

1.对于代码规范的问题

我自己起草了一份代码规范，

当然这个参考了网上的一些东西和自己实际的编程经验，

强制执行，每次发现不合理的地方，立马更新。

渐渐的这个代码规范，使越来越多的人可以接受。

2.关于性能问题。

每个人水平参差不齐，

我把共性的问题，作为一个专题，进行专项整治，

自己写出性能，效率高的，重用性高的代码，进行专项培训。

并且优化代码提取公共模块，公共模块的编写，参考很多资料，

和本人的经验，来实现，并做专项培训。

3.关于执行

采取教育+强迫的方式，

一方面强调代码评审的作用和好处，让每个人认可，有很多是口头上的认可。

另一方面，杀鸡儆猴，有一个关系不错的哥们，因为没有按时完成代码优化任务，

被我当众批评，其他人自动的都约束自己完成优化任务。

21天养成一个习惯，90天巩固一个习惯，

最初一个月，

根据编码规范和公共实例，修改自己之前的代码。

并且强制要求按照代码规范编写，

后面三个月主要采取抽查的方式，我也有我的工作，不可能永远扑到这个任务里。

就这样，慢慢的个人都养成了编写规范代码的习惯，

公司的代码比较规范，也比较易于维护。

之前的难点，都总结成了专题文档，有不会也易于查看。

前面起到一些软件工具，我觉得只能起到辅助作用，

起决定作用的还是人。把人的习惯培训好了，

自然团队的力量也大了。

当时的失误：

1.由于当时采用了杀鸡儆猴的策略，

搞的那个哥们，挺郁闷，最后离职。

如果不采取这种方式，code review根本推行不下去，两难的选择。

2.没有起草形成一个良好的制度。

从新人培训开始，到规范的积累，到公共类得积累的机制，评审会议的积累。

我已经离开那家公司，

我走了之后，估计那些东西没人维护，慢慢的都丢了。

总结：

1.最适合自身情况的方法才是好方法，

2.工具能提高工作效率，但只是死的工具，只会做规范的有规律的事情，恰恰很多事情很特殊，工具无法满足，所以不要迷信工具，起决定作用的还是人。