CRV2 ManualReviewProsCons

Revision as of 07:36, 28 May 2013 by Gary David Robinson (talk | contribs) (Created page with "= Manual Review - Pros and Cons = Add content here ... == Benchmark of different Static Analysis Tools == Add content here .. == Advantages of Code Review to Development...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Manual Review - Pros and Cons

Add content here ...

Benchmark of different Static Analysis Tools

Add content here ..

Advantages of Code Review to Development Practices

Expand upon the following points, stress that some depend upon the code review procedure/tool used

  1. Can provide developers (especially code maintainers) with an historical record of code changes
    1. As well as code review containing the code, it should also have the Functional Specs, Design Specs, etc included/linked so the reviewers know the context of the change.
    2. After code review is done, and code submitted, the code review procedure/tool should store these details for future reference. If/When years later some different developer wants to work in the same area (and the original developer has moved on) they have a record of the change made, along with review comments & decisions.
  2. Code review should also describe the testing (unit, component, manual, etc) that was done to verify the change, allows reviewers to be confident the developer tested the change in the right way.
  3. Junior developers can learn from senior developers during code review. After you learn the basics of a language and read a few of the best practices book, how can you get good on-the-job skills to learn more... well code review can provide that. Apart from buddy coding (which rarely happens) code review is the best place for junior developers to see how the experienced guys do it.
  4. Developers can become more familiar with the code base. Two examples of this, 1) someone (or team) creates a new functional area, then code review allows others who may use that code in the future to become familiar with it, or 2) some cross pollination for silo'ed teams, where they reach out to other teams to review their code, everyone then learns a bit more about the company's code.
  5. This happens less frequently, but does happen, people can spot potential clashes. Person 1 and 2 are working in and around the same area of code, person 1 is going to put their change in 1st, so includes person 2 on the review so person 2 can know if it's going to clash with the code they're about to submit next week.
  6. Code can be reviewed against guidelines. If the company creates guidelines for coding, security, performance, logging, etc, the code review is the place to ensure those guidelines are followed. I.e. a piece of code that may do the job fine, could be rejected because it does not adhere to the coding guidelines. Maybe doesn't matter much for standard code, but for code associated with secure interfaces, this is where the OWASP top 10 could be enforced.