Loading ...
Sorry, an error occurred while loading the content.

158659Re: Code review practices

Expand Messages
  • gustavonarea_tech
    Apr 29, 2013
    • 0 Attachment
      Where I work, we try to have another pair of eyes in everything we do, except for the occasional, trivial, no-brainer change.

      We use one of the following approaches, depending on the task at hand:
      - Pair programming.
      - Solo development, with a design review prior to the implementation.
      - Solo development, followed by a review of the implementation after the change has been committed to the repository.

      When we do solo development, we normally use both design and implementation reviews.

      We do pair programming when one of the following conditions is met:
      - We want to transfer knowledge (e.g., about a library) from one participant to the other.
      - The task will involve removing or changing code spread across multiple locations (since a single person may miss occurrences or not spot all the consequences).
      - We need to add a new non-trivial component.

      We do solo development when we think pair programming isn't worth it (as is the case with a minority of the tasks) or when we can't form a pair (and the developer would be idling otherwise).

      If we do solo development, we'll also do a design review before implementation happens, unless there's one obvious way to make the change. This is, the implementer will propose a design to another developer, and once both are happy, the implementer will, err, implement it.

      And every time we do solo development, another person will review the implementation. Unless it's really trivial, as mentioned above.

      Sometimes we'll start doing pair programming, and then split once we've gotten to a point where it's no longer worth pair programming.

      In terms of planning for this, we do Scrum, and in the second part of the planning meeting (when we do the story breakdown), we'll estimate the effort required to complete each task considering the approach we intend to take.

      HTH,

      - Gustavo.


      --- In extremeprogramming@yahoogroups.com, Charles Bradley - Professional Scrum Trainer and Coach <charles@...> wrote:
      >
      >
      > Hi,
      >
      > I'm trying to come up with a list of different ways of doing code reviews as they relate to a Scrum definition of done.
      >
      > In practice, I've seen:
      >
      > * A scheduled meeting for a code review, several show up and review code
      >
      > * Paired Programming  (I realize XP'ers are biased to PP, and nothing wrong with that)
      >
      > * Live review by one other programmer just before code commit.
      > * Code review published to code review system (like Atlassian Crucible, etc) with deadline by which reviewers can submit feedback.
      > * Code review published to code review system (like Atlassian Crucible, etc)
      > where code cannot integrate until one person says "ship it"
      > * No code reviews
      > * Code reviews only on special occasions or in certain parts of the code
      > What other code review type practices have you seen?
      >  
      > -------
      > Charles Bradley
      > Professional Scrum Trainer
      > Scrum Coach-in-Chief
      > ScrumCrazy.com
      >
      > [Non-text portions of this message have been removed]
      >
    • Show all 8 messages in this topic