Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Code review at large scale

864 views

Published on

When you work in a small collocated team many engineering practices and approaches are relatively easy to use and adapt. In large project with many teams working on the same product this task is not so simple. I want to share experience report in implementing Code Review practice in big product development team (more than 150 people, 10+ feature teams). In this talk we will review what approaches works in such setup and what don’t work, what tools and additional practices are needed to support Code Review and make it more effective, what difficulties and blockers will you probably see in the real life cases, what useful metrics could be produced by this practice.

Published in: Software
  • Be the first to comment

Code review at large scale

  1. 1. Code Review at large scale Mikalai Alimenkou http://xpinjection.com @xpinjection
  2. 2. Any fool can write code that a computer can understand
  3. 3. Any fool can write code that a computer can understandProfessional developer write code that humans can understand
  4. 4. Goals of code review  Improve quality of code  Share knowledge  Improve collective code ownership  Check conformance  Verify completeness  Educate  Reach a consensus  Try other approaches
  5. 5. This goals are hard to achieve at scale
  6. 6. Everything is simple in ideal team … but reality is different … like this
  7. 7. Complexity brings more pain…
  8. 8. Optimist-style development
  9. 9. Before or after check-in?
  10. 10. It is all about quality gates Has error handling code been tested? Are objects accessed by multiple threads thread-safe? Are variables initialized before they are used?
  11. 11. Full feedback cycle for MR 1.Pre-commit quality gates (static code analysis + quick tests) 2.Internal review within a team 3.Cross-team review 4.MR approval
  12. 12. Use static code analysis
  13. 13. Internal team review 1.Pair programming 2.Check business logic 3.Early feedback
  14. 14. Cross-team review 1.Check architectural agreements 2.Collective code ownership 3.Share best practices
  15. 15. Definitely tool is needed
  16. 16. Developers with +2 authority
  17. 17. Track reviewers • Not for blame • Easy to find person who also knows the code • More responsibility for reviewer
  18. 18. Checklist – make your live easier Has error handling code been tested? Are objects accessed by multiple threads thread-safe? Are variables initialized before they are used?
  19. 19. Metrics-based improvements
  20. 20. What if something just goes wrong?
  21. 21. Incident management team
  22. 22. Collaboration within the code is critical at scale
  23. 23. @xpinjection http://xpinjection.com mikalai.alimenkou@xpinjection.com

×