1. 24
  1.  

  2. 6

    It’s nice to see Google publish their standard on code reviews. The standard feels polished, detailed, yet concise.

    I recently what separates great code reviews from okay ones and found it reassuring that this piece hits on a few pieces:

    Conflict. In any conflict on a code review, the first step should always be for the developer and reviewer to try to come to consensus, based on the contents of this document and the other documents in The CL Author’s Guide and this Reviewer Guide. When coming to consensus becomes especially difficult, it can help to have a face-to-face meeting or a VC between the reviewer and the author, instead of just trying to resolve the conflict through code review comments.

    Also, it was great to see a section dedicated to the speed of the code reviews. I work at a large, distributed tech organization, so the one-day rule is important to go by. It was just as nice to stumble on a section dedicated for distributed code reviews with different time zones:

    When dealing with time zone differences, try to get back to the author when they are still in the office. If they have already gone home, then try to make sure your review is done before they get back to the office the next day.

    Finally, I found the emergency code reviews part a thoughtful read. It’s good to see things called out, like it’s not an emergency, just because someone higher up in the chain says it needs to be done today.

    1. 4

      I believe CL is Change List but, unless I’ve missed it, that wasn’t actually explained in any of the documents

      1. 2

        It’s explained here but there is no link to this page unfortunately.