1 / 11

Code Reviews

Conduct code reviews to find bugs cost-effectively, uphold coding standards, and enhance system implementation knowledge among team members. Include formal inspections, inspection roles, and follow-up procedures for efficient code review sessions.

conboy
Télécharger la présentation

Code Reviews

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Assignment • Each team should perform a code review • Select a section of code • Select your more difficult code sections. • Other members of the team and the instructor will be given copies of the code to review at least 48 hours ahead of time. • The code review should last about 1 hour. • Don’t select too much code – about 300 lines is good Code Reviews

  2. Find bugs in the least costly manner Ensure that coding standards are maintained Train staff and disseminate knowledge of system implementation Make sure code is readable and maintainable Code Reviews Objectives

  3. All participants are given copies of the code to be reviewed before the review (usually a couple of days ahead of time) The reviewers review the code before the meeting The code author and other team members gather to review the code The principal goal is to find bugs (defects), not fix them Formal Inspection

  4. Moderator • Sets the pace • Arranges meeting and manages materials • Reports Results • Follows up • Author • Answers questions • Explains things that are unclear (and will obviously have to be changed.) Formal Inspections Roles

  5. Reviewer • Fellow programmer • Tester • High-level architect • Scribe • Records problems (the official record of the review) • Records action items • Management must be excluded from the meeting Formal Inspection Roles ContInued

  6. Enough to consume about an hour’s time Number of lines of code varies significantly with code complexity How much Code should Be Reviewed in one Meeting?

  7. Someone other than the moderator or author reads or paraphrases the code • Reviewers make relevant comments as the code is read • Remember you are looking for bugs • Address the code – not the programmer • (“The code does” … rather than “You did…”) • “Egoless” is the goal, but seldom the reality • Reviewers don’t recommend fixes Inspection Meeting

  8. Issued within 24 hours of the meeting • Report is a record of what was found • “What was found” provides statistics for management on efficacy • What was found provides opportunity for follow-up Inspection Report

  9. Rework • The author fixes the defects • Follow-up • The moderator is responsible for seeing that the defects have been addressed, but it is up to the author to make decisions about what needs to be changed. • Review the code again • Review relevant sections only • No formal review Reworks and Follow-up

  10. Optional informal meeting in which reviewers discuss solutions. This meeting should only be held if the author requests it, or if there are significant urgent problems. Third-Hour Meeting

  11. Over-the-shoulder Reviews • Author walks through code with one peer • Less formal • Less documentation/assurance of completion • No formal followup • Email (pass-around) reviews • Not constrained to place/time • Can be difficult to track the conversation • Pair-Programming • Pairs can be too close to the code to see problems • May be more time-consuming/expensive • Can be combined with formal reviews Alternatives

More Related