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

Re: [XP] Code review practices

Expand Messages
  • James Grenning
    Here is an approach to reviews in a pair programming TDD environment that has worked well for some team I have worked with: - trust the pair to apply the
    Message 1 of 8 , Apr 29 6:35 AM
    • 0 Attachment
      Here is an approach to reviews in a pair programming TDD environment that has worked well for some team I have worked with:

      - trust the pair to apply the coding standards and to refactor
      - review only the test cases
      - if the pairing was done by two less experienced TDDers, review the code too.
      - periodically run coverage check to see if any legacy code is being written

      By reviewing just the test cases
      - you lighten the review load
      - you review the architecturally significant aspect of the design
      -- interface of the code under tests
      -- the interactions of the code under test with other entities in the design
      -- check that the code do the right thing


      thanks, James

      --------------------------------------------------------------------------------------------
      James Grenning Author of TDD for Embedded C
      www.renaissancesoftware.net http://pragprog.com/titles/jgade/
      www.renaissancesoftware.net/blog
      www.twitter.com/jwgrenning
      >



      [Non-text portions of this message have been removed]
    • Vlietstra, Joe (ES)
      ... We use some form of code inspection (ala Fagan) almost exclusively. In theory, this makes defining done easy -- the inspection is done when the moderator
      Message 2 of 8 , Apr 29 1:50 PM
      • 0 Attachment
        On 26 April 2013 23:33, 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:
        > ...

        We use some form of code inspection (ala Fagan) almost exclusively.
        In theory, this makes defining "done" easy -- the inspection is
        done when the moderator verifies that the rework is complete.
        In practice, there are four different events that may be called
        "done":
        1. Developer completes code and sets up inspection
        2. Inspection (logging) meeting (possibly virtual) itself
        3. Developer fixes any issues identified from inspection
        4. Moderator verifies fixes
        Which event counts as "done" depends on the purpose. For example,
        when the developer completes code, he or she is available to pick
        up the next open task; so event 1 is "done" when working resource
        scheduling. At the other extreme, we use all 4 events (weighted
        80%, 10%, 0%, and 10%, resp.) when determining earned value (EV).

        Joe Vlietstra
      • Phlip
        ... I love it when people who don t need to help you actually finish features get to patrol their territory by reviewing your code changes, and gating them.
        Message 3 of 8 , May 9, 2013
        • 0 Attachment
          > 4. Moderator verifies fixes

          I "love" it when people who don't need to help you actually finish
          features get to patrol their territory by reviewing your code changes,
          and gating them. Blatant fail of the guideline we should unite
          authority and responsibility!

          --
          Phlip
          http://c2.com/cgi/wiki?ZeekLand
        Your message has been successfully submitted and would be delivered to recipients shortly.