Bạn đang “review” hay đang “phán xét”? 90% team nhầm chỗ này

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.
Bài này mình không viết để “dạy đạo lý”.
Mình viết vì gần như team nào làm sản phẩm đủ lâu cũng sẽ gặp một trong các vấn đề sau:

• PR treo dài ngày vì comment căng
• Reviewer mệt, author mệt, rồi… né nhau
• Người mới sợ mở PR, chỉ dám làm nhỏ
• “LGTM” trở thành một kiểu… cho qua
• Không ai dám đụng refactor vì sợ “bị soi”

Nếu bạn thấy quen quen, thì bài này là dành cho bạn.

1) Review vs Phán xét: khác nhau ở “mục tiêu”, không phải ở “ngôn từ đẹp”

Có những team nghĩ “review tốt” là phải nói nhẹ, phải lịch sự, phải “dạ vâng”. Thật ra không phải. Review tốt có thể rất thẳng. Rất technical. Rất khó tính. Nhưng nó vẫn là review nếu mục tiêu của nó là:

• Làm code đúng hơn
• Làm hệ thống an toàn hơn
• Làm dự án dễ bảo trì hơn
• Giúp team học nhanh hơn

Còn “phán xét” đôi khi… nghe cũng lịch sự, nhưng mục tiêu là:

• Chứng minh ai đúng ai sai
• Giữ quyền lực (“để xem ai mới là người hiểu”)
• Gắn nhãn (“em code yếu”, “ông này ẩu”)

3 dấu hiệu nhận diện “phán xét” (rất thực tế). Bạn có thể tự check 3 điểm này:

(1) Comment đánh vào người thay vì code

• “Em code thế này…”
• “Anh không hiểu em nghĩ gì…”
• “Ai mà viết thế này…”

(2) Comment không có “vì sao”

• “Sai rồi.”
• “Không ổn.”
• “Làm lại đi.”

(3) Comment không mở ra đường giải quyết
 Chỉ có “bác bỏ”, không có “đề xuất”, “gợi ý”, “context”.

Nói ngắn gọn: Review là về giải pháp. Phán xét là về cảm xúc/ego.

2) 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 cái giá rất đắt mà team thường không thấy ngay.

2.1 Defensive mode: PR biến thành trận đấu “ai đúng”

Khi bị phán xét, não người ta chuyển sang chế độ tự vệ.
Và trong chế độ tự vệ, người ta không còn học. Họ chỉ muốn thắng.
PR sẽ chuyển từ:
• “Đoạn này có bug khi data null, fix thế nào?”
 thành
• “Tôi làm đúng mà” / “anh đang áp đặt” / “sao anh soi thế?”

Càng tranh luận kiểu “ai đúng”, team càng rời xa câu hỏi quan trọng nhất:
“Cái gì đúng cho sản phẩm?”

2.2 Silent PR: mọi người bắt đầu “đi một mình”

Sau vài lần bị phán xét, người ta sẽ tự điều chỉnh hành vi:

• Ít mở PR sớm → mất cơ hội feedback sớm
• Ít hỏi → bug “đẻ muộn”
• Ít góp ý ngược → reviewer dần thành “cửa quyền”
• Né PR to → refactor không ai đụng

Nhìn bề ngoài, team có vẻ “êm”. Nhưng thật ra là im lặng vì mệt.
2.3 Học cách né drama thay vì học cách làm tốt

Một team review toxic sẽ rất giỏi… né.

• Né người khó tính
• Né phần code rủi ro
• Né tranh luận
• Né thay đổi

Và hệ quả cuối cùng là: nợ kỹ thuật tăng, tốc độ release giảm, chất lượng giảm.

3) Một câu tự check trước khi bạn comment (cực hiệu quả)

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.
Bạn không cần “nịnh”. Bạn chỉ cần chuyển trọng tâm từ người → code.

4) 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

Điểm khác không nằm ở “lịch sự”. Điểm khác nằm ở cấu trúc:
Rủi ro / mục tiêu → vì sao → gợi ý / lựa chọn

5) 3 “động tác” nhỏ để PR bớt drama ngay lập tức

5.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…”

Khi bạn neo mục tiêu chung, bạn kéo cuộc review ra khỏi “cá nhân”.

5.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?”

Đây là câu cứu rất nhiều cuộc review. Vì reviewer không thể biết hết bối cảnh.

5.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í.

6) Ask / Should / Must: framework giúp comment rõ ràng, tránh “mỗi người một luật”

Mình rất thích 3 nhãn này vì nó giải quyết đúng vấn đề thường gặp nhất:

“Comment này là gợi ý hay bắt buộc?”

🟢 ASK (Hỏi để hiểu)
Dùng khi bạn chưa chắc hoặc muốn hiểu intent:

• “Mình hiểu đúng không…?”
• “Chỗ này intended behavior của mình là gì?”
• “Case X có xảy ra không?”

🟡 SHOULD (Gợi ý lựa chọn)
Dùng cho cải thiện nice-to-have:

• “Nếu có thể, mình gợi ý tách hàm để dễ test hơn.”
• “Gợi ý cân nhắc đổi naming để dễ đọc.”
• “Có thể dùng pattern X để dễ maintain.”

SHOULD không nên block merge (trừ khi team đã thống nhất nó là tiêu chuẩn bắt buộc).

🔴 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

MUST nên đi kèm “vì sao” rõ ràng:

“Chỗ này có rủi ro X/Y, mình nghĩ cần xử lý trước khi merge để tránh lỗi production.”

Nếu cái gì cũng MUST, người ta sẽ “lờn”.

7) “Giao kèo” với team: tiêu chuẩn tối thiểu để approve

Đây là bước nhiều team bỏ qua, nên review dễ thành… cảm tính. Hãy thống nhất với nhau một “bar merge” tối thiểu. Ví dụ “bar merge” (bạn có thể copy áp dụng)

MUST trước khi merge

• Không có bug logic rõ ràng (đặc biệt với happy path)
• Không gây crash / không phá flow chính
• Không tạo lỗ hổng security
• Không break API contract
• Có test cho những nhánh quan trọng (tuỳ dự án)

SHOULD nếu có thời gian

• refactor cho sạch hơn
• tối ưu naming
• tách hàm cho dễ đọc
• tối ưu performance nhẹ

Khi có bar merge, PR sẽ bớt drama vì:

• reviewer không còn “tuỳ mood”
• author biết mình cần làm gì
• team thống nhất mức chất lượng

8) Template comment “thẳng mà không căng” (rất hữu dụng)

Dưới đây là bộ template mình hay dùng, bạn có thể dán vào notion/team guideline.
Template 1: Chỉ ra rủi ro + đề xuất

“Chỗ này có thể lỗi khi (tình huống). Mình đề xuất (cách) để tránh rủi ro.”

Ví dụ:

“Chỗ này có thể lỗi khi data null. Mình đề xuất thêm guard + fallback UI.”

Template 2: Gợi ý với Should

“Nếu có thể, mình gợi ý (cải thiện) vì (lý do). Hiện tại thì vẫn OK.”

Ví dụ:

“Nếu có thể, mình gợi ý tách hàm buildPayload vì sẽ dễ test hơn. Hiện tại vẫn OK để merge.”

Template 3: Ask để hiểu bối cảnh

“Cho mình hỏi (câu hỏi) để mình hiểu intent/constraint.”

Ví dụ:

“Cho mình hỏi mình đang tối ưu cho speed hay readability ở đoạn này? Có constraint deadline không?”

Template 4: Must rõ ràng, không gay gắt

“Mình nghĩ phần này cần fix trước khi merge vì (lý do cụ thể).”

Ví dụ:

“Mình nghĩ phần này cần fix trước khi merge vì có thể leak data nếu user không có quyền.”

9) 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?

10) Kết: Review tốt không làm người khác im lặ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. Vì sản phẩm tốt không đến từ “người giỏi nhất”. Mà đến từ team phối hợp tốt nhất.

Tác giả: anh Trần Anh Tuấn (Evon) – member dự án Easier tại TechX Vietnam

Về danh sách Blog