Code reviews
4 likes264 views
The document discusses code reviews, including what they are (formal vs lightweight reviews), why they are important (avoiding knowledge silos, early bug detection, improved code quality), how to conduct them (taking it easy, communicating clearly, following best practices), and the mindset needed (focus on code, not people, and be grateful). It emphasizes that code reviews can find up to 75% of defects and improve software evolvability.
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