Daniel Brown

1
Daniel Brown

• Code Reviews
• What do they mean to Project Managers

E-Mail daniel.brown_at_internode.on.net Blog
http//www.danielbrown.id.au/
2
(No Transcript)
3

• Introduction

4
What are we going to cover?

• What is a code review
• How to perform one
• When to perform them
• What are the benefits
• Tips

5

• What is a Code Review?

6
Code Reviews are not

• A Blame Game!
• A way to measure a developers abilities!
• A long meeting!!!!!!!!

7
What is a Code Review?

• A Constructive way to find
• Common Defects
• Memory Leaks
• Complex Code
• Broken functionality
• Vulnerabilities
• Buffer Overflows
• Size Checking
• Exploits
• Security Defects
• Missing / Wrong Security permissions
• Elevation or privileges
• Inaccurate in-code documentation
• A way to build and exchange knowledge
• Language independent

8
Why review in-code documentation?

• Ensure the comments are valid accurate against
  the code
• It should explain what it SHOULD do, not what it
  does
• Easy to read and understand

9

• Benefits

10
What metrics can you gather?

• Major defects
• Minor defects
• Documentation defects
• How much time is allocated to bug fixes
• (this is a good thing! it gives you better
  datetime projections!)

11
How to these metrics help?

• Show Progress to everyone
• Track how many defects have been stoped from
  going into production
• Save Time and Money

12
Knowledge Exchange

• Teaches the new as well as the old by
• Giving new perspectives
• Documentation Writing

13
Benefits of conducting Code Reviews

• Catch defects early before the users see them!
• Information and Knowledge exchange between
  developers
• More reliable software (Known-state)

14
Pre-requisites

• Standard
• Example ECMA
• Source Control
• SVN, TFS, SourceSafe, CVS

15
How to perform a code review

• Before anything, Code reviews are social
• You want the developer juices flowing!
• Before the review
• What to review
• Reviewing
• Roles
• Reading
• Recording defects
• Keep it simple Major/Minor/Investigate
• Follow Up

16
How to record defects

• Spreadsheet
• Columns
• , Title, Details, Major/Minor, Assigned To,
  Recorded, Completed

17
When to perform code reviews?

• Every X number of Check Ins to Source Control
• Only review what has changed
• - OR
• As often as you need

18
Summary

• Code Reviews Productivity
• Designed to be pro-active
• Not a blame game!
• Part of the development lifecycle
• Easy to manage
• Do them Friday
• But keep them focused! (they will deviate)

Get more information http//msdn.microsoft.com/en
-us/library/aa302437.aspx http//en.wikipedia.org/
wiki/Code_review
19
Questions?
20

• Thanks

E-Mail daniel.brown_at_internode.on.net Blog
http//www.danielbrownid.au/ Mobile [phone]