Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Code Review 101

Code Review 101

In the open source environment, any bug fix, new feature, or documentation goes over a review,
where the project maintainers has the opportunity to ask and suggest improvements before the
change get integrated into the project. This practice has many benefits that’s why many companies
incorporated this practice in their development flow.

In this talk, we’ll discuss:

* What’s code review and Pull/Merge requests
* Why use code reviews
* When you should ask for a code review
* Code Review vs Pair Programming
* Good and bad practices
* Code Review in development/deployment flow

After this talk, you’ll learn why code reviews are important and how to extract the best of this practice.

Ulisses Almeida

April 18, 2019
Tweet

More Decks by Ulisses Almeida

Other Decks in Programming

Transcript

  1. Code Review CODE REVIEW 101 What is it? Options Why

    Pull Requests? Pull requests good practices Go beyond with pull requests
  2. Bunch of folks reading code and suggesting changes W E

    L C O M E A B O A R D Improve code quality, prevent defects, share knowledge and responsibility, discover better solutions
  3. Continuous
 Integration =~
 not having a code review CODE REVIEW

    101 Don’t branch! Don’t branch! Commits on master everyday! Feature toggle to hide WIP Automated tests Automated deployment Continuous Integration 
 != Continuous Delivery
 != Continuous Deployment https://martinfowler.com/articles/continuousIntegration.html
  4. Pair programming, kinda code review CODE REVIEW 101 Driver and

    Navigator Constant feedback during the coding process Faster on-boarding Focus No personal space, can be exhausting Lack of feedbacks from third team members
  5. Code Review, Merge/Pull requests CODE REVIEW 101 Open collaboration Time-zone/remote

    friendly History of discussions Enforce code quality before mainline integration Wait for review can take a long time Written communication is hard
  6. First, automation always W E L C O M E

    A B O A R D Automated tests, deploys, rollbacks are important, no matter the process
  7. Continuous integration Pair programming Pull Requests Teammates early feedback 0

    ++ + Team Visibility - + ++ Team ownership - + ++ Individual space + - + Focus 0 ++ 0 Code Quality 0 + ++ Deploy confidence ++ + 0 ++ Strong promotes + Promotes 0 Neutral - Negates CODE REVIEW 101
  8. Small Concise, Focused CODE REVIEW 101 Few code to read

    leads to a better quality of the review Give lots of information with few words and image Efforts to one goal
  9. Concise PR,
 is about optimise the reviewer time CODE REVIEW

    101 Clear title Good description about you have done and why You can use screenshots and GIFs Add Issue Tracker links (JIRA for example) Add reviewers Review your own PR and highlight some parts
  10. A focused PR starts before coding CODE REVIEW 101 Breakdown

    your user stories Try to delivery a testable thing But don’t break too much otherwise your PR will be pointless Work with your team to check if the tasks/stories are clear
  11. CODE REVIEW 101 0 27,5 55 82,5 110 #1 #2

    #3 #4 Backlog Developing Review Testing Done
  12. 0 27,5 55 82,5 110 #1 #2 #3 #4 Backlog

    Developing Review Testing Done CODE REVIEW 101
  13. Big review times are symptoms W E L C O

    M E A B O A R D Removing pull requests might not cure the disease.
 
 Analyse the context:
 WIP? Big demands? Context switching?
  14. What we 
 should look 
 for? CODE REVIEW 101

    Is it solving the problem? Is there other ways? Typos, bugs, security, performance Need tests? Documentation? Following the team/project patterns?
  15. Try to be assertive,
 written communication is hard CODE REVIEW

    101 Avoid imperative sentences Suggestive tone Teach, show examples Don't assume, ask questions Compliments Celebrate! Have fun!
  16. The code is 
 not you and 
 not just

    
 for you CODE REVIEW 101 Appreciate the reviewer time Assertive communication Answer the suggestions, even those you will not apply Lots of comments doesn’t mean you are bad programmer Detach from your code, it’s ok sometimes rewrite everything
  17. There are people behind the screens W E L C

    O M E A B O A R D Go beyond the tool.
 Face-to-face, video calls…
 
 Don’t forget to register the decision in PR later
  18. Go crazy, and deploy the PR in production! CODE REVIEW

    101 https://guides.github.com/introduction/flow/