Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Code Review Skills for Pythonistas - Nina Zakharenko - EuroPython

3,224 views

Published on

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.

Published in: Technology
  • You can now be your own boss and get yourself a very generous daily income. START FREE...♣♣♣ https://tinyurl.com/realmoneystreams2019
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Forget about surgery, pills and weights, they DONT work! This DOES work, but you need to follow the methods contained in the guide. Let's be honest, penis size is an important aspect of any man's life whether they want to admit it or not. The market is flooded with products and solutions that claim to have the answer to making your member bigger, but usually these products fail to deliver. Luckily, I happened to come across what might be the "Holy Grail of Penis Enlargement", it's written by this guy named John Collins and it's called the Penis Enlargement Bible. What I found mind blowing about John's program is that he backs up his claims with actual video proof and testimonials from customers who have used the product. It's said that a picture is worth a thousand words, but I would say most of these videos are worth 3 to 4 inches! Forget extenders, pills, suction devices and surgery. They are either expensive, too painful or they just don't work. The Penis Enlargement Bible is a proven two step program that combines natural over the counter supplements with a specially designed exercise regime to achieve up to 4" of growth within just a few months. If you are serious about getting bigger, check out the Penis Enlargement Bible here ➤➤ https://tinyurl.com/yaygh4xh
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • The methods and techniques in the PE Bible are exclusive to this unique program. The two step system involves low cost off the shelf natural supplements and a specially designed exercise program. Many users experience gains of almost an inch within just a few weeks of starting this unique program! Imagine having 2-4 inches of extra length and girth added onto your penis size, this Penis Enlargement Bible makes it possible. Over 5000 copies of this product have already been sold, and unlike most products on the market there is real video proof from actual users that show REAL results. You can see the video here ➤➤ https://tinyurl.com/ydaetwbk
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • I went from getting $3 surveys to $500 surveys every day!! learn more...  http://ishbv.com/surveys6/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Code Review Skills for Pythonistas - Nina Zakharenko - EuroPython

  1. 1. NINA ZAKHARENKO CODE REVIEW SKILLS FOR PYTHONISTAS @NNJA bit.ly/ pycodereviews
  2. 2. LIVETWEET USE #EUROPYTHON @NNJA
  3. 3. WHAT WE'LL LEARN TODAY [1/2] > What are the proven benefits of review? > Setting standards > Time saving tools and automation options for Python @nnja
  4. 4. WHAT WE'LL LEARN TODAY [2/2] > How to review code helpfully > How to submit PRs for maximum impact > Use code review to build a stronger team @nnja
  5. 5. WHAT WILL YOU TAKE AWAY FROM THIS TALK? > Novice - Comprehensive overview of code review best practices > Intermediate - Tooling & automation > Advanced - Hardest part – the people factor @nnja
  6. 6. NOT ONE SIZE FITS ALL! > team size > 2 vs 10 > product type > agency vs in-house vs open source @nnja
  7. 7. NOT ONE SIZE FITS ALL! > defect tolerance > jet engines vs mobile games @nnja
  8. 8. WHY CODE REVIEW? @nnja
  9. 9. CODE REVIEWS CAN BE FRUSTRATING @nnja
  10. 10. APPARENT CODE REVIEW FRUSTRATIONS > Adds time demand > Adds process > Can bring up team tensions > “smart” devs think they don’t need it ! @nnja
  11. 11. CODE REVIEW BENEFITS @nnja
  12. 12. FIND BUGS & DESIGN FLAWS > Design flaws & bugs can be identified and remedied before the code is complete > Case Studies on Review5 : > ➡ bug rate by 80% > productivity by 15% 5  blog.codinghorror.com/code-reviews-just-do-it/ @nnja
  13. 13. THE GOAL IS TO FIND BUGS BEFORE YOUR CUSTOMERS DO @nnja
  14. 14. SHARED OWNERSHIP & KNOWLEDGE > We’re in this together > No developer is the only expert @nnja
  15. 15. LOTTERY FACTOR New Yorker: Can Andy Byford Save the Subways?
  16. 16. CODE REVIEW BENEFITS? > Find Bugs > Shared Ownership > Shared Knowledge > Reduce "Lottery Factor" @nnja
  17. 17. HOW?@nnja
  18. 18. CONSISTENT CODE > Your code isn’t yours, it belongs to your company > Code should fit your company’s expectations and style (not your own) > Reviews should encourage consistency for code longevity @nnja
  19. 19. CODE REVIEWS NEED TO BE UNIVERSAL & FOLLOW GUIDELINES > Doesn’t matter how senior / junior you are > Only senior devs reviewing == bottleneck > Inequality breeds dissatisfaction @nnja
  20. 20. STYLE GUIDE > Distinguishes personal taste from opinion > Should be agreed upon beforehand > Go beyond PEP8 > See: Google's pyguide.md or plone styleguide @nnja
  21. 21. FORMATTERS - autopep8 - Black - YAPF
  22. 22. ! BLACK DEMO @: black.now.sh github.com/jpadilla/black-online
  23. 23. VS Code> settings: > "editor.formatOnSave": true > "python.formatting.provider": "black" > "python.formatting.blackArgs": ["--line- length", "100"] > VS Code Black support docs @nnja
  24. 24. CONSISTENT CODE IS EASIER TO MAINTAIN BY A TEAM @nnja
  25. 25. CODE REVIEW IS DONE BY YOUR PEERS & NOT MANAGEMENT @nnja
  26. 26. DON’T POINT FINGERS! @nnja
  27. 27. WHEN CODE REVIEWS ARE POSITIVE, DEVELOPERS DON’T EXPECT THEIR CHANGES TO BE REVIEWED, THEY WANT THEIR CHANGES TO BE REVIEWED. @nnja
  28. 28. LET'S REVIEW: CODE REVIEW FUNDAMENTALS > Universal code review > Performed by Peers > Style guides & formatters for consistency > No blame culture @nnja
  29. 29. HOW SHOULD WE CODE REVIEW? @nnja
  30. 30. BE A GREAT SUBMITTER @nnja
  31. 31. DON’T GET RUBBER-STAMPED. @nnja
  32. 32. DON’T BE CLEVER. READABILITY COUNTS! @nnja
  33. 33. GOOD CODE IS LIKE A GOOD JOKE. IT NEEDS NO EXPLANATION. - RUSS OLSEN @nnja
  34. 34. STAGES OF REVIEW > 0: before PR submission > 1: PR submitted > 2: (optional) work in progress PR (30-50%) > 3: review almost done (90-100%) > 4: review completed @nnja
  35. 35. STAGE 0:BEFORE SUBMISSION @nnja
  36. 36. 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 @nnja
  37. 37. YOU ARE THE PRIMARY REVIEWER > Review your code with the same level of detail you would give giving reviews. > Anticipate problem areas. @nnja
  38. 38. THE PRIMARY REVIEWER > Make sure your code works, and is thoroughly tested. > Don’t rely on others to catch your mistakes. @nnja
  39. 39. BEFORE SUBMITTING, TRY A CHECKLIST @nnja
  40. 40. ☑ SMALL STUFF> Did you check for reusable code or utility methods? > Did I remove debugger statements? > Are there clear commit messages? @nnja
  41. 41. ☑ BIG STUFF> Is my code secure? > Will it scale? > Is it maintainable? > Is it resilient against outages? Tip: Read The Checklist Manifesto @nnja
  42. 42. STAGE 1: SUBMITTED@nnja
  43. 43. YOU’RE STARTING A CONVERSATION > Don’t get too attached to your code before the review process > Anticipate comments and feedback > Acknowledge you will make mistakes @nnja
  44. 44. STAGE 2: (OPTIONAL) WORK IN PROGRESS@nnja
  45. 45. SUBMIT WORK IN PROGRESS PULL REQUESTS > Open them your code is 30-50% done > Good idea for bigger features > Don’t be afraid of showing incomplete, incremental work @nnja
  46. 46. WHEN CODE IS WORK IN PROGRESS > Feedback to expect: > Architectural issues > Problems with overall design > Design pattern suggestions @nnja
  47. 47. STAGE 3:ALMOST DONE@nnja
  48. 48. WHEN CODE IS ALMOST DONE > Feedback to expect: > Nit Picks > Variable Names > Documentation & Comments > Small Optimizations @nnja
  49. 49. ONE REVIEW PER PR > Solving multiple problems? Break them up into multiple PRs for ease of review. > Solved an unrelated problem? Make a new PR with a separate diff @nnja
  50. 50. 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 1  https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/ bosu2015useful.pdf @nnja
  51. 51. ✔ CHECK CODE WITH AUTOMATED TOOLS @nnja
  52. 52. ✔ LINTER @nnja
  53. 53. > Coding standard > Error detection > Refactoring help > IDE & editor integration @nnja
  54. 54. ! PYLINT RULE: trailing-comma-tuple foo = (1, 3, 4, ) bar = 2, @nnja
  55. 55. USE VULTURE.PY TO FIND DEAD OR UNREACHABLE CODE $ pip install vulture $ vulture script.py package/ or $ python -m vulture script.py package/ github.com/jendrikseipp/vulture
  56. 56. Sample code def foo(): print("foo") def bar(): print("bar") def baz(): print("baz") foo() bar() Run vulture.py › python -m vulture foo.py foo.py:7: unused function 'baz' (60% confidence) @nnja
  57. 57. GIT PRE-COMMIT HOOKS > run linter > check syntax > check for TODOs, debugger statements, unused imports > enforce styling (autopep8, black formatter, sort imports, etc) > option to reject commit if conditions don't pass @nnja
  58. 58. pre-commit.com @nnja
  59. 59. pre-commit.com > autopep8-wrapper - Runs autopep8 over source > flake8 and pyflakes - Run flake8 or pyflakes on source > check-ast - Check whether files contain valid python > debug-statements - Check for debugger imports and breakpoint() calls @nnja
  60. 60. ✔ TESTS> Write them! > Don’t know code health if tests are failing > Tests identify problems immediately @nnja
  61. 61. @nnja
  62. 62. ✔ CONTINUOUS INTEGRATION CPYTHON USES VSTS @nnja
  63. 63. ✔ coverage.py % OF CODE EXECUTED WHEN RUNNING A TEST SUITE @nnja
  64. 64. ✔ COVERAGE > Coverage tools integrate into GitHub > coverage.py > coveralls.io @nnja
  65. 65. STAGE 4:REVIEW COMPLETE @nnja
  66. 66. BE RESPONSIVE> Reply to every comment > Common Responses: > Resolved > Won’t Fix > If you won’t fix, make sure you’ve come to a mutual understanding with the reviewer @nnja
  67. 67. IT’S STILL A CONVERSATION If there were comments, let your reviewer know when you’ve pushed changes and are ready to be re- reviewed. @nnja
  68. 68. DON’T BIKE-SHED> bikeshed.com > back & forth > 3 times? step away from the keyboard > talk instead! > record the results of the conversation in the PR @nnja
  69. 69. VS CODE LIVE SHARE Download Extension
  70. 70. FIGHT FOR WHAT YOU BELIEVE, BUT GRACEFULLY ACCEPT DEFEAT. @nnja
  71. 71. DON’T TAKE FEEDBACK PERSONALLY. IT’S AN OPPORTUNITY FOR GROWTH. @nnja
  72. 72. HOW TO BE A GREAT SUBMITTER? > Provide the why (context!) > Review your own code > Expect conversation > Submit in progress work @nnja
  73. 73. HOW TO BE A GREAT SUBMITTER? > Use automated tools > Be responsive > Accept defeat @nnja
  74. 74. #1: BE A GREAT REVIEWER @nnja
  75. 75. @nnja
  76. 76. BE OBJECTIVE “THIS METHOD IS MISSING A DOCSTRING” INSTEAD OF “YOU FORGOT TO WRITE A DOCSTRING” @nnja
  77. 77. ASK QUESTIONS DON’T GIVE ANSWERS > “Would it make more sense if... ?” > “Did you think about... ? ” @nnja
  78. 78. OFFER SUGGESTIONS > “It might be easier to...” > “We tend to do it this way...” @nnja
  79. 79. AVOID THESE TERMS > Simply > Easily > Just > Obviously > Well, actually... @nnja
  80. 80. ... NOW, SIMPLY @nnja
  81. 81. HAVE CLEAR FEEDBACK > Strongly support your opinions > Share How & Why > Link to supporting documentation, blog post, or stackoverflow examples @nnja
  82. 82. THIS IS NOT CLEAR FEEDBACK @nnja
  83. 83. COMPLIMENT GOOD WORK AND GREAT IDEAS @nnja
  84. 84. DON'T BE A PERFECTIONIST @nnja
  85. 85. DON’T BE A PERFECTIONIST > For big issues, don’t let perfect get in the way of perfectly acceptable. > Prioritize what’s important to you. > Usually 90% there is good enough. @nnja
  86. 86. 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. @nnja
  87. 87. Don't burn out. Studies show reviewer should look at 200-400 lines of code at a time for maximum impact2 . 2  https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
  88. 88. Limit reviews to 400 lines in 60 mins to maximize effectiveness3 . 3  https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
  89. 89. TRY TO DO REVIEWS IN 24-48 HOURS
  90. 90. HOW CAN WE BE A GREAT REVIEWER? > Have Empathy > Watch your Language > Have Clear Feedback > Give Compliments @nnja
  91. 91. HOW CAN WE BE A GREAT REVIEWER? > Don’t be a perfectionist > Avoid Burn Out > Complete in 24-48 hours @nnja
  92. 92. CODE REVIEWS BUILD A STRONGER TEAM @nnja
  93. 93. FIRST DAY VIBES... @nnja
  94. 94. NEWBIES> Not everyone has experience being reviewed. > Remember what it felt like when you introduced the process. > Ease into it! @nnja
  95. 95. 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 @nnja
  96. 96. EVERYONE’S A REVIEWER > Junior devs start by doing pair- reviews with a more experienced teammate. > Use it as a mentorship opportunity. @nnja
  97. 97. HIRING SENIOR ENGINEERS IS HARD. YOU CAN HIRE JUNIOR ENGINEERS, AND GROW THEM INTO FUNCTIONAL PRODUCTIVE PARTS OF YOUR TEAM. - SASHA LAUNDY @nnja
  98. 98. IF YOU’RE NOT DOING CODE REVIEWS, YOU’RE MISSING A BIG OPPORTUNITY. @nnja
  99. 99. 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 maximum impact @nnja
  100. 100. I'VE BECOME A MUCH BETTER PROGRAMMER BY PARTICIPATING IN CODE REVIEWS @nnja
  101. 101. WHAT DID WE LEARN? @nnja
  102. 102. @nnja
  103. 103. REVIEWS DECREASE WTFS/M BY INCREASING CODE QUALITY LONG TERM @nnja
  104. 104. LESS WTFS ➡ HAPPIER DEVS! @nnja
  105. 105. THANKS! SLIDES: bit.ly/ pycodereviews aka.ms/python @nnja (Additional resources on next slides)
  106. 106. 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 @nnja
  107. 107. EXAMPLE STYLE GUIDES > Python > Plone Google has many good, but strict style guides at: https://github.com/google/styleguide Doesn't matter which one you use. Pick one and stick with it. @nnja

×