Effective Peer Review

  • View

  • Download

Embed Size (px)


Code reviews don't have to suck.


  • 1. Effective peer review.an ongoing conversation.

2. 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. 3. Who are reviews for?Developers.So that we can learn from one another. 4. 10 Commandmentsof 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.Dont rewrite code without consultation.Treat people who know less than you with respect, deference and patienceThe 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.Dont be the guy in the room.Critique code instead of people. Be kind to the coder, not the code. 5. We all make mistakes.The important thing is to catch them as early aspossible.Luckily our mistakes arent life threatening. We can fix them, move onand laugh about it. 6. You are not your code.The point of reviews is to find problems early,educate and learn.Dont take it personally. 7. Always room to learn.We are all smart capable developers.Lets learn from one another. 8. Ask why.Dont just assume that something is wrong.Ask questions. Inquire about why something was done in a particularway. It might be the way it is for a valid reason. 9. Respect your peers.Even those that have been in the game for ashorter time then you have.We all have different levels of experience. Patience and respect goes along way. 10. Change is constant.Standards are a living thing.We need to work as a team to develop a culture of quality. 11. Knowledge over position.Everybody has valuable insight.Lets cultivate that and build a knowledge based developmentenvironment. 12. Dont dig in too deep.Fight for what you believe.Be willing to accept ideas that are different then the ones you have now. 13. Dont hide.Building a positive development environmenttakes participation.Share what you know. Ask questions. Participate. 14. Critique Code.Not people.Be kind to the coder, not the code. 15. What is a good review?Good reviews spread knowledge and provide alearning experience for everybody involved. 16. a conversation...Reviews should be a two way conversationbetween the author of the code and theparticipants of the review.Reviewers should ask questions of the author. The author should offerexplanations and frame the context of the code being reviewed. 17. 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 aresult of the review. 18. includes praise...If you see something you like, let the authorknow.It can be difficult to remember to do this, but it is important. 19. references standards...Have a solid set of standard practices toreference.Remember that standards are a living thing. They are still open fordiscussion. 20. focus on the code...Not the person that wrote it.Ego is something we all have, but should be kept out of reviews as muchas possible. 21. not always actionable...Comments in a code review dont necessarilyrequire immediate action.Be clear about that. Is a comment a suggestion? A question? 22. is time-boxed...Code reviews work best on code that is fresh inthe authors mind.Respond to review requests promptly. Participate as much as possibleand mark the review complete when you are done. 23. Being reviewed.It can be tough to be in the hot seat and haveyour code examined. 24. Add initial comments.As the author adding an initial pass ofcomments is extremely helpful to explain thecode under review.Scope and context can be defined this way. 25. Decouple yourself...Take a step back and release your attachmentsto the work being reviewed.This is challenging. The initial instinct is to bunker in and defend thework. 26. Understand the standards.Work as closely to the defined standards aspossible.When you need to deviate explain why in the initial comment pass. 27. Maintain the standards.Standards are living things.If you deviate and need to do something a different way open thediscussion for improving the standards. 28. When to start a review?During active development while the code isfresh in your head is the best time to start areview.Peer review is not a task to save as until the end of development. Startingthe conversation early helps ensure that it isnt an afterthought. Problemsare caught before they spin out of control. 29. Who starts a review?Generally the author.But sometimes it might be started by somebody else if a problem isnoticed or if a commit isnt under review and is on the large side.