All notes
CodeReview

Intro

Good references:

Benefits / Targets

Agile teams are self-organizing, with skill sets that span across the team. This is accomplished, in part, with code review. Code review helps developers learn the code base, as well as help them learn new technologies and techniques that grow their skill sets.

Agile teams can realize huge benefits because work is decentralized across the team. No one is the only person who knows a specific part of the code base. Simply put, code reviews help facilitate knowledge sharing across the code base and across the team. Full stack engineers can tackle front-end work as well as server-side work.

Code review is not just a senior team member reviewing a junior team member’s code. Code review should happen across the team in every direction. Newer members, with fresh eyes, discover gnarly, time-plauged areas of the code base that need a new perspective. So, code review also helps ensure new insight is tempered with existing knowledge.

Don’t wait for a code review if feedback is needed earlier in the development cycle.

Best practices

Initiate a code review after all the code has been written and automated tests have been run and passed–but before the code is merged upstream. This ensures the code reviewer’s time is spent checking for things machines miss, and prevents poor coding decisions from polluting the main line of development.

Checklists

Unbounce.

FAQ

When to do code review?

We develop on a topic branch, submit a pull request, review the request in isolation, and merge only on acceptance.

What if author and reviewer disagree?

Unbounce.com.

What to do when the source developer and the reviewer disagree about a change? Who wins?

At Unbounce reviewers aren’t goalies; they don’t have the final say on whether code moves forward, they’re simply making recommendations. A developer could choose to ignore suggestions and comments and push an issue forward anyway, but by the same token if the reviewer strongly disagrees, they’re welcome at any point to raise the issue up with the dev team in general, usually through email, to get second opinions.

In our experience force-of-will pushes rarely happen, and group discussions tend to settle disagreements nicely.