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.

1. Code Review at large
scale
Mikalai Alimenkou
http://xpinjection.com
@xpinjection

5. Any fool can write code that a
computer can understand

6. Any fool can write code
that a computer can
understandProfessional developer write code
that humans can understand

7. 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

8. This goals are hard to
achieve at scale

9. Everything is simple in ideal team
… but reality
is different
… like this

10. Complexity brings more pain…

11. Optimist-style development

12. Before or after check-in?

13. 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?

14. 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

15. Use static code analysis

16. Internal team review
1.Pair programming
2.Check business logic
3.Early feedback

17. Cross-team review
1.Check architectural agreements
2.Collective code ownership
3.Share best practices

18. Definitely tool is needed

19. Developers with +2 authority

20. Track reviewers
• Not for blame
• Easy to find
person who also
knows the code
• More
responsibility for
reviewer

21. 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?

22. Metrics-based improvements

23. What if
something
just goes
wrong?

24. Incident management team

25. Collaboration within the
code is critical at scale

26. @xpinjection
http://xpinjection.com
mikalai.alimenkou@xpinjection.com