1. 一次檢查少於200～400行程式碼
2. 努力達到一個合適的檢查速度：每小時少於300～500行程式碼
3. 有足夠的時間、以適當的速度、仔細地檢查，但不宜超過60～90分鐘
4. 在複審前，程式碼作者應該對程式碼進行註釋
5. 建立量化的目標並獲得相關的指標資料，從而不斷改進流程
6. 使用檢查表（checklist）肯定能改進雙方（作者和複審者）的結果
7. 驗證缺陷是否真正被修復
8. 管理人員要營造良好的氛圍（文化），使大家可以積極地對待缺陷的發現，發現足夠多的缺陷，只關心問題是什麼、怎樣引起的，而不關心是誰寫的程式碼
9. 清楚度量工具（"Big Brother"）的作用——度量工具是雙刃劍，要小心使用
10. 自我約束：即使沒有時間完成所有程式碼的檢查，也應該儘可能去做，哪怕是一部分
11. 輕量級的code review是高效率的、可行的，並能有效地發現缺陷

I think the first thing you need to figure out is what kind of errors are you expecting to find during inspections. It must exist a clear idea of the goal of the review and all participants should share this idea. If this is not defined you may have reviews wasting time in discussions about variable names, indentation, code comments, message descriptions, or any other topic.

In my company for example, we don't look for code conventions compliance, we use automated tools to ensure that. We run static analysis tool on our code before inspections, therefore we don't look for the type of errors that this tool can easily report. But we do look for compliance with the design: is the code implementing the defined design appropriately? Are all exception conditions handled following the design?

One useful thing that I did in the past to define our goal for code reviews is to read different code inspection checklists available online and identify the items that I considered useful for our reviews. Then, based on that list I agreed with the team the aspects that we should check in our code reviews. In that way we focused our effort and everyone was on the same page during the review.