Code Review Skills for Pythonistas - Nina Zakharenko - EuroPython
Presented at EuroPython 2018
As teams and projects grow, code review becomes increasingly important to support the maintainability of complex codebases. In this talk, I’ll cover guidelines for writing consistent python code beyond pep8, how to look out for common python gotchas, and what python tools are available to automate various parts of the review process. Most importantly, I’ll cover the human aspect of code reviews - how we can be better at approaching reviews with empathy and understanding from the perspective of both a reviewer and a submitter. Following these successful code review practices will lead to happier teams and healthier code bases.
This talk is useful for python developers with any amount of experience. No prerequisite knowledge is necessary. - For those who are just starting out, it will be a great general overview. - Intermediate developers may not know about the wide variety of tooling that’s available. - Advanced developers will learn techniques for performing code reviews with empathy.
This talk will enable you to have better code reviews on your teams at work, and a better approach to code reviews in open source projects. You’ll leave with 3 main takeaways: 1. Code Reviews are most effective when conducted with empathy. If you do reviews with growth and learning in mind, they become tools for sharing knowledge instead of an opportunity to bruise egos or show off esoteric knowledge. 2. Python has powerful tooling available for code reviews such as pep8 as a style guide, pylint as a linter, coverage.py to identify test coverage, and vulture to identify dead code. 3. That python style guides beyond pep8 have clear benefits in terms of producing more consistent code that’s easier to review and easier to maintain.
FIND BUGS & DESIGN FLAWS
> Design flaws & bugs can be identified
and remedied before the code is
> Case Studies on Review5
> ➡ bug rate by 80%
> productivity by 15%
THE GOAL IS TO FIND
BUGS BEFORE YOUR
SHARED OWNERSHIP & KNOWLEDGE
> We’re in this together
> No developer is the only expert
New Yorker: Can Andy Byford Save the Subways?
> Your code isn’t yours, it belongs
to your company
> Code should fit your company’s
expectations and style (not your
> Reviews should encourage
consistency for code longevity
CODE REVIEWS NEED TO BE UNIVERSAL &
> Doesn’t matter how senior / junior
> Only senior devs reviewing ==
> Inequality breeds dissatisfaction
> Distinguishes personal taste from
> Should be agreed upon beforehand
> Go beyond PEP8
> See: Google's pyguide.md or plone
PROVIDE CONTEXT (THE WHY)
> What was the motivation for
submitting this code?
> Link to the underlying ticket/issue
> Document why the change was needed
> For larger PRs, provide a changelog
> Point out any side-effects
YOU ARE THE
> Review your code with the same level of
detail you would give giving reviews.
> Anticipate problem areas.
THE PRIMARY REVIEWER
> Make sure your code works, and is
> Don’t rely on others to catch your
WHEN CODE IS ALMOST DONE
> Feedback to expect:
> Nit Picks
> Variable Names
> Documentation & Comments
> Small Optimizations
ONE REVIEW PER PR
> Solving multiple problems? Break
them up into multiple PRs for ease
> Solved an unrelated problem? Make
a new PR with a separate diff
PREVENT REVIEWER BURNOUT
> Reviews lose value when they’re
more than 500 lines of code1
> Keep them small & relevant
> If a big PR is unavoidable, give
the reviewer extra time
DON’T BE A PERFECTIONIST
> For big issues, don’t let perfect
get in the way of perfectly
> Prioritize what’s important to
> Usually 90% there is good enough.
IT’S OK TO NIT-PICK
> Syntax Issues
> Spelling Errors
> Poor Variable Names
> Missing corner-cases
> Specify: Are your nitpicks blocking merge?
Save the nit-picks for last, after any pressing
architecture, design, or other large scale issues
have been addressed.
Don't burn out. Studies show reviewer should look at
200-400 lines of code at a time for maximum impact2
Limit reviews to 400 lines in 60 mins
to maximize effectiveness3
NEWBIES> Not everyone has experience being
> Remember what it felt like when
you introduced the process.
> Ease into it!
ONBOARDING> The first submitted PR is the hardest
> The first review done is challenging too
> Start by reading recently completed reviews
> First code review should be small
> Share the style guide
EVERYONE’S A REVIEWER
> Junior devs start by doing pair-
reviews with a more experienced
> Use it as a mentorship
HIRING SENIOR ENGINEERS IS HARD.
YOU CAN HIRE JUNIOR ENGINEERS,
AND GROW THEM
INTO FUNCTIONAL PRODUCTIVE PARTS OF
- SASHA LAUNDY
IF YOU’RE NOT DOING CODE REVIEWS,
YOU’RE MISSING A BIG OPPORTUNITY.
REMEMBER...> Allocate the time
> Develop, don’t force the process
> Not one size fits all
> Or a one stop fix
> Use in addition to tests, QA, etc for
I'VE BECOME A MUCH BETTER PROGRAMMER
BY PARTICIPATING IN CODE REVIEWS
(Additional resources on
RESOURCES & ADDITIONAL READING
> Microsoft Study on Effective Code Review
> Code Reviews: Just do it
> Code Project - Code Review Guidelines
> Great Example Checklist
> Best Practices for Code Review
> Rebecca's Rules for Constructive Code Review
> My Big Fat Scary Pull Request
> The Gentle Art of Patch Review - Sage Sharp
> Watch: Raymond Hettinger - Beyond PEP8
EXAMPLE STYLE GUIDES
Google has many good, but strict style guides
Doesn't matter which one you use.
Pick one and stick with it.