The Good,

The Bad,

And the Code Review

Manu Castrillón

Universidad de Antioquia

Medellín, Colombia

@manucastrillonm

A
Code
Review?

Benefits

Learn and share

All the peers can explicitly know what functionalities are being added, updated or removed

@manucastrillonm

Raise team standards

Committers will tend to produce a better quality code, because they know someone else will be examining their work.

@manucastrillonm

Set the mindset for an open company culture

By introducing the process to give and to receive feedback in our natural daily workflow.

@manucastrillonm

Reduce the cost of fixing bugs

The cost of fixing a bug increases exponentially over the time in a development workflow

@manucastrillonm

What

To

Look For

  • Design: Do the interactions of various pieces of code in the PR make sense?

 

  • Functionality: Does this CL do what the developer intended?

 

  • Complexity: Is the CL more complex than it should be?

 

  • Tests: Ask for unit, integration, or end-to-end tests as appropriate for the change

@manucastrillonm

  • Naming: Did the developer pick good names for everything?

 

  • Comments: Did the developer write clear comments?

 

  • Documentation: If a PR changes how users build, test, interact with, or release code, check to see that it also updates associated documentation.

@manucastrillonm

Good

Practices

For all

Don't take things personally

Is not a "dev vs. peers"

@manucastrillonm

Use Checklists

"...we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know."

- Donald Rumsfeld

@manucastrillonm

For committers

Provide context

  • Ensure your commit message explain what are you trying to achieve and how.

  •  Link any related tickets or issues.

  •  Comment your code.

@manucastrillonm

Keep the code short

Beyond 200 LOC the review effectiveness drop significantly, more than 400 it's almost pointless.

@manucastrillonm

Push commits based on earlier rounds of feedback as isolated commits to the branch

@manucastrillonm

For reviewers

You must understand the change you are reviewing

@manucastrillonm

Don't waste your time

There are plenty of tools for checking style and formatting issues.

@manucastrillonm

Everyone should review!

@manucastrillonm

 Code review for short sessions

No longer than an hour

@manucastrillonm

Reviews

Communication

For all

  • Be humble

  • Keep it real

@manucastrillonm

For committers

  • Try to respond every comment

  • Be grateful for the reviewer's suggestions

@manucastrillonm

For reviewers

  • Judge the code, not the developer

  • The code is not 'his/her code' is 'our code'

  •  Ask good questions. Don't make demands.

@manucastrillonm

Thank You

@manucastrillonm

The good, the bad and the code review

By Manu Castrillón

The good, the bad and the code review

  • 906