How to Give Good Code Review Feedback

Effective code review feedback needs to be specific, constructive, and focused on the code rather than the person. Start by being specific about what needs to change. Don't say this method is confusing. Instead, say this method mixes business logic with data access, which makes it hard to test. Can we extract the database calls into the repository layer? That tells the author exactly what the problem is and gives them direction. Always explain your reasoning. Don't just say use constructor injection. Say use constructor injection instead of field injection because it makes dependencies explicit and enables testing without Spring. When someone understands why a pattern is better, they'll apply it consistently. Offer alternatives when possible. If you're saying an approach won't work, suggest what will work. Instead of catching all exceptions here, catch specific exceptions like IOException and let unexpected ones propagate to the global error handler. One technique I use is prefixing comments to signal priority. I write nit for minor style issues that won't block the merge, like variable naming. I write suggestion for optional improvements that make code better but aren't critical. I write question when I don't understand the approach and want the author to explain. And I don't use a prefix for required changes that block the merge, like security issues or missing validation. This helps authors know what to focus on first. Another key point is focusing on the code, not the person. Say the code doesn't handle concurrent requests properly, not you forgot about concurrency. That keeps feedback objective and professional. A common mistake freshers make is being too vague. They say this looks wrong or I don't like this but don't explain why or what to change. Another mistake is only pointing out problems without offering solutions or teaching the better pattern. Code review is a mentoring opportunity.