Presentation on code reviews.

1. CODE REVIEWS

2. CODE REVIEWS
WHOAMI
▸ Raúl Araya
▸ Currently Backend Lead Engineer @ brokergenius
▸ @nubeiro
▸ github.com/nubeiro
▸ Doing PHP since 1998

3. CODE REVIEWS
WHAT WE WILL COVER
▸ What is a code review?
▸ What a code review is not
▸ Why code reviews?
▸ How to create a code review?
▸ How do I review code?
▸ Code review — It´s a mindset

4. CODE REVIEWS
WHAT IS A CODE REVIEW? - FORMAL CODE REVIEWS
▸ Developers attend a series of meetings and review code line
by line, usually using printed copies of the material. Formal
inspections are extremely thorough and have been proven
effective at finding defects in the code under review.

5. CODE REVIEWS
WHAT IS A CODE REVIEW? - LIGHTWEIGHT CODE REVIEW
▸ Over-the-shoulder: one developer looks over the author's
shoulder as the latter walks through the code.
▸ Email pass-around: source code management system emails
code to reviewers automatically after checkin is made.
▸ Pair programming: two authors develop code together at the
same workstation, as it is common in Extreme Programming.
▸ Tool-assisted code review: authors and reviewers use
software tools, informal ones such as pastebins and IRC, or
specialized tools designed for peer code review.

6. CODE REVIEWS
WHAT IS A CODE REVIEW? - LIGHTWEIGHT CODE REVIEW
▸ Study shows that lightweight reviews uncovered as many
bugs as formal reviews, but were faster and more cost-
effective.

7. CODE REVIEWS
WHAT IT IS NOT
▸ A personal evaluation.
▸ A review on your performance
▸ an excuse to leave unfinished work (why complete
everything if somebody else will tell me during the review).
▸ QA. Code reviews might uncover bugs, but it is not a
replacement for QA.

8. CODE REVIEWS
WHY? A QUICK EXAMPLE
▸ Do not read the words, just say out loud the colours

9. CODE REVIEWS
WHY?
▸ Avoiding knowledge silos: a code review is an opportunity to
acquire knowledge on somebody else's work.
▸ Spot bugs early: Even before merging to develop or master
branch.
▸ Improves code quality: Brings up discussions over design,
performance and maintainability.
▸ Improves the team: Both reviewer and developer roles
benefit from interaction, learning from each other.

10. CODE REVIEWS
WHY?
▸ Industry data indicates that code reviews can accomplish at
most an 85% defect removal rate with an average rate of
about 65%.
▸ Empirical studies provided evidence that up to 75% of code
review defects affect software evolvability rather than
functionality, making code reviews an excellent tool for
software companies with long product or system life cycles.

11. CODE REVIEWS
HOW DO I CREATE A REVIEW?
▸ Make sure requirements are clear
▸ Make sure you have a proper branching model: git flow with feature
branches, PR with stable master branch, etc.
▸ Make sure you provide automated tests (unit, integration, acceptance, end
to end).
▸ Before you push your changes, consider squashing to a meaningful commit.
▸ Before you push your changes, make sure all tests pass green.
▸ Once pushed, provide as much information as possible: link to original
ticket or reference to issue being fixed is mandatory.

12. CODE REVIEWS
HOW DO I REVIEW?
▸ Take it easy (400 LOC at a time). The brain can only effectively process
so much information at a time; beyond 400 LOC, the ability to find
defects diminishes.
▸ Take your time (less than 500 per hour), research shows a significant
drop in defect density at rates faster than 500 LOC per hour.
▸ Make it short (no longer than 1 hour), performance starts dropping off
after about 60 minutes. Take a break if needed.
▸ Get to know the context, read the requirements for the ticket being
solved.
▸ Communicate which ideas you feel strongly about and those you don't.

