Why code review? There are lots of good reasons. Programming is hard. We work with smart people. Discussing our work can be positive. Increases overall quality. Helps solve difficult problems. Spreads knowledge. Helps develop strong shared standards.
Who are reviews for? Developers. So that we can learn from one another.
10 Commandments of egoless programming. Understand and accept that you will make mistake. You are not your code. No matter how much “karate” you know, someone else will always know more. Don’t rewrite code without consultation. Treat people who know less than you with respect, deference and patience The only constant in the world is change. The only true authority stems from knowledge, not from position. Fight for what you believe, but gracefully accept defeat. Don’t be “the guy in the room.” Critique code instead of people. Be kind to the coder, not the code.
We all make mistakes. The important thing is to catch them as early as possible. Luckily our mistakes aren’t life threatening. We can fix them, move on and laugh about it.
You are not your code. The point of reviews is to find problems early, educate and learn. Don’t take it personally.
Always room to learn. We are all smart capable developers. Let’s learn from one another.
Ask why. Don’t just assume that something is wrong. Ask questions. Inquire about why something was done in a particular way. It might be the way it is for a valid reason.
Respect your peers. Even those that have been “in the game” for a shorter time then you have. We all have different levels of experience. Patience and respect goes a long way.
Change is constant. Standards are a living thing. We need to work as a team to develop a culture of quality.
Knowledge over position. Everybody has valuable insight. Let’s cultivate that and build a knowledge based development environment.
Don’t dig in too deep. Fight for what you believe. Be willing to accept ideas that are different then the ones you have now.
Don’t hide. Building a positive development environment takes participation. Share what you know. Ask questions. Participate.
Critique Code. Not people. Be kind to the coder, not the code.
What is a “good” review? Good reviews spread knowledge and provide a learning experience for everybody involved.
a conversation... Reviews should be a two way conversation between the author of the code and the participants of the review. Reviewers should ask questions of the author. The author should offer explanations and frame the context of the code being reviewed.
includes a summary... When a review is over it should be summarized. This will let all the participants know what action is being taken as a result of the review.
includes praise... If you see something you like, let the author know. It can be difficult to remember to do this, but it is important.
references standards. . Have a solid set of standard practices to reference. Remember that standards are a living thing. They are still open for discussion.
focus on the code.. Not the person that wrote it. Ego is something we all have, but should be kept out of reviews as much as possible.
not always actionable... Comments in a code review don’t necessarily require immediate action. Be clear about that. Is a comment a suggestion? A question?
is time-boxed... Code reviews work best on code that is fresh in the author’s mind. Respond to review requests promptly. Participate as much as possible and mark the review complete when you are done.
Being reviewed. It can be tough to be in the hot seat and have your code examined.
Add initial comments. As the author adding an initial pass of comments is extremely helpful to explain the code under review. Scope and context can be defined this way.
Decouple yourself... Take a step back and release your attachments to the work being reviewed. This is challenging. The initial instinct is to “bunker in” and defend the work.
Understand the standards. Work as closely to the defined standards as possible. When you need to deviate explain why in the initial comment pass.
Maintain the standards. Standards are living things. If you deviate and need to do something a different way open the discussion for improving the standards.
When to start a review? During active development while the code is fresh in your head is the best time to start a review. Peer review is not a task to save as until the end of development. Starting the conversation early helps ensure that it isn’t an afterthought. Problems are caught before they spin out of control.
Who starts a review? Generally the author. But sometimes it might be started by somebody else if a problem is noticed or if a commit isn’t under review and is on the large side.