3. What is code review?

4. When do you need to use code
review on your project?

5. Points that might be the reason:
 Too much boilerplate code (any changes are very
risky)
 External API need to be changed (just little bit)
 Too much too complex business logicrules
 Code smells (again? After it was just refactored)
 High load – only one simple line could f**k up all
system
 In each development iteration the number of bugs
is more then in previous one
 when the duck grunted

6. Bonus points
 Each developer want to refactor everything on his
own way
 When you fix one bug and you introduce N bugs
(where N >= 2)
 Only you can changefix your own code
 Too much shitty code

7. How to code review

8. Types
 Over-the-shoulder
 Email pass-around
 Pair programming
 Tool-assisted code review

9. Timeline
 TDD/unit test for critical functionality
 Automatic code analysis – common conventions
 Fish eye – tool similar to github functionality
 UI tests (for regression)
 Performance tests (not to f**k up on mass event)
 Over-the-shoulder code review + elements of pair
programming – this is really works