Code Review of Senior Python Engineers

Through various practical experiences and case studies, this talk aims to share with professional software engineers the output and expectations of "seniority" in code submission (pull-request) and code review at each stage of software development.

Specifically, it covers: 1. Key points of writing and reviewing Python code. 2. Related environment, tools, and methods.

In the summary, the talk will also move from the perspective of a senior engineer's Python code review to the communication, learning, sharing, and recruitment within an organization. Enough time will be assured for Q&A by best effort.

Transcript

1. OF SENIOR ENGINEERS CODE REVIEW PYTHON Keith Yang
2. Agenda Six Key Points of Senior Python Code Review Supportive Environment and Tools around Pull-Request 1. 2. 2023 talk in PyCon TW
3. Anti-Agenda How-to Details Find A Good Job 👁️ 👀 👁️‍🗨️ 🔎 🔍 🔦 1. 2.
4. Been there reviewed that? You've got a review
5. Pull-Request (PR) > A pull request is a method used in collaborative coding projects to propose code changes. > It allows developer to request code review, and then merge those changes into the main code repository once approved.
6. Keith Yang Lead Backend Engineer in iCHEF Taipei.py co-founder and co-organizer PyCon APAC 2015 Chairperson Lead Backend Engineer in iCHEF Taipei.py co-founder and co-organizer PyCon APAC 2015 Chairperson
9. 6 Key Points of Senior Python Code Review Agenda 1
10. 6 Key Points of Senior Python Code Review Agenda 1 9,999 From Years of Practice
11. Code Review
12. Quality Assurance Knowledge Sharing Finding and Fixing Bugs Early Code Review
13. ... to submit a change to the kernel, ... can be daunting ... if not familiar with "the system" - Submitting patches guide (Linux kernel) git send-email
16. #Comment Code Readibilirty Make code easy to be understood If it's tricky, write comments to help understanding 1st key point
17. GUESSING GUESSING PURPOSE PURPOSE
18. #Comment Example 1
20. #Comment Example 1
21. #Comment Example 2
22. Concise Code Descriptive for Human Purpose instead of Function 2nd key point
23. Code Example
24. Naming Descriptive for Human Purpose instead of Function Uniqueness v.s. Common easy to understand 3rd key point
25. Uniqueness "user" in users.py "member" in members.py "user" in crm.py "member" in crm.py Easiest to find and reason? a. b. c. d.
26. Uniqueness "user" in users.py "member" in members.py "user" in crm.py "member" in crm.py Easiest to find and reason? a. b. c. d. Tool: ripgrep
27. EXAMPLE Naming in member_logic.py, not member_utils.py
28. Code & Infra Readability Make code and module easy to understand If it's tricky, write comments and doc to help understanding
29. The Zen of Python The Zen of Python
30. python3 -m this The Zen of Python
31. Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! The Zen of Python, by Tim Peters python3 -m this
32. Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. CODE CODE NAMING NAMING COMMENT COMMENT
33. CODE NAMING COMMENT Readability counts. ...easy to explain, it may be a good idea Namespaces are one honking great idea
34. 6 Key Points of Senior Python Code Review, Part II
35. Unused Code Linting Tools: ruff, flake8, pylint Avoid writing unused: variables imports functions classes 4th key point
36. EXAMPLE Unused Code
37. Check Unused EXAMPLE by pre-commit
38. Senior Wrote Knew Common Python Errors Defaults for function arguments Modifying a list while iterating over it Lambda in for loop? MISTAKES 5th key point
39. Been there Done that 🥲
40. Lambda Code EXAMPLE in ITERRATION Expecting [0, 1, 2, 3, 4]?
41. PEP8 Read the doc? Tools black, isort flake8, ruff pre-commit 6th key point
42. PEP8 Check Real-time in Vim EXAMPLE
43. Type Hint Does Python need type hint? extra key point
44. Type Hint But it can be used to find mistakes early Small Projects v.s. Large Enterprise Projects No. extra key point
45. Supportive Environment and Tools around Pull-Request Agenda 2
46. “One essential characteristic of modern life is that we all depend on systems” -- The Checklist Manifesto: How to Get Things Right by Atul Gawande
47. Why to and why not Commit Message Pull-Request Description Document File Documentation Documentation Complete the Code Review
48. Purposes and Reasons Implement Plan Do This B efore Coding Design Review Design Review Complete the Code Review
49. Template Rocks 🤘 Design Review From Years of Practice
50. Operation Review Scop User Stories Security Review Inspirations Success Criteria B Plan (if not working) Designs (API, Model, DB) Performance Review Alternatives Considered Template Example & Tips
51. SRE Design Review Template Pull-Request Template Project Time Evaluation Template ... Template Everywhere Template Everywhere
52. Document Tool Exmaple Document Tool Exmaple .TXT, .md, .rst Notion, Amplenote, ... Notion, Google Doc, CryptPad, ... Figma, Archi, ...
53. CI / CD Continuous Integration Continuous Deployment Code ⬇️ Build ⬇️ Test --- ⬇️--- Staging ⬇️ Production
54. CI / CD Replace Painful Routines Reduced Manual Errors Rollbacks and Recovery
55. CI in Pull-Request
56. CI / CD Tool Example CI/CD pipelines Jenkins GitHub Actions PipeRider.io (data, dbt) pre-commit flake8, ruff, black, isort
57. "Spot issues before they emerge" ~ PipeRider ( instead of 　　　　　　　 Hotfix on Production )
58. Code Coverage Untested Code Collaboration Surprising Errors
59. Code Coverage Tool Example pytest-cov ( coverage.py) Codecov (by Sentry) SonarQube (SonarCloud)
60. Code Coverage checked in Pull-Request
61. The Zen of Python The Zen of Python
62. Errors should never pass silently Unless explicitly silenced Special cases aren't special enough to break the rules DOCUMENT DOCUMENT TEMPLATE TEMPLATE CI / CD COVERAGE CI / CD COVERAGE
63. Errors should never pass silently Unless explicitly silenced Special cases aren't special enough to break the rules DOCUMENT DOCUMENT TEMPLATE TEMPLATE CI / CD COVERAGE CI / CD COVERAGE TYPE HINT TYPE HINT
64. DOCUMENT TEMPLATE CI / CD There should be one -- and preferably only one -- obvious way to do it. TYPE HINT
65. AI Tools GPT4 ChatGPT Bard Claude GitHub Copilot
66. AI Tools Prompt vs real experienced Domain Knowledge Identify what's right and wrong with official doc Experiment tools and grow with your team
67. Mentorship Design Review Weekly Meeting Sharing Fun and Pain Teamwork
68. Internet AI Books, Podcast, Video ( O'Reilly Learning) Communities & (Py)Cons Different Languages & Design Paradigms & Pitfalls def Learning(self) Taiwan /APAC
69. Search on Internet Reference vs Pragmatic Mentor & Boss Interview & Culture Care Framework Care Framework Ladder: Your Mileage May Vary
70. Summary From Comment to Naming: Explicit Common Errors Supportive Environment with Tools: Find Errors at Very First Place Design Template CI/CD, AI, Soft Skills Senior: More Helpful
71. OF SENIOR ENGINEERS CODE REVIEW PYTHON @keitheis @mstdn.io 𝕏 discord @keitheis @mstdn.io 𝕏 discord Keith Yang