Tại sao nên Comment và Approve Pull Request cùng lúc?

Tại sao nên Comment và Approve Pull Request cùng lúc?

Sau khi xem xét rất nhiều Pull Request (PR), tôi đã đúc kết được một quy tắc mặc định đơn giản: nếu tất cả các nhận xét của tôi chỉ là những điểm nhỏ nhặt (nitpicks), gợi ý, câu hỏi hoặc các vấn đề không gây chặn (non-blocking), tôi sẽ để lại những nhận xét đó và phê duyệt PR ngay lập tức.

Dưới đây là chi tiết về cách hoạt động của phương pháp này. Nhưng trước hết, hãy trả lời hai câu hỏi làm rõ vấn đề.

Tại sao lại Comment khi đã Approve?

Tại sao lại để lại nhận xét nếu tôi đã phê duyệt?

Nhận xét cho thấy rằng có ai đó đã thực sự suy nghĩ về vấn đề và giải pháp, và họ quan tâm đến những gì đang diễn ra với mã nguồn. Thỉnh thoảng, chúng mang lại cơ hội để học hỏi hoặc để làm rõ những hiểu lầm, các giả định hoặc rủi ro tiềm ẩn.

Tôi hầu như luôn để lại một nhận xét trên mỗi PR tôi xem xét, ngay cả khi đó chỉ là quan sát: "Lớp này đang trở nên quá lớn, có lẽ chúng ta nên cân nhắc thêm một presenter," hoặc lời khen ngợi: "Cảm ơn vì đã dọn dẹp đoạn code này!"

Tại sao lại Approve khi đã Comment?

Tại sao lại phê duyệt, nếu tôi đã để lại những nhận xét mà tôi nghĩ đáng lẽ nên được thực hiện?

Bởi vì tôi tin tưởng vào đội ngũ của mình. Tôi biết rằng các nhận xét của tôi sẽ được cân nhắc, và nếu chúng hữu ích, chúng sẽ được thực hiện.

Đội ngũ của tôi đủ nhanh để thực hiện thay đổi đó. CI (Continuous Integration) chạy đủ nhanh để xác thực nó. Thời gian cần thiết để làm điều đó không phải là trở ngại.

Các điểm lưu ý về quy trình

Dưới đây là một vài điểm về quy trình mà quy trình làm việc này giả định.

Đầu tiên, bạn phải tin tưởng vào đội ngũ của mình. Nếu bạn không tin tưởng họ đọc và suy nghĩ về các nhận xét của bạn — nếu các nhận xét đó không phải là một tín hiệu đủ mạnh — hãy làm việc để cải thiện điều đó.

Ngoài ra, một số kho lưu trữ (repository) được cấu hình để đặt lại trạng thái phê duyệt khi một commit mới được đẩy lên nhánh PR. Nếu đó là cấu hình của bạn, cách tiếp cận này sẽ kém hiệu quả hơn vì bài đánh giá (review) của bạn bị loại bỏ khi một thay đổi thực hiện gợi ý của bạn, hoặc của bất kỳ ai khác, được commit. Vẫn có giá trị ở đó vì sự phê duyệt của bạn được ghi lại trên PR, nhưng nó không phải là lý tưởng.

Hơn nữa, một số repo có thể được cấu hình để tự động hợp nhất (merge) các PR khi tất cả các yêu cầu được đáp ứng, một trong số đó có thể là sự phê duyệt của bạn. Hãy tham khảo cấu hình repo của bạn trước khi hành động.

Quy trình này cũng hoạt động tốt hơn với các công cụ có cấu hình thấp giúp loại bỏ nhiều nhận xét vụn vặt. Với các công cụ như linters, auto-formatters, type checkers, security scanners, v.v. chạy trong môi trường phát triển và CI, một số nhận xét giá trị thấp không cần phải viết ra.

Cuối cùng, tất cả các nhận xét tôi viết đều được đặt ngữ cảnh bởi "Conventional Comments". Tôi sử dụng các nhãn như nitpick: (nhặt sạn), question: (câu hỏi), suggestion: (gợi ý), và issue (non-blocking): (vấn đề không gây chặn) để làm rõ ý định khi tôi phê duyệt.

Dưới đây là một số công cụ khác, giống như Conventional Comments, đã được giới thiệu cho tôi:

• Phương pháp MoSCoW
• Thang phản hồi của Netflix (Netflix’s Feedback Ladders)
• Emoji (👁️, 🧹, 🐛)

Vậy còn các Comment gây chặn (Blocking) thì sao?

Đối với những phản hồi quan trọng hơn, loại nên ngăn chặn công việc, tôi có thể chỉ comment, hoặc comment và chặn (block).

Đó là điều tôi quyết định tùy theo từng trường hợp, và nó khác nhau đối với các loại vấn đề, dự án và người có mã nguồn mà tôi đang xem xét.

Đánh giá mã (code review) là một nơi tốn kém để phát hiện ra một vấn đề gây chặn hoặc lỗi thiết kế. Đối với loại đội ngũ mà tôi đã làm việc nhiều nhất — các startup và doanh nghiệp vừa và nhỏ (SMB) — điều này thường chỉ ra sự thiếu thống nhất ở thượng nguồn (upstream misalignment). Các đội ngũ khác có thể có cổng đánh giá mã nghiêm ngặt hơn, và việc này phổ biến hơn.

Bạn muốn đạt đến trạng thái mà hầu hết phản hồi là không gây chặn vì đội ngũ được liên kết rất cao. Và sau đó bạn có thể comment và phê duyệt một cách tự tin.

Thử thách: Comment và Approve!

Đối với những người hoài nghi, gợi ý của tôi là hãy thử điều này với một người trong đội ngũ mà bạn có mối quan hệ tốt. Bạn có thể nói trong một nhận xét trên PR: "Trông có vẻ ổn rồi, tôi phê duyệt nhé. Tôi nghĩ việc đổi tên là đáng làm, nhưng ngoại trừ ra thì đã ổn để chạy rồi." Hầu hết các kỹ sư mà tôi biết sẽ cân nhắc lời khuyên này và làm theo đó. Kết thúc cuộc trò chuyện, và mã có lẽ sẽ tốt hơn.

Tôi muốn các bài đánh giá mã của mình đóng vai trò huấn luyện và giảng dạy, và thực hành này giúp ích cho điều đó. Khi nó sai, nó sai về phía tiến độ hơn là quy trình.

Đó là cách tôi nói: "Tôi quan tâm đến thay đổi này, và đây là cách tôi nghĩ nó có thể còn tốt hơn. Bạn quyết định khi nào phát hành (ship) nó nhé."