Chia sẻ bài viết: Kinh Nghiệm Review Code Của Tôi Với Tư Cách Là Một Lập Trình Viên Junior: Tôi Đã Học Được Gì Và Cách Review Như 1 Team?

Tham khảo: https://levelup.gitconnected.com/my-code-review-experience-as-a-junior-developer-what-i-learned-and-how-to-review-as-a-team-2166a85df1c2

Hey there, curious minds! 👋

Welcome to my newsletter, where I share what I’ve been learning, thinking about, and exploring in the tech world. If you don’t know me:

Hi, I am Sumonta Saha Mridul. I’m an Associate Software Engineer at Cefalo. I regularly share what I learn through weekly posts on LinkedIn, Dev. to, and Medium. Also, I run a small YouTube channel where I try to share helpful content for developers.

As a junior developer, especially in the AI era, where almost everything can be generated by AI, it’s hard to continuously improve and keep learning. One of the best ways to grow is by reviewing and trying to understand existing code. Yes, at an early stage, it’s hard, things seem complicated, and you might not know the best practices. But if you don’t start now, it will be difficult to go far in this industry.

Code reviews are not just about finding bugs. They are about learning, sharing, and improving the overall quality of the system. The goal is simple: to improve the system while learning.

For the last few months, I got the chance to review and mentor teammates and review some codes and PR’s at Cefalo . I took it as a challenge. But before jumping in directly, I did a little bit of research: how to be a good code reviewer? I started learning from my seniors, how they review my code, what they look for, and how they understand things so quickly.

Here, I’m just sharing all the knowledge and learning I gathered throughout this time.

🔑 1. Mindset: You are a mentor, not a Judge

The first rule of reviewing code is remembering that the goal is to improve the code, not to insult the developer.

• Do not take commit messages personally.
• Remember your junior days. Everyone starts with mistakes, insecurities, and a lack of confidence. When you started your journey, did you know all the best practices? Maybe not. So, let them learn.
• Instead of just pointing out what’s wrong, try to explain why something needs to change, and the benefit of doing it a better way. Share best practices. Show how a small improvement can make a big difference in code quality, and sometimes, just a small example or hint can be enough to guide them in the right direction.
• People make mistakes. Don’t judge too quickly. Before jumping to conclusions, first ask the developer for a quick preview or explanation. Try to understand their thought process and there’s logic behind the approach even if it’s not the best one.

Ask yourself: “How can I help this developer write better code in the future and grow more?”

Remember: The behavior of senior engineers sets the tone for the entire team culture. Junior engineers observe what you do, how you give feedback, how you communicate, how you handle mistakes, and they start to repeat that behavior to others. In long time. that how a culture shapes in a team.

Goal: Help each other write better code in future and build a quality system. You’re there to help improve the code, ensure team standards, and learn not to just find flaws and mistakes

🎯 2. Tone is the Key

The way you give feedback shapes the whole code review experience. Personally, from my experience, I feel this is one of the most important parts of a code review. Your words can either motivate someone to learn and improve or completely kill their confidence.

• Highlight both strengths and weaknesses.
• Explain the reason behind every suggestion.
• Use positive and polite language. Avoid harsh, vague, or demotivating comments.
• Invite discussion. Encourage the developer to share their honest thought process before judging the code. Always encourage them to ask questions without hesitation and actively listen to their concerns or challenges.
• You should also appreciate the junior developer’s efforts and achievements and celebrate their progress and success. This builds trust and confidence. In our team in Cefalo , when finally, a PR gets approval, we try to give feedback like this “🥳 Great Work”, “🎉 Good Job, Keep it up!”

💬 Instead of: “This is wrong.” Say: “I’m struggling to understand this part. Can you walk me through it?”

Be respectful, curious, and suggestive. Examples of Good Review Comments:

• “Nice use of utility functions here! One suggestion though…”
• “Could we simplify this logic with a helper function?”
• “This works well, but I wonder if there’s a more efficient way.”

One of the best things I’ve experienced in my journey at Cefalo is how we approach code reviews. We never use “you”, we always say “we” in our comments. It creates the feeling that we’re solving the problem together, not pointing fingers. For example:

• Instead of saying: “Why did you do that?” We say: “Can we do it this way?”
• Instead of: “Why did you use a loop here?” We say: “Why are we using a loop here? Is there a better approach?”

This small change gives the developer a positive vibe and makes them feel more involved and comfortable in the review process. It creates a supportive, team-like environment. I actually learned this from one of my mentors, Simanta Deb Turja and Md Naem bhai.

Press enter or click to view image in full size

🧭 3. Follow a Framework: The CEDAR Feedback Model

• Context: Create a comfortable environment, leave ego aside, and focus on the outcome.
• Example: Use specific examples of what works or what needs improvement.?
• Diagnosis: Ask why the code was written this way. Use open-ended questions instead of assumptions. Ask their context you are missing, before judging
• Actions: Suggest improvements that follows the best practices
• Review: Summarize and ensure mutual understanding.

This structure helps make feedback clear, respectful, and actionable.

4. My Todo List: What to look for in code reviews?

When reviewing code, look at the big picture first, then the details.

✅ Basic

• Understand the Goal: Read the PR title, description, and related task/ticket.
• Branching name is, okay? Try testing it locally?
• Check if your previous suggestions are applied?

✅ Design Review

• Is it Well designed? making the overall system better or worse?
• Does the new code follow pattern that already applied in codebase? Does it follow existing patterns?
• Would a new developer know where to look this feature or logic after six months?
• Does the form re-rendering? Are validations working?

✅ Functionality Review

• Does the code work as intended? Does it fulfill end-user requirements?
• Look for bugs? What could go wrong if corner case not handled?
• Are bugs, leaks, race conditions, or deadlocks possible?
• Are requests handled correctly? Error states? Is data being updated correctly?

✅ Complexity

• Is the code too complex? Is this code doing over engineering staff?
• Is a function doing more than one job?
• Is it violating design principles like Single Responsibility?

✅ Naming & Documentation

• Are function and variable names meaningful and clear?
• Is the code easy to read and follow? Can I understand the code after a month?

✅ Performance & Security

• Any obvious performance bottlenecks?
• Any security risks with inputs or data handling?
• Any information leakage in Api call?
• Is it rendering multiple times? Check the computation cost?
• Are errors properly handled? Are there any edge cases?
• Any N+1 queries or unnecessary loops?

💬 5. Give Feedback That Teaches

Good code reviews are not about nitpicking or micromanaging. Focus on:

• The bigger picture and overall design.
• Don’t just think based on specific function or code, think from longer vision.
• Explaining why something should change. Every comment must include a “because” clause. Offering examples or small clues when suggesting improvements.

Never leave a comment as “please do X”. Instead, it must be “please do X because Y”.

Honestly, I also make this mistake sometimes. I get stuck on small parts of the code instead of thinking about the full context.

Sometimes I use tools for code review and the first thing I try to do is understand the context of the changes. And to be honest, I’ve also learned a lot of new things just by reviewing others’ code.

Press enter or click to view image in full size

Also, remember you can be wrong too. Be open to accepting your mistakes.

The main goal is learning for both sides. Code review should be a two-way process, not just one giving and one receiving. It is a learning opportunity for you and the junior developer.

🤝 Remember:

• Your code reviews can either help someone become a better developer and write cleaner code or completely kill their motivation to improve.
• Code reviews are not just about code; they’re the first step on your journey to becoming a better leader and software developer.

🧡 Thanks for Reading!

That’s all! I hope you learned something new or saw tech from a new angle. If you enjoyed this, feel free to share it or comment on your thoughts. I’d love to hear your thoughts. Until next time, keep learning and building!

Sumonta Saha Mridul, Associate Software Engineer I, Cefalo Bangladesh Ltd.

I regularly share what I learn through weekly posts on LinkedIn, Dev. to, and Medium. Also, I run a small YouTube channel where I try to share helpful content for developers.