Downloaded 13 times
Uploaded byJane Prusakova
Effective Code Review
Effective code review focuses on collaboration and shared criteria rather than competition. Key components include readability, maintainability, architecture, and test coverage, alongside constructive feedback and continuous learning. It is a community effort that aims for technical quality through preparation, conversation, and iterative improvement, rather than simply being a procedural check.
More Related Content
Similar to Effective Code Review
More from Jane Prusakova
Effective Code Review
- 1.
- 3.
- 6. Judge a coderby the code? Cooperation, not competition Attention is respect Everyone is a reviewer
- 9. Size matters • Consistentcriteria • Maintain focus • Be agile • Limit scope • Limit time
- 10. Bucket list Visual layout Naming Architecture Testcoverage • Is it readable*? • Is it good maintainable code? • Does it do what it appears to do?
- 11. Skip Explanations what thecode does Checks by automated tools Reasons why this code is bad Arguments about preferences*
- 12. Code review isNOT A substitute for the QA A check on automated tools results A discussion on formatting, tools, or patterns
- 13. All code mustbe perfect? It depends
- 14. Goals of codereview Immediate benefit Medium to longer-term improvements Building technical community
- 15. Good Code Worthy ofa compliment Bugs Unintended behavior Bad Code Bugs coming soon Erratic code Hard to understand Common Vision -ilities Dependencies Poor scalability
- 16. Code review isnot a meeting 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 Preparation Conversation Follow up Author Reviewer(s)
- 17. Code review isnot a meeting 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 Preparation Conversation Follow up Author Reviewer(s)
- 18. Author Verify test coverage Runcode quality tools Fix problems Reviewer Be prepared Learn requirements Read the code Read the tests
- 19. What is readablecode? Defined by technology community Common knowledge Expected tenure Popular tools
- 20. Readability Short code blocks Minimizenestedness WYSIWYG
- 21. Show logic One decisionper code block Visible assumptions D.R.Y. Test every scenario exactly once
- 22. Naming Make sense Accepted terminology Abbreviations As short as possible but not any shorter Easy to distinguish String result, response, received; Integer value, values; MainClassHelper aHlpr; SituationUtils utils; PersonalDetails personsDetails; PersonalsDetails adCollectionDetails;
- 23.
- 24.
- 25.
- 26. Architecture technical details Standard practices Consistentpatterns Reflects requirements Builds on prior knowledge
- 27. Tests All scenarios covered Norepetitive tests Robust test structure
- 28.
- 29. Follow up Review therecommendations Make changes Apply learning Write more code Prepare for the next code review
- 30. It is OK Challengethe advice Do more research Ask for clarification
- 31. Technical Quality Takes time Takesa community Takes iterations Write code Prepare for code review Code review Follow up
- 32. Bugs Unintended behavior Bad Code Bugs coming soon Erratic code Hard to understand CommonVision -ilities Dependencies Poor scalability Good Code Worthy of a compliment
- 33. Code review islike pants. If you work alone, pants are optional. But if you are part of a team, make sure you have pants on.
- 34.