Cracking the Code Review by Paco van Beckhoven

Write clear, descriptive pull request titles and descriptions that provide context about what changed and why decisions were made

Review your own code first before requesting reviews - look for formatting issues, unused imports, and potential improvements

Use automated tools to handle formatting, linting and common issues:

• Error Prone for static analysis
• Google Java Format/Spotless for consistent formatting
• ArchUnit for architectural rules enforcement
• Sonar for code quality checks

Follow a structured review process:

1. Look at high-level design/architecture
2. Review tests
3. Check functionality and business logic
4. Look for code readability/complexity
5. Note style/formatting issues last

Be specific and constructive in review comments:

• Avoid personal pronouns like “you”
• Provide alternatives/solutions
• Include positive feedback
• Take discussions offline if they get too long

Use templates and checklists for PRs to ensure consistency and completeness

Keep PRs focused and relatively small to make reviews more manageable

Add screenshots, examples, and test cases to provide more context

Tag specific reviewers rather than broadcasting general review requests

Centralize tool configurations across projects to maintain consistency

Early bug detection in the development process saves significant time and money compared to production fixes