Cái comment làm tôi phải nhìn lại mình
Năm đó tôi là tech lead của một team 6 người. Tôi tự hào về code quality của team - PR rejection rate cao, comment kỹ, bug rate thấp.
Một hôm tôi review PR của Linh - junior developer mới 6 tháng. Tôi để lại 12 comments. Ngắn gọn, technical, đúng hết.
Một tuần sau Linh xin nghỉ. Trong exit interview, khi được hỏi lý do, cô ấy nói: "Em cảm thấy code của em lúc nào cũng sai hết. Không biết mình có đang tiến bộ không."
Tôi ngồi đọc lại 12 comments của mình. Tất cả đúng. Nhưng không một comment nào nói: "Approach này thú vị vì...", "Em đã handle được X tốt, phần Y có thể cải thiện bằng cách...", "Câu hỏi cho em: tại sao em chọn cách này thay vì Y?"
12 comments. 12 lần nói "sai". Không một lần nói "tốt". Không một lần giải thích tại sao, chỉ nói phải làm gì.
Đó là lúc tôi nhận ra: Tôi đang review code, không phải mentoring developer.
Bước ngoặt: Code review là gì thực sự?
Sau sự việc đó, tôi research và reflect nhiều hơn về code review.
Code review là một cơ chế có 3 mục đích:
- Quality gate: Catch bugs, enforce standards
- Knowledge sharing: Spread knowledge về codebase
- Mentoring: Grow developer skills
Hầu hết team tập trung vào mục đích 1 và bỏ qua hoàn toàn mục đích 3. Nhưng với junior và mid developer, mục đích 3 thường quan trọng hơn mục đích 1.
Lý do: Bug từ junior dev thường là symptom của knowledge gap. Fix bug mà không address knowledge gap → bug tương tự sẽ xuất hiện lại.
Bài học tôi rút ra: Framework cho mentoring code review
Nguyên tắc 1: Hỏi trước, phán sau
Thay vì: "Đây là anti-pattern. Refactor thành Repository pattern."
Dùng: "Tại sao em chọn approach này? Có cân nhắc Repository pattern không? Tôi tò mò muốn hiểu reasoning của em."
Câu hỏi có hai tác dụng:
- Bạn có thể đang sai - developer có thể có context bạn không biết
- Nếu developer không có lý do tốt, việc giải thích reasoning sẽ stick hơn là đọc instruction
Nguyên tắc 2: Acknowledge trước khi suggest
Mỗi review phải có ít nhất một comment nhận ra cái gì developer đã làm tốt.
Không phải khen cho có - mà là thực sự tìm thứ gì đó tốt để acknowledge. Luôn có.
✅ "Em đã handle error case khá tốt ở đây - throw specific exception thay vì generic là đúng.
Một điều có thể strengthen thêm: thêm error context vào exception message.
Thay vì throw new OrderException("Invalid"), có thể throw new OrderException($"Invalid order status: {order.Status} when processing payment")
Điều này giúp debugging sau này dễ hơn nhiều."Nguyên tắc 3: Explain "why", không chỉ "what"
Tệ nhất: "Refactor thành này."
Trung bình: "Nên dùng X thay vì Y."
Tốt: "Nên dùng X thay vì Y, vì X giúp testability tốt hơn - khi Y hardcode dependency, unit test sẽ phải mock entire service."
Developer học pattern khi họ hiểu reasoning, không chỉ khi họ biết rule.
Nguyên tắc 4: Phân loại comment
Tôi dùng prefix để developer biết level của mỗi comment:
[BLOCK]: Phải fix trước khi merge - security issue, potential bug, breaking change
[SUGGEST]: Nên fix - code quality, maintainability
[QUESTION]: Tôi không hiểu, cần clarify
[NIT]: Nice-to-have, không nhất thiết fix ngay
[LEARN]: Chia sẻ thêm context/pattern để developer họcKhi developer thấy 5 comments nhưng chỉ 1 là [BLOCK], họ biết PR không tệ - chỉ cần một fix nhỏ.
Nguyên tắc 5: Pair thay vì just comment khi complexity cao
Khi feedback quá phức tạp để giải thích qua comments, đừng viết essay dài. Ngồi lại 30 phút pair programming để walk through - đây effective hơn nhiều.
Gửi các bạn trẻ
Nếu bạn đang ở vai trò reviewee:
Khi nhận comment: Đừng defensive. Mọi comment - dù được diễn đạt tệ đến đâu - đều có information bạn có thể học. "Code này xấu" không helpful, nhưng "tại sao reviewer nghĩ code này xấu?" thì có.
Khi không hiểu comment: Hỏi. "Anh/chị có thể giải thích tại sao approach này tốt hơn không? Em muốn hiểu hơn." Đây không phải defensive - đây là learning.
Khi không đồng ý: Hỏi, không argue. "Anh/chị có thể share thêm context tại sao X tốt hơn Y không? Em đang thấy trade-off là..." Nếu sau discussion bạn vẫn không đồng ý - escalate professionally.
Bạn nghĩ sao?
Bạn đang review code theo approach nào? Và nếu bạn từng nhận review tệ - nó ảnh hưởng đến bạn như thế nào? Tôi tin rằng code review culture ảnh hưởng rất lớn đến psychological safety của team - muốn nghe góc nhìn của các bạn 👇
/Son Do - believe in basic
#1percentbetter #TechnicalLeadership #CodeReview #Mentoring #EngineeringCulture