Pragmatic Programmer – Topic 53: Pride and Prejudice — Ký tên lên code

Mở đầu

Hồi làm ở một công ty cũ, mình có thói quen xấu: gặp bug ở chỗ không rõ ai viết thì sửa đại, commit message ghi "fix bug" rồi lặng lẽ biến. Một thời gian sau có người phát hiện đoạn code đó sửa sai, nhưng chẳng ai truy được ai đã đụng vào. Cái ticket nằm đó mấy tháng, còn mình thì thở phào vì không ai gọi tên.

Đọc Topic 53 của The Pragmatic Programmer, mình mới thấy đó không phải chuyện nhỏ. Dave Thomas và Andy Hunt gọi nó bằng một cái tên rất nặng: Pride and Prejudice — lòng tự hào về việc mình làm, và thành kiến khi nó biến mất.

Sự vô danh tạo ra code dở

Các tác giả nói thẳng: "Anonymity, especially on large projects, can provide a breeding ground for sloppiness, mistakes, sloth, and bad code."

Nghe gắt nhưng đúng. Khi code là của tập thể chung chung, không ai ký tên, thì rất dễ thấy mình chỉ là một bánh răng trong cỗ máy. Người ta viết ẩu, rồi viết báo cáo trạng thái dài dòng để tránh phải nhìn lại đoạn code mình vừa đẩy lên.

Điểm mình thích ở chương này là tác giả không hô hào đạo đức suông. Họ chỉ ra cơ chế: muốn code tử tế thì phải có người đứng sau nó. Và họ dẫn lại Tip 97 — Sign Your Work: thợ thủ công thời xưa ký tên lên sản phẩm của mình, lập trình viên cũng nên vậy.

Sign Your Work — ký tên không phải để khoe

Ký tên ở đây không có nghĩa là chèn comment // written by Phong đầy kiêu ngạo. Ý của các tác giả:

• Khi phụ trách một thiết kế hay một đoạn code, làm cho nó đáng tự hào.
• Tên trên code phải là tín hiệu chất lượng — người khác thấy tên là tin đoạn đó chắc chắn, viết gọn, có test, có tài liệu.
• Không phải để giành credit, mà để chịu trách nhiệm.

Mình liên hệ ngay tới cách mình dùng git. Nếu commit nào cũng viết đàng hoàng, review kỹ trước khi đẩy, thì đồng nghiệp mở git blame ra thấy tên mình là yên tâm. Còn nếu lịch sử commit toàn "update", "fix" thì cái tên mình chẳng có nghĩa lý gì.

Mặt trái: sở hữu code sinh ra lãnh địa nhỏ

Chương này có một đoạn rất tỉnh mà nhiều người bỏ qua. Tác giả cảnh báo: cái tên trong sở hữu code có thể gây rắc rối trên một số dự án.

Người ta bắt đầu giữ đất. Giữ chặt phần mình viết, không cho ai sửa. Những thành phần nền chung không ai muốn đụng vào vì "không phải việc của tôi". Cuối cùng dự án thành một mớ lãnh địa tách rời, ai cũng thành kiến với code của mình.

Cách chữa các tác giả đề xuất rất đơn giản: đối xử với code người khác như mình muốn người ta đối xử với code mình. Cộng với nền tảng tôn trọng lẫn nhau, đó là điều kiện bắt buộc để tip này hoạt động.

Điểm mình thấy hơi khó áp dụng trong thực tế. Code có chủ thì review kỹ, nhưng rất dễ thành chuyện cá nhân: góp ý một PR bị hiểu là chê năng lực. Còn chuyển sang sở hữu tập thể như Kent Beck khuyến nghị trong Extreme Programming thì lại cần thực hành đi kèm, ví dụ pair programming, để bù lại sự vô danh.

Lối giữa: tập thể sở hữu, cá nhân chịu trách nhiệm

Các tác giả không cực đoan theo phe nào. Họ chốt lại: code phải có chủ, nhưng chủ không nhất thiết phải là một cá nhân.

Nghĩ cho cùng nó là hai trục khác nhau. Ai cũng được quyền sửa code chung, nhưng người đưa nó vào phải chịu trách nhiệm về chất lượng của nó. Sở hữu tập thể về quyền, cá nhân về nghĩa vụ.

Ảnh: Pexels

Bài học rút ra

• Không ai ký tên thì người ta dễ làm ẩu. Vô danh không xấu, nhưng nó là môi trường tốt cho code dở.
• Ký tên là để chịu trách nhiệm, không phải để khoe. Tên trên code phải là tín hiệu chất lượng: viết gọn, có test, có tài liệu.
• Đừng biến sở hữu code thành lãnh địa. Giữ đất thì dự án vỡ thành nhiều mảnh.
• Code có thể chung, nhưng người đưa code vào phải đứng sau nó.
• Muốn sở hữu tập thể hoạt động được thì phải có review nghiêm túc và pair programming đi kèm.

Ảnh: Pexels

Còn bạn, lần cuối cùng bạn mở git blame ra và thấy tên mình trong đó, bạn thấy tự hào hay chỉ muốn chạy trốn?