Code Review - how to do it better?
summary
Argues that code review works best when reviews stay under 15 minutes and changes are split so each commit does one thing, because reviewers can only hold about seven contexts in their head; uses tools (formatters, static analysis like PMD, IDE refactor) to eliminate style noise and enforce rules (example: max five dependencies) so humans focus on logic and design. Adds lightweight comment tags such as delegate or question to avoid blocking, requires upfront design sharing for big changes, and files Jira issues for deferred fixes.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 1:10Value of code review
- 2:03Defining perfect reviews
- 3:43Common review pitfalls
- 6:19The 'no comment' experiment
- 9:42Improving review comments
- 12:12Handling large pull requests
- 16:03Tools and automation
- 18:54Design and decision making
- 21:02Context switching issues
- 23:47Small commit strategies
- 27:43Balancing small/large reviews
- 30:47Handling refactoring
- 33:33Rule enforcement in reviews
- 36:34Code explanation issues
- 39:54Overcoming review fear
- 44:28Managing complex changes
- 47:35Emergency fixes and process
- 51:11Conclusion and Q&A
