20/03/2026
🤔 𝐁𝐚̣𝐧 đ𝐚𝐧𝐠 “𝐫𝐞𝐯𝐢𝐞𝐰” 𝐡𝐚𝐲 đ𝐚𝐧𝐠 “𝐩𝐡𝐚́𝐧 𝐱𝐞́𝐭”? 𝟗𝟎% 𝐭𝐞𝐚𝐦 𝐧𝐡𝐚̂̀𝐦 𝐜𝐡𝐨̂̃ 𝐧𝐚̀𝐲.
Có một sự thật hơi đau:
Nhiều team nói “review code để tốt hơn”, nhưng thực tế PR lại biến thành… phòng xử án.
Bạn mở PR lên, tim hơi đập nhanh.
Không phải vì sợ bug.
Mà vì sợ… cách người ta nói:
・“Sao code kiểu này?”
・“Không ổn.”
・“Sai rồi.”
・“Làm vậy ai maintain?”
・“Em nghĩ gì khi viết đoạn này?”
Và thế là… thay vì bàn về chất lượng code, mọi người vô thức bàn về chất lượng con người.
Ranh giới mỏng nhưng cực nguy hiểm:
✅ Review = cùng soi code để cải thiện sản phẩm
❌ Phán xét = gán nhãn người viết code
Bạn có thể đúng về kỹ thuật… nhưng sai về văn hoá.
Và cái “sai” đó làm team mất tốc độ nhiều hơn cả bug.
Vì sao “phán xét” làm team chậm đi (dù bạn tưởng nó giúp team nhanh)?
Vì nó tạo ra 3 thứ cực đắt:
1) “Defensive mode” (chế độ tự vệ)
Người bị góp ý kiểu phán xét sẽ không còn tập trung vào giải pháp nữa.
Họ tập trung vào việc… bảo vệ bản thân.
👉 PR biến thành tranh luận “ai đúng” thay vì “cái gì đúng”.
2) “Silent PR”
Sau vài lần bị phán xét, người ta bắt đầu:
・ít mở PR hơn (đợi “xong hẳn” mới dám mở)
・ít hỏi hơn
・ít góp ý ngược lại
・và… ít quan tâm chất lượng chung hơn
3) Học cách né thay vì học cách tốt
Team không cải thiện kỹ năng. Team chỉ cải thiện… kỹ năng né drama.
Một câu tự check trước khi bạn comment
Trước khi gõ, tự hỏi:
“Comment này làm code tốt lên… hay làm người đọc thấy tệ đi?”
Nếu comment khiến người đọc:
• ngại mở PR lần sau
• sợ hỏi
• muốn đáp trả
→ khả năng cao nó đang là phán xét, dù ý bạn là tốt.
Before / After: cùng một vấn đề, khác cách nói → khác kết quả
🎭 BEFORE (Phán xét)
• “Sao em code vậy?”
• “Đoạn này dở.”
• “Thiếu trách nhiệm.”
• “Ai mà maintain nổi.”
✅ Kết quả kỹ thuật: có thể sửa được code
❌ Kết quả văn hoá: PR căng, tốc độ chậm, người viết thu mình
🧑🏫 AFTER (Review đúng nghĩa)
• “Đoạn này có thể lỗi khi data null, mình thêm guard nhé?”
• “Chỗ này nếu tách hàm thì test sẽ dễ hơn.”
• “Mình đổi cách đặt tên để người đọc hiểu nhanh hơn không?”
• “Có constraint nào khiến mình chọn approach này không?”
✅ Kết quả kỹ thuật: code tốt hơn
✅ Kết quả văn hoá: người viết muốn hợp tác, team học được thứ mới
3 “động tác” nhỏ để PR bớt drama ngay lập tức
1) Bắt đầu bằng mục tiêu chung
Thay vì “Sai rồi”, thử:
“Mục tiêu ở đây là giảm rủi ro production / dễ đọc / dễ test…”
2) Hỏi trước khi kết luận (Ask > Tell)
Một câu hỏi đúng giảm căng thẳng cực mạnh:
“Có lý do/constraint nào khiến mình chọn cách này không?”
Nhiều thứ “trông có vẻ sai” nhưng lại đúng vì constraint.
3) Đổi “Bạn” thành “Chúng ta”
• “Em làm vậy…” → nghe như chỉ trích
• “Chúng ta thử…” → nghe như đồng đội
Chỉ đổi 1 từ, nhưng đổi cả bầu không khí.
Bộ từ khoá “cứu” văn hoá review code: Ask / Should / Must
🟢 ASK (Hỏi để hiểu)
• “Mình hiểu đúng không…?”
• “Chỗ này intended behavior của mình là gì?”
🟡 SHOULD (Gợi ý lựa chọn)
• “Gợi ý cân nhắc tách hàm…”
• “Có thể dùng pattern X để dễ maintain…”
🔴 MUST (Chỉ khi thật sự bắt buộc)
• Chỉ dùng khi liên quan:
• correctness (sai logic)
• security
• performance nghiêm trọng
• breaking change
Nếu cái gì cũng “must”, team sẽ mệt và lì.
Với lỗi nhỏ / tùy chọn, chúng ta có thể comment theo hướng gợi ý:
“Nếu có thời gian, mình gợi ý thử X cho gọn hơn. Còn bản hiện tại mình thấy OK để merge.”
Với lỗi nghiêm trọng, chúng ta sẽ nói thẳng nhưng không nặng nề:
“Đoạn này có rủi ro khá rõ (…); mình đề xuất fix trước khi merge để tránh hậu quả về sau.”
Chốt ‘mức tối thiểu’ với team. Thống nhất luôn: cái gì bắt buộc trước khi merge, cái gì để sau, cái gì là MUST để merge, cái gì là SHOULD để cải thiện dần.”
Mini checklist 20 giây trước khi bấm “Comment”
✅ Comment này có nói rõ vì sao không?
✅ Có đưa gợi ý/định hướng không?
✅ Có phân biệt “code” và “người” không?
✅ Tone của mình có khiến người đọc muốn hợp tác không?
Review tốt không phải là review làm người khác im lặng.
Review tốt là review khiến: code tốt lên – người viết học được – team muốn tiếp tục làm chung.
Team bạn đang review code kiểu nào: Coach hay Judge?
Comment 1 tình huống “khó xử” (không cần nêu tên) — mình sẽ gợi ý cách phản hồi sao cho thẳng mà không căng.
Nguồn ảnh: https://imgflip.com/ , https://makeameme.org/
![[INFO] 260120 SEO & GIẤC MƠ MÀU XANH ⚡Khi tốc độ không chỉ là con số, mà là động lực tạo nên trải nghiệm số vượt trội 🚀V...](https://img3.yasteq.com/829/234/122206657358292344.jpg)
![[EVENT] 260130 🎉 HAPPY HOUR THÁNG 1 – KHI TECHX-ERS CÙNG NHAU ĐÓN TẾT GẦN HƠN 🧧Mỗi cuối tháng, TXVN đều tổ chức Happy Ho...](https://img3.yasteq.com/229/234/122206300322292344.jpg)
![[INFO] 260108 🚀 Agentic AI — Khi AI trở thành “cộng sự”Không còn chỉ hỏi – đáp, Agentic AI biết nghĩ – quyết – hành động...](https://img5.yasteq.com/429/234/122205354854292344.jpg)
![[INFO] 260109 BẠN VIẾT CODE HAY BẠN ĐANG “ĐẠO DIỄN” CODE?Bạn vẫn đang "code như một máy": Mở IDE ➔ Gõ ➔ Debug ➔ Gõ tiếp?...](https://img3.yasteq.com/229/234/122204031362292344.jpg)