13. CODE REVIEWS
HOW DO I REVIEW?
▸ Identify ways to simplify the code while still solving the problem.
▸ If discussions turn too philosophical or academic, move the
discussion offline to a regular Friday afternoon technique discussion.
▸ In the meantime, let the author make the final decision on alternative
implementations.
▸ Offer alternative implementations, but assume the author already
considered them. ("What do you think about using a custom
validator here?")
▸ Seek to understand the author's perspective.

14. CODE REVIEWS
TOOLS THAT HELP
▸ Diff all the things!
▸ At PR level Github, Gitlab
▸ From your IDE (i.e. PHPStorm)
▸ Code review tools: Phabricator, Crucible, UpSource
▸ Setup CI

15. CODE REVIEWS
TOOLS THAT HELP: DIY FIRST, THEN AUTOMATE
▸ Run all automated tests (unit, integration, functional,
acceptance)
▸ Run static tools: (lint, code style checks, mess detector)
▸ Use your IDE: (i.e. setup PHPStorm inspections)
▸ Use multi branches pipelines (so that the branch also gets a
build)
▸ Actually check CI result!

16. CODE REVIEWS
HOW DO I REVIEW? - RUN CI ON BRANCHES
▸ Make sure everyone knows what goes on in CI
▸ Use multi branch builds (so that the branch also gets a build)
▸ Actually check CI result!

17. CODE REVIEWS
HOW DO I REVIEW? - A CHECKLIST
▸ Are there any obvious logic errors in the code?
▸ Are all requirements implemented?
▸ Are automated tests provided?
▸ Do all automated tests pass?
▸ Check code coverage.
▸ Check coding standards.
▸ Check static code analysis metrics.
▸ Are there obvious violations of SOLID principles?

18. CODE REVIEWS
HOW DO I REVIEW? - SINGLE RESPONSIBILITY
A CLASS SHOULD HAVE ONLY A
SINGLE RESPONSIBILITY

19. CODE REVIEWS
HOW DO I REVIEW? - OPEN/CLOSED
SOFTWARE ENTITIES …
SHOULD BE OPEN FOR
EXTENSION, BUT CLOSED FOR
MODIFICATION.
SOLID (Wikipedia)

20. CODE REVIEWS
HOW DO I REVIEW? - LISKOV SUBSTITUTION
OBJECTS IN A PROGRAM SHOULD BE
REPLACEABLE WITH INSTANCES OF
THEIR SUBTYPES WITHOUT
ALTERING THE CORRECTNESS OF
THAT PROGRAM.
SOLID (Wikipedia)

21. CODE REVIEWS
HOW DO I REVIEW? - INTERFACE SEGREGATION
MANY CLIENT-SPECIFIC
INTERFACES ARE BETTER THAN
ONE GENERAL-PURPOSE
INTERFACE
SOLID (Wikipedia)

22. CODE REVIEWS
HOW DO I REVIEW? - DEPENDENCY INVERSION
ONE SHOULD “DEPEND UPON
ABSTRACTIONS, NOT
CONCRETIONS.”
SOLID (Wikipedia)

23. CODE REVIEWS
HOW DO I REVIEW? - CODE SMELLS
"A CODE SMELL IS A SURFACE
INDICATION THAT USUALLY
CORRESPONDS TO A DEEPER
PROBLEM IN THE SYSTEM”
Martin Fowler

24. CODE REVIEWS
HOW DO I REVIEW? - CODE SMELLS
▸ Long method / Long class (God objects, Utils, Helpers and
such)
▸ Feature envy
▸ Inappropriate intimacy
▸ Cyclomatic complexity
▸ Too many parameters

25. CODE REVIEWS
HOW DO I REVIEW? - ANTI PATTERNS
‣ Big Ball of Mud
‣ Anemic Domain Models
‣ Lassagna code
‣ Magic numbers / strings
‣ Spaghetti code

26. CODE REVIEWS
THE MINDSET (EVERYONE)
▸ Accept that many programming decisions are opinions. Discuss tradeoffs,
which you prefer, and reach a resolution quickly.
▸ Ask questions; don't make demands. ("What do you think about naming
this :user_id?")
▸ Ask for clarification. ("I didn't understand. Can you clarify?")
▸ Avoid selective ownership of code. ("mine", "not mine", “yours")
▸ Avoid using terms that could be seen as referring to personal traits ("dumb",
"stupid"). Assume everyone is attractive, intelligent, and well-meaning
▸ Be explicit. Remember people don't always understand your intentions
online.

27. CODE REVIEWS
THE MINDSET (EVERYONE)
▸ Be humble. ("I'm not sure - let's look it up.”)
▸ Don't use hyperbole. ("always", "never", “endlessly", "nothing")
▸ Don't use sarcasm.
▸ Keep it real. If emoji, animated gifs, or humor aren't you, don't
force them. If they are, use them with aplomb
▸ Talk synchronously (e.g. chat, screen-sharing, in person) if there are
too many "I didn't understand" or “Alternative solution:"
comments. Post a follow-up comment summarising the discussion.

28. CODE REVIEWS
THE MINDSET (AS A REVIEWER)
▸ Be grateful: you get an opportunity to learn from someone
else.
▸ Be grateful: someone is trusting your criteria.
▸ Focus on the code (not the person or how well you think of
that person).

29. CODE REVIEWS
THE MINDSET (AS AUTHOR OF CHANGES)
▸ Be grateful: someone wants to learn from you.
▸ Be grateful for the reviewer's suggestions. ("Good call. I’ll
make that change.")
▸ Focus on suggestions being made (not the person or how
well you think of that person). i.e. Don't take it personally.

30. CODE REVIEWS
THE MINDSET (AS AUTHOR OF CHANGES)
▸ Explain why the code exists. ("It's like that because of these reasons.
Would it be more clear if I rename this class/file/method/variable?")
▸ Extract some changes and refactors into future tickets/stories.
▸ When suggested to make changes, seek to fully understand the
reasons behind those suggestions.
▸ If provided alternative solutions: explore them, maybe even provide
automated tests for the new solutions so that they can be discussed
▸ Try to respond to every comment

31. CODE REVIEWS
REFERENCES
▸ Why code reviews matter (and actually save time!)
▸ Code review on wikipedia
▸ Code review on thoughtbot´s github
▸ The Importance of Code Reviews
▸ Best Practices for Code Review
▸ SOLID the first five OOD principles
▸ SOLID (Wikipedia)
▸ Common Code Smells on Wikipedia