code rievew困局

几乎所有的开发流程方法都强调代码复查的重要性，但根据自己的经验，实施起来确不尽人意。 团队总共6个人，以小项目（2～3人月）为主，基本上每个人的项目处于饱和状态，绩效管理主要看个人完成的项目数量。

复查过程主要遇到的两个问题， 一是代码复查会成为reviewer的负担： reviewer一般都是团队的骨干， 本身就很忙，还要复查动辄成百上千的行的code，其结果不外乎：

1） 流于形式，reviewer舍本求末,跳过业务逻辑，而给出一些类似行缩进，tab/space,注释风格类的问题，效果不佳

2） 反馈滞后， 开发者不愿再动baseline的code

二是管理者的期望问题， 在追查生产环境中的“问题”/bug时，boss第一问为什么没有测试出来，第二问为什么没有review出来 －把code review看作了一种UT...

 

对于问题一，公司专门开发review系统，号称可以记录effort，并测算review的投入产出比，要求各团队收集历史数据用于项目计划估算，想法不错，可是实践中开发人员更愿意直接交流，草草填写的review数据并不靠谱。

至于问题二，主管要求搞一个checklist。 个人认为编码是一种高度不能“容错”的活计，一行出错，满盘皆输。根据人（至少是我）的认知能力，后期确认发现的问题，怎么看都觉得能review出来，回头要搞预测性的checklist，估计要开一个保罗万象的清单才行。

 

改进计划：

 a) 提高review的积极性（难），计划： 1）激发reviewer，办review来看作一个学习机会 2） leader 要check 每个review的结果

 b) 持续多次review，避免一次review 500行以上的change； 分开design review和code review

 c) 定期review “technical review checklist”，keep it as a brief list limited in one page

 d) expectation management -- persude manager to accept  the idea there are always some issues can be found by review

 

占坑： 立此为据，3个月后以观后效

 

 

－－－－分割线，6个月后的update －－－－－－－－－－－－－－－－

改善：明确了对review的期望:

      - review <> UT,  review 不是查bug的

      - 强化经验交流和培训目的

 

 

不足：enough motiviation， reviewee still treat it as "burden"

 

下一步：

1） 推行“结对设计”（非全程结对）， 迭代review

2） 希望基于review，积累review后的comments 完善“团队知识库”