本文共 1890 字,大约阅读时间需要 6 分钟。
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.
另外参考文章:Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1815089