Code review is recommended when code contains complex business logic, external API changes, or high risk of introducing bugs. It helps reduce bugs by having another developer review changes before merging. Effective code review involves over-the-shoulder reviews or pair programming to catch issues early, as well as unit and integration tests to prevent regressions.

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