Code Reviews 101

Goal:

Increase code quality by using effective collaboration and encouraging a proactive learning environment

Why Code Reviews are important

• Better code decreases waste of Resources/Engineers time (refactoring, redesigning and fixing existing code).
• Code Reviews improve Quality, which reduces Incidents (getting page in the middle of the night).
• Promote Team collaboration and knowledge sharing.
• Identify absence of S O L I D principles.
• Leverage cross-functional skills (Dev, Test, DevOps, etc.).

How is this helping ME?

• By doing Code Reviews, the learning from peers is encouraged.
• Code Reviews improve the "Attention to Detail" skill.
• You will be more productive. Writing good quality code will become more natural.
• Code Reviews promote technical discussions and, with that, the opportunity to talk to very smart people will grow.

Will It slow me down?

• When done right, Code Reviews actually save time in the long run.
• Review your own code as it wasn't yours before asking for a Code Review.
• Select and include multiple potential reviewers even if they are from different Teams (as long as they have the correct context).

How does this improve Product quality?

• If you have the correct metrics in place, the number of code issues will be lowering down.
• If you have same or more number of code issues, most probably because those issues used to be swallowed, silenced or masked before.
• Code Reviews will promote Testable code.

How/What am I learning?

• Give it some time... learning it's not a overnight process. Collaboration will bring implicit value at the same proportion as the Code Review practice is exercised.
• In order to learn, asking for reviews is not enough, it's also good practice review peer's code (include yourself in code reviews) and be actively involve in comments and discussions.

How does this relates to Agile?

• Code Reviews share the knowledge and mentor newer engineers.
• Code Reviews make for better estimates.
• They promote the early feedback.

Code Review Guidelines

When you submit a code review:

• The amount of code submitted for Code Review should be as small as possible. Use your best judgement to identify how much implementation will be included.
• Give context to reviewers if needed by using the appropriate channels.
• If the code is related to a change in the UI, including screenshot or mock-ups for context is really helpful.
• Include and encourage reviews from Seniors Engineers and/or Subject Matter Experts (SME).
• Ask your peers directly to review your code.

When someone asks you to code-review:

• Important: Keep constructive/positive criticism in a and be open to discussion
• Do your best to address the code review request as soon as possible.
• If you cannot look at the code review the same day, let the submitter know so she/he can consider asking someone else.
• Let the author know when your are done and if there's comments about the code.
• Make sure to look for tests and if the test adds value and/or makes sense.
• If you think that the code is not in your area of expertise, let the author know. However, you can still review it in order to verify/suggest coding standards, code smells, patterns, etc.).
• When addressing open "discussions", If there are disagreements between your comment and the author opinion, involve a Lead or Senior Engineer for advice.