𝗠𝗢̛̉ 𝗣𝗨𝗟𝗟 𝗥𝗘𝗤𝗨𝗘𝗦𝗧 𝗠𝗔̀ 𝗡𝗚𝗨̛𝗢̛̀𝗜 𝗥𝗘𝗩𝗜𝗘𝗪 𝗖𝗛𝗨̛𝗔 𝗧𝗨̛̀𝗡𝗚 𝗕𝗜𝗘̂́𝗧 Đ𝗘̂́𝗡
Gần đây tôi có review một pull request (PR) rất lớn. Nó sử dụng AI để hỗ trợ viết code. Nó thay đổi một module mà ba tính năng khác đang sử dụng. Phần mô tả chỉ vỏn vẹn một câu. Nó nêu tên file nhưng không nêu lý do của sự thay đổi.
Tôi đã mất mười lăm phút để nắm bắt các thay đổi trước khi có thể bắt đầu. Tôi phải tìm ra mục đích. Tôi phải tìm ra các rủi ro. Tôi phải tách biệt các file quan trọng khỏi những thứ gây nhiễu.
Tôi nhận ra mình cũng từng làm điều này với người khác trước đây.
Khi bạn viết code, bạn nắm giữ toàn bộ ngữ cảnh. Bạn biết tại sao mình lại chia nhỏ một module. Bạn biết mình đã thử cách nào trước đó. Bạn biết phần nào mình còn cảm thấy chưa chắc chắn.
Hầu hết mọi người viết mô tả cho chính họ. Họ viết "Refactored service layer" hoặc "Fixed auth module." Đây là những mô tả dành cho những người đã nắm rõ ngữ cảnh.
Một bản mô tả tốt là dành cho người không biết gì cả.
Mô tả không chỉ là một bản tóm tắt. Nó là một bài kiểm tra. Nếu bạn không thể giải thích được công việc của mình, thì công việc đó vẫn chưa sẵn sàng.
Giờ đây, tôi sử dụng cấu trúc sáu phần cho mọi PR quan trọng:
• Intent: Giải thích tại sao PR này tồn tại và vấn đề mà nó giải quyết. Nếu bạn không thể viết được điều này, hãy dừng lại. PR đó chưa sẵn sàng. • Major changes: Liệt kê các quyết định ảnh hưởng đến kiến trúc hoặc hành vi hiện tại. • Minor changes: Liệt kê các phần dọn dẹp (cleanups) và đổi tên (renames). Hãy tách biệt chúng khỏi các thay đổi về cấu trúc. • Impact: Liệt kê các hệ thống mà thay đổi này chạm tới. Cung cấp một bản đồ về phạm vi ảnh hưởng (blast radius). • Evidence: Liệt kê những gì bạn đã chạy và những bài kiểm tra (tests) bạn đã vượt qua. Đưa ra bằng chứng cho thấy bạn đã thực hiện công việc. • Uncertainties: Nêu rõ những gì bạn còn đang phân vân.
Khi bạn thừa nhận những điểm chưa chắc chắn, bạn đang giúp đỡ người review. Họ sẽ biết cần phải xem xét kỹ ở đâu. Họ sẽ không lãng phí thời gian vào những phần đang hoạt động ổn định.
Nếu bạn không thể gọi tên được những điểm chưa chắc chắn của mình, nghĩa là bạn chưa suy nghĩ đủ sâu về code của mình.
Mô tả là bước cuối cùng trước khi bạn quyết định xem liệu một PR có nên được mở ra hay không.
Một người review hiểu được mục đích của bạn sẽ dành thời gian cho những câu hỏi khó. Một người review phải đoán mục đích của bạn sẽ dành thời gian cho những câu hỏi dễ. Họ sẽ hỏi xem thứ đó là gì thay vì hỏi xem nó có đúng hay không.
Hãy viết cho người review, người chưa từng tiếp xúc với code của bạn. Hãy viết như thể bạn sẽ không có mặt ở đó để trả lời câu hỏi. Hãy viết như thể chính bạn đang đọc lại nó vào ba ngày sau đó mà không còn nhớ gì về công việc đã làm.
Nếu bản mô tả đáp ứng được các tiêu chí trên, PR đó đã sẵn sàng.
Hãy cứ mở PR đi, người review của bạn vẫn chưa gặp đâu
Bạn đã làm việc trên một tính năng trong ba ngày. Bạn đã viết code, thêm các bản kiểm thử (tests), và thậm chí đã refactor một vài phần. Nhưng rồi, bạn lại do dự. "Liệu nó đã đủ tốt chưa?" "Nếu họ phát hiện ra một lỗi cơ bản thì sao?" "Có lẽ mình nên trau chuốt thêm một chút nữa trước khi gửi."
Đây chính là cái bẫy của chủ nghĩa hoàn hảo.
Chúng ta thường coi Pull Request (PR) như một bài kiểm tra cuối kỳ, nơi chúng ta phải trình bày một kiệt tác không tì vết để đạt điểm cao. Nhưng thực tế, một PR là một cuộc hội thoại.
Tại sao bạn nên mở PR sớm hơn:
- Phản hồi sớm hơn: Đừng đợi đến khi hoàn thành 100% mới mở PR. Nếu bạn đang đi sai hướng, việc nhận ra điều đó vào ngày thứ 2 sẽ tốt hơn nhiều so với ngày thứ 10.
- Giảm bớt áp lực: Khi bạn chia sẻ code sớm, áp lực phải trở nên hoàn hảo sẽ giảm bớt. Bạn đang tìm kiếm sự trợ giúp, chứ không phải đang trình diễn.
- Tốc độ của nhóm: Việc chờ đợi để gửi một "mega-PR" khổng lồ có thể khiến người review bị quá tải. Những PR nhỏ và thường xuyên hơn sẽ giúp dòng chảy công việc (workflow) trôi chảy hơn.
Thay đổi tư duy của bạn
Thay vì nghĩ: "Tôi cần phải gửi một sản phẩm hoàn chỉnh", hãy thử nghĩ: "Tôi đang chia sẻ tiến độ của mình để nhận ý kiến đóng góp".
Người review không ở đó để phán xét bạn. Họ ở đó để giúp dự án tốt hơn. Một vài lỗi nhỏ hay một gợi ý refactor không định nghĩa giá trị của bạn với tư cách là một lập trình viên; đó chỉ là một phần của quá trình.
Vì vậy, đừng suy nghĩ quá nhiều nữa. Hãy mở PR đó đi.
Optional learning community: https://t.me/GyaanSetuAi