Upgrade to Pro — share decks privately, control downloads, hide ads and more …

PyLady Berlin 2023: How to be a good reviewer? ...

PyLady Berlin 2023: How to be a good reviewer? - Be honest, nice and a badass

The first time I was asked to review a colleague's code, I was unsure: What was expected of me? What exactly was I supposed to check? And, most importantly, wouldn't I make myself unpopular by pointing out others' mistakes?
In my presentation, I will describe what I have learned since then. Using real examples, I’ll point out:
what you should look for when reviewing code (e.g. readability, redundancy, files & data), which tools you can use (e.g. gitlab runner, black, mypy) and how to stay friends while being brutally honest with each other :-)
By the way: The examples of code bugs are not only from my colleagues. After all, my own code is constantly reviewed and fixed by others. And yes, I admit, it hurts every single time…

Video: https://www.youtube.com/watch?v=jvQJHIXPTOc

Avatar for raanasn

raanasn

July 12, 2023
Tweet

More Decks by raanasn

Other Decks in Programming

Transcript

  1. B E H O N E S T , N

    I C E A N D A B A D A S S HOW TO BE A GOOD REVIEWER 

  2. H O W T O B E A G O

    O D R E V I E W E R HI HALLI HALLO! 2 Raana
  3. H O W T O B E A G O

    O D R E V I E W E R WHY THE HELL AM I DOING THIS? 3 … 2 years ago This is me … What is the expectation? What if I make mistakes?
  4. H O W T O B E A G O

    O D R E V I E W E R TODAYS AWESOME GOAL 4 Dealing with yourself Review Depth Interacting with others
  5. DEALING 
 WITH YOURSELF H O W T O B

    E A G O O D R E V I E W E R 5
  6. H O W T O B E A G O

    O D R E V I E W E R DEALING WITH YOURSELF: SITUATION 6 I don’t know this project … Deadline is near, I am too slow … This code is complex for me … What if I am wrong?
  7. H O W T O B E A G O

    O D R E V I E W E R DEALING WITH YOURSELF: SOLUTIONS 7 I don’t know this project … Deadline is near, I am too slow … This code is complex for me … What if I am wrong?
  8. H O W T O B E A G O

    O D R E V I E W E R DEALING WITH YOURSELF: REVIEW EXAMPLES 8 …
  9. REVIEW DEPTH H O W T O B E A

    G O O D R E V I E W E R 9
  10. H O W T O B E A G O

    O D R E V I E W E R REVIEW DEPTH 10 Code Structure Files & Data Readability Changes Testing
  11. H O W T O B E A G O

    O D R E V I E W E R REVIEW: CHANGES 11 Does the code still run? Is everything adjusted (also the tests)? If something is removed / renamed: is it changed everywhere? Were the changes recorded in the CHANGELOG / README ?
  12. H O W T O B E A G O

    O D R E V I E W E R REVIEW: TESTING 12 Do the tests still run? Is the code format fine? Is the code plausible? Does the code run automatically on another server? [mypy, flake8, black, Pylint, pre-commit, PEP 8] [pytest] [plausibility-checks] [GitLab CI/CD]
  13. H O W T O B E A G O

    O D R E V I E W E R REVIEW: CODE STRUCTURE 13 Is something repeated? Are functions too dependent? Is the code flexible for changes? Does the code follow an overall structure? [encapsulation, classes] [PyCharm] [hard-coded, other variables] [data, logic, server, …]
  14. H O W T O B E A G O

    O D R E V I E W E R REVIEW: READABILITY 14 Can I run the code only with the help of the readme? Are the namings self-explainatory? Is the code explained well? Are the access configurations given? [comments, doc-strings, typings, explicit calls] [functions, variables, folders] [be-a-dummy] [.env.sample]
  15. H O W T O B E A G O

    O D R E V I E W E R REVIEW: FILES & DATA 15 Are the necessary files pushed? Are the files too big? Is sensitive data pushed? Do we have files which shouldn’t be tracked? [.gitattributes, git-lfs] [.gitignore, .dockerignore] [password, personal-data, .env] [migrations, metrics, poetry.lock]
  16. H O W T O B E A G O

    O D R E V I E W E R REVIEW DEPTH 16 Code Structure Files & Data Readability Changes Testing
  17. INTERACTING WITH OTHERS H O W T O B E

    A G O O D R E V I E W E R 17
  18. H O W T O B E A G O

    O D R E V I E W E R INTERACTING WITH OTHERS 18 What to do, when others say: 
 „Dude, your code is bad“? How to tell others: 
 „Dude, your code is bad“? In general: 
 What helps?
  19. H O W T O B E A G O

    O D R E V I E W E R INTERACTING WITH OTHERS: 
 BE HONEST, NICE AND A BADASS 19 What to do, when others say: 
 „Dude, your code is bad“? How to tell others: 
 „Dude, your code is bad“? In general: 
 What helps? Criticism is fine Name positive things! Explain but don’t make changes Admit :) Say thank you Explain Ask for clarification You are here to help You are here for improvements
  20. H O W T O B E A G O

    O D R E V I E W E R INTERACTING WITH OTHERS: 
 BE HONEST NICE A BADASS 20
  21. H O W T O B E A G O

    O D R E V I E W E R INTERACTING WITH OTHERS: YOU ARE ONE TEAM 21
  22. READY TO REVIEW? H O W T O B E

    A G O O D R E V I E W E R 22
  23. H O W T O B E A G O

    O D R E V I E W E R WHAT TO TAKE OR NOT TO TAKE HOME 23 Your opinion 
 counts Reviewing has 
 many steps You are 
 one team
  24. H O W T O B E A G O

    O D R E V I E W E R AM I A GOOD THE BEST REVIEWER? 24
  25. H O W T O B E A G O

    O D R E V I E W E R Q&A WHAT DO YOU THINK? 25 Contact: 
 Raana Saheb-Nassagh 
 [email protected]