code_review.md

backend review checklist

• no null check
• Hardcoded strings instead of enums
• Tightly coupled code. use DI Dependency injection
• Magic Numbers
• DRY. duplication. One logic, one home
• YAGNI
• use response dto for external services
• check for 500 http status in external service response
• too many if/else conditions, use polymorphism
• Solve today’s problem well. Leave tomorrow’s until it’s real.
• use context manager, when using os.remove()

frontend dev review checklist

EMPTY

How I Give Feedback Without Starting a War

I’ve learned that how you say something in a code review matters as much as what you say. Here’s my personal approach:

Be specific. “Consider using an enum for status values” is better than “Don’t use strings.” Ask instead of assuming. “Was there a reason you didn’t use try-with-resources here?” opens a conversation. Balance critique with praise. If something is well-structured, say it. People remember that. Avoid nitpicking. Focus on what impacts maintainability, correctness, or security. Respect deadlines. Suggest big changes early in the review cycle — not hours before release.