Effective review

如何在软件项目中进行effective review？这是个问题。

在时间紧张的时候，大家过于关注自己的部分，往往对其他人的工作没有足够的熟悉程度，这时候进行review往往得不到好的效果，尤其是在不提前进行准备的情况下。

一直以来，认为大家先在底下独自review，然后再聚到一起把review结果汇报一下的做法不经济，所以选择让大家会上当场review，随着owner的引导，大家一路review过去。但一直有一个问题：很多人跟不上队伍，或者干脆不打算跟上，这样的review会留下很多隐患，以至于有些功能遗漏居然没有发现。其实大家独自review也会有这个问题，只是时间宽松一点，可以做的细致一点而已，但同样没有效率。

review最根本的功能有两个方面：例行检查与功能检查。例行检查目标是找出不符合普遍规范的地方，例如文档不完整，code形式不符合规范等。功能检查的目标是找出错误理解需求或遗漏需求的地方，也包括算法或架构性能、安全等方面的缺陷。

在采用现场review的时候，由于节奏很快，把这两方面的检查一起进行，可能就会导致很多人“身在曹营心在汉”的状况，review草草收场。

怎么办？分开呗，进行至少两遍review，第一遍例行检查，第二遍功能检查。如果有意见，也可以颠倒顺序。例行检查根据checklist进行，功能检查根据上一环节的input，如需求文档，设计文档等。

Document Review

首先owner展示文档，reviewer检查各部分是否齐全，是否遵守约定的模板。第二遍功能检查视各文档目的而定，如设计文档要看能否覆盖需求，如果不能，是否已在文档中指出。

Code Inspection

1.功能检查

按scenario进行，owner需要在会前准备scenario，并且标注每个scenario对应的需求点。

Inspection的第一步是检查scenario是否符合需求，覆盖所有需求点。

接下来对着每个scenario进行功能实现检查。

2.例行检查

例行检查的checklist需要在项目启动的时候定义好，或在编码前定义好，如果有人不熟悉，需要进行培训或沟通。

这个checklist需要经验的积累或借鉴别人经验的结晶，根据编程语言有所不同，例如C++语言需要检查指针操作、内存的分配/释放等，而Java项目就无须检查这些。但基本编程原则的check是一致的，例如变量命名等。