Decoding Code Review - Elixir Conf US

Lightning Talk

Transcript

1. DECODING CODE REVIEW ElixirConf US - 2023
2. ELAINE NAOMI WATANABE B.Sc. in Computer Engineering M.Sc. in Computer Science Senior Software Engineer @ TheRealReal twitter.com/elaine_nw speakerdeck.com/elainenaomi linkedin.com/in/elainenaomi slides
4. CODE REVIEW
6. 60% of defects can be identified in code review process Boehm, Barry, and Victor R. Basili. "Top 10 list [software development]." Computer 34.1 (2001): 135-137
8. Code review is a valuable tool for identifying code evolvability-related defects that are not detectable during the testing phase Mäntylä, Mika V., and Casper Lassenius. "What types of defects are really discovered in code reviews?." IEEE Transactions on Software Engineering 35.3 (2009): 430-448
9. http://agilemodeling.com/essays/modelReviews.htm Dev. Cost of Change Time Requirements Analysis and Design Review Tests Production
10. http://agilemodeling.com/essays/modelReviews.htm Dev. Cost of Change Time Requirements Analysis and Design Review Tests Production
11. As an Author
12. Self-descriptive title Motivation (Business Context) List previous questions and discussions GIFs, screenshots from the changes
13. Coherent commit messages Complete, tested code Small changes Single responsibility principle
14. Review your own PR Tag people as reviewers Apply necessary changes Respond to all comments
15. RubyConf 2018 - A Branch in Time https://www.youtube.com/watch?v=8OOTVxKDwe0 capture the why, not the what
16. As a Reviewer
17. Identify defects (bugs) Suggest alternatives, refactorings Reinforce patterns Validate functionality (code + business)
18. Identify security issues Analyze performance impact Suggest documentation Validate the code quality
19. Be introduced to new functionalities Learn new technologies Share knowledge and questions
20. #
21. Feedback is about the source code, not about people
22. Promote the participation of everyone in your team
24. Toxic behaviors in code review may not be so obvious…
25. Toxic behaviors in code review may not be so obvious… ask feedback
26. Toxic behaviors in code review may not be so obvious… read about Non-Violent Communication
27. "This PR should not be merged" Opinion-based comment, lacking concrete action, imperative
28. "Why haven't you created a new module?" A question with a judgmental tone "Why didn't you think of that?"
29. Code reviews like a Human https://mtlynch.io/human-code-reviews-1/ https://mtlynch.io/human-code-reviews-2/
30. it's about adding comments in a more constructive manner
31. "Why haven't you created a new module?" A question with a judgmental tone "Why didn't you think of that?"
32. constructive manner "What do you think about extracting this logic into a module? I think it will improve readability and reduce complexity"
33. no assumptions, just a suggestion "I don't know if you've already considered this, but wouldn't it be worth creating a new module for this case?"
34. Be mindful about unconscious bias
35. For example, about seniority bias
36. Don't assume that a junior engineer needs explanation for everything
37. And also, about gender bias
38. Please, don't try to explain what Elixir is to a female Elixir engineer
39. Pay attention for not assuming a female Elixir engineer is a junior engineer
40. #
43. https://sourcelevel.io/code-review-ebook
46. google.github.io/eng-practices/review/reviewer/standard.html
48. railsgirls.com.br
50. CARNIVAL EDITION
51. speakerdeck.com/elainenaomi elainenaomi.dev Muito obrigada illustrations from undraw.co translation: thank you so much! slides