← Tất cả bài văn hoá

Văn hoá review code: đón nhận chỉ trích kỹ thuật (指摘) mà không tự ái

Văn hoá xem xét mã nguồn trong các công ty công nghệ Nhật Bản: bản chất của các bình luận 指摘 và kỹ năng giao tiếp giúp bạn trưởng thành qua từng dòng code.

Nỗi sợ mang tên "bị bắt lỗi" trong Pull Request

Nhiều kỹ sư mới vào dự án Nhật thường cảm thấy căng thẳng mỗi khi mở Pull Request (PR). Thấy GitHub hay GitLab báo 10–20 bình luận, nghe leader nói "指摘 (してき) nhiều đấy", không ít bạn thấy tự ái, nghĩ đồng nghiệp đang bắt bẻ hay nghi ngờ năng lực mình. Nhưng ở phần lớn team, nhiều bình luận chỉ có nghĩa là reviewer đọc kỹ.

Từ vựng quan trọng

指摘してき
Chỉ ra điểm cần sửa, góp ý kỹ thuật
可読性かどくせい
Tính dễ đọc của mã nguồn (Readability)
手戻りてもどり
Phải quay lại làm lại một công đoạn trước (rework) do sai sót hoặc hiểu lệch

Chỉ trích vào code, không nhắm vào người

指摘 đơn giản là "chỉ ra": biến này chưa kiểm tra null, hàm này dài quá nên khó đọc (可読性 thấp), câu SQL này chưa dùng được index. Lý lẽ rất thực tế: lỗi bắt được ở review sửa mất vài phút, để lọt ra production thì có thể tốn cả ngày xử lý sự cố. Người góp ý đang giúp bạn và giúp dự án.

Nhiều team Nhật còn gắn nhãn đầu bình luận để nói rõ mức độ, ví dụ [MUST] là phải sửa, [IMO] là ý kiến riêng, nits là chuyện nhỏ như đặt tên hay khoảng trắng. Team bạn có quy ước như vậy thì đọc nhãn trước, đừng coi mọi bình luận nặng như nhau.

Approve là cùng đứng tên

Người bấm Approve cũng là người đã xác nhận đoạn code đó ổn. Bug lọt lên production thì câu hỏi trong buổi họp không chỉ là "ai viết" mà còn "review đã bỏ sót gì". Vì vậy reviewer soi kỹ là vì trách nhiệm với chất lượng chung, không phải vì định kiến với người viết.

Cách phản hồi chuyên nghiệp khi nhận góp ý

Khi nhận được góp ý, có 3 cách ứng xử chuẩn mực:

1. Nếu đúng là mình sót: cảm ơn và sửa ngay, trả lời kiểu "ご指摘ありがとうございます。修正しました" kèm commit hash.

2. Nếu bạn có chủ ý kỹ thuật riêng: Bình tĩnh giải thích lý do: "Chỗ này em dùng cách A thay vì B vì lý do hiệu năng, anh xem hướng này có phù hợp không ạ?".

3. Nếu chưa hiểu ý của reviewer: Hãy hỏi lại ngay để làm rõ, tránh việc đoán mò rồi sửa sai lần hai làm phát sinh 手戻り (làm lại).

Mẫu câu trao đổi trong review code

Cảm ơn anh đã chỉ ra ạ. Em đã sửa chỗ đó rồi.

Để nâng cao tính dễ đọc của code, tôi đã tách nhỏ hàm này ra.

Anh xem lại phần đã sửa giúp em, nếu không có vấn đề gì thì nhờ anh merge ạ.

Biến góp ý thành vốn nghề

Năm đầu ở dự án mới, nhận nhiều 指摘 là chuyện bình thường. Hãy ghi lại những lỗi mình hay bị nhắc rồi tự soát trước khi mở PR; vài tháng sau số bình luận giảm hẳn, và đó là lúc leader thấy bạn tiến bộ.

Nguồn

Biên soạn bởi GoMe