Welcome Practical pointers for better code review
Introduction ● About me: Python dev at Four Digits – Web stuff – Python, Django, Wagtail CMS, React ● Slides will be linked from Twitter @keeshink
Code review goals ● Find bugs ● Check if it solves the problem ● Check maintainability ● Share knowledge / onboard people
More goals ● Discuss alternative approaches ● Make less experienced developers learn ● Link to documentation and other sources ● Avoid unwanted new dependencies on external packages ● Check team members’ understanding ● Recognize when (end user) documentation needs update ● Record reasons for code changes ● Recognize when external parties need to be informed
Goal: Check if it solves the problem ● Ask until problem is entirely clear ● Ask until proposed solution is clear
Example: Problem+solution unclear ● Customer: “When I try logging in with my username in CAPITALS, I get this message in red: ● Developer: OK
Goal: Share knowledge, onboard people ● Ask a “control question” ● Ask questions instead of suggesting changes ● Also comment on what is good in the MR ● As submitter: Put in a TBD, ask for suggestions ● Have agreements / rules for MRs
Goal: Maintainability (1) ● Pretend it’s yours from now on ● Ask until code is clear to you ● Split large MR into small ones ● Review one commit at a time
Goal: Maintainability (2) ● Actively look for similar code elsewhere in the project ● Consider the name of each class / method / variable / file ● Follow the code across referenced methods ● Check dependencies’ repo: #devs, last release, open issues
Example: Code unclear
Goal: Find bugs (1) ● There is no recipe ● Discuss the “interface”
Goal: Find bugs (2: read tests) ● If A B, also test !A !B → → ● Run test without fix (should fail) ● Test with edge case inputs
Know the kind of review to do ● Know your project ● Know the timeline ● Know yourself
Thank you ● Thank you for being here ● Thanks to my colleagues for their MRs... ● ...and for reviewing mine!

Practical pointers for better code review

  • 1.
  • 2.
    Introduction ● About me:Python dev at Four Digits – Web stuff – Python, Django, Wagtail CMS, React ● Slides will be linked from Twitter @keeshink
  • 3.
    Code review goals ●Find bugs ● Check if it solves the problem ● Check maintainability ● Share knowledge / onboard people
  • 4.
    More goals ● Discussalternative approaches ● Make less experienced developers learn ● Link to documentation and other sources ● Avoid unwanted new dependencies on external packages ● Check team members’ understanding ● Recognize when (end user) documentation needs update ● Record reasons for code changes ● Recognize when external parties need to be informed
  • 5.
    Goal: Check ifit solves the problem ● Ask until problem is entirely clear ● Ask until proposed solution is clear
  • 6.
    Example: Problem+solution unclear ● Customer:“When I try logging in with my username in CAPITALS, I get this message in red: ● Developer: OK
  • 7.
    Goal: Share knowledge,onboard people ● Ask a “control question” ● Ask questions instead of suggesting changes ● Also comment on what is good in the MR ● As submitter: Put in a TBD, ask for suggestions ● Have agreements / rules for MRs
  • 8.
    Goal: Maintainability (1) ●Pretend it’s yours from now on ● Ask until code is clear to you ● Split large MR into small ones ● Review one commit at a time
  • 9.
    Goal: Maintainability (2) ●Actively look for similar code elsewhere in the project ● Consider the name of each class / method / variable / file ● Follow the code across referenced methods ● Check dependencies’ repo: #devs, last release, open issues
  • 10.
  • 11.
    Goal: Find bugs(1) ● There is no recipe ● Discuss the “interface”
  • 12.
    Goal: Find bugs(2: read tests) ● If A B, also test !A !B → → ● Run test without fix (should fail) ● Test with edge case inputs
  • 13.
    Know the kindof review to do ● Know your project ● Know the timeline ● Know yourself
  • 14.
    Thank you ● Thankyou for being here ● Thanks to my colleagues for their MRs... ● ...and for reviewing mine!