注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

中吴南顾惟一笑

成功法则就是那19个字

 
 
 

日志

 
 

评审那些事  

2016-05-19 17:17:36|  分类: R&D |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

1. Purpose
    Using peer code review can improve code quality and makes the most of developers' time. Lightweight peer code reviews have been proven to be effective by scientific study and by extensive field experience.
Code reviews have two purposes.
    1). To make sure that the code that is being produced has sufficient quality to be released.
    2). As a teaching tool to help developers learn when and how to apply techniques to improve code quality, consistency, and maintainability.
    It is common sense that peer code review – in which software developers review each other’s code before releasing software to QA – uncovers bugs, encourages collaboration, and keeps code more maintainable. This reduces rework for both development and test resources.
But it’s also clear that some code review techniques are inefficient and ineffective. The meetings often mandated by the review process take time and kill excitement. Strict process can stifle productivity, but lax process means no one knows whether reviews are effective or even happening.

 

2. Category
    A quality-driven organization will practice a variety of peer review methods, spanning a spectrum of formality, rigor, effectiveness, and cost. Let’s look at descriptions of some common review approaches.
    1).  An inspection is the most systematic and rigorous type of peer review. Inspection follows a well-defined multistage process with specific roles assigned to individual participants. Inspections are more effective at finding defects than are informal reviews.
    2). Team reviews are a type of "inspection-lite," being planned and structured but less formal and less rigorous than inspections. Typically, the overview and follow-up inspection stages are simplified or omitted, and some participant roles may be combined (e.g., moderator and reader).
    3).  A walkthrough is an informal review in which the work product’s author describes it to some colleagues and solicits comments. Walkthroughs differ significantly from inspections because the author takes the dominant role; other specific review roles are usually not defined. Walkthroughs are informal because they typically do not follow a defined procedure, do not specify exit criteria, require no management reporting, and generate no metrics.


3. Roles and responsibility:
    A. Reviewees
        a) Explains application
        b) Shares the content
        c) Discusses solved problems.
    B. Reviewers
        a) Criticizes code against organization standards and goals
        b) Tries to make suggestions on how to fix
    C. Moderator - a reviewer who controls the meeting, not the content


4. Detailed process
    1). Preparation-meeting-rework-followup
    2). Use tools in all aspects of the review process:
        Automated File-Gathering
        Combined Display: Differences, Comments, Defects
        Automated Metrics Collection
        Some control over the workflow

 

There also are a few simple things that you can do to change the approach for the better:

1.    Ask questions rather than make statements. "You didn't follow the standard here" is an attack—whether intentional or not. The question, "What was the reasoning behind the approached you used?" is seeking more information.

2.    Avoid the "Why" questions. For example, "Why didn't you follow the standards here..." versus "What was the reasoning behind the deviation from the standards here..."

3.    Remember to praise.

4.    Make sure you have good coding standards to reference.

5.    Make sure the discussion stays focused on the code and not the coder.

6.    Remember that there is often more than one way to approach a solution. The goal is quality, maintainable code. If it meets those goals and follows the coding standards, that's all you can ask for.

7.    Exploit code coverage and code analysis tools

8.    Capture code issues in the backlog

9.   The learning from a design issue or programmatic style problem is shared

10.  Review fewer than 200-400 lines of code at a time.

11. Keep Review checklists (if used) short. Checklists substantially improve results for both authors and reviewers. Contain no items that are obvious or can be detected via automation, and should focus on things that are easy to forget (e.g. “Are all errors handled correctly everywhere?”).

As a developer:

            Remember that the code isn't you. You need to strive to not get defensive.
            Create a checklist for yourself of the things that the code reviews tend to focus on.
            Help to maintain the coding standards.
            Advantage of Coding Standards comes mostly from Consistent Use

  评论这张
 
阅读(37)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017