Cộng đồng phát triển phần mềm đang tham gia vào một cuộc tranh luận sôi nổi về quy mô và cấu trúc tối ưu của các pull request ( PR ), được khởi phát bởi các khuyến nghị từ một bài thuyết trình hội thảo gần đây ủng hộ việc code review nhỏ hơn và hướng theo câu chuyện.
 |
|---|
| Một diễn giả đang tương tác với khán giả tại hội nghị về các chiến lược pull request |
Tiêu chuẩn Review 5-10 phút
Một phong trào đang phát triển cho rằng các pull request nên có thể được review chỉ trong 5-10 phút, với các thay đổi giới hạn khoảng 300 dòng code. Những người ủng hộ lập luận rằng cách tiếp cận này dẫn đến các review chất lượng cao hơn và chu kỳ phát triển nhanh hơn. Họ tin rằng khi các thay đổi nhỏ và tập trung, những người review có thể cung cấp phản hồi chu đáo hơn thay vì chỉ đóng dấu cao su cho các bài nộp lớn, phức tạp với một câu đơn giản Looks Good To Me ( LGTM ).
Tuy nhiên, nhiều nhà phát triển có kinh nghiệm phản đối cách tiếp cận cứng nhắc này. Họ lập luận rằng việc chia nhỏ các tính năng thành những phần nhỏ một cách giả tạo thực sự có thể làm cho việc review khó khăn hơn bằng cách che khuất bức tranh tổng thể và tạo ra sự phức tạp không cần thiết trong việc quản lý nhiều thay đổi phụ thuộc lẫn nhau.
Hướng dẫn PR được khuyến nghị:
- Kích thước: 300 dòng code (500+ dòng được coi là không thể review được)
- Thời gian review: 5-10 phút cho reviewer trung bình
- Cấu trúc commit: 13 commit cho 152 dòng thay đổi code (trường hợp ví dụ)
- Tập trung: Tối đa một thay đổi gây tranh cãi cho mỗi PR
Tranh cãi về Commit Story
Một điểm gây tranh cãi khác liên quan đến việc tạo ra các commit kể một câu chuyện mạch lạc về cách code phát triển. Những người ủng hộ đề xuất rằng mỗi commit nên đại diện cho một bước logic trong quá trình phát triển, giúp những người review dễ dàng theo dõi quá trình suy nghĩ của nhà phát triển. Cách tiếp cận này coi các commit như các chương trong một cuốn sách, mỗi chương xây dựng dựa trên chương trước đó.
Những người chỉ trích thấy thực hành này tốn thời gian và đặt câu hỏi về giá trị thực tế của nó. Nhiều nhà phát triển báo cáo rằng những người review hiếm khi đọc từng commit message riêng lẻ trong quá trình PR review, khiến cho nỗ lực tạo ra những commit story hoàn hảo cảm thấy như lãng phí thời gian.
Không ai đọc từng commit message trung gian một cách riêng lẻ trên một PR , chấm hết. Tôi đã làm việc trong một team mà lead rất khăng khăng về điều này và bắt đầu viết các message theo kiểu 'nếu bạn đang đọc message này, tôi sẽ cho bạn 5 đô la'. Tôi chưa bao giờ trả cho ai một đô la nào.
Công cụ phát triển thay thế:
- Jujutsu (jj): Hệ thống kiểm soát phiên bản được thiết kế cho các nhánh xếp chồng
- Graphite: Công cụ quản lý các PR xếp chồng trên nền tảng Git
- Git-branchless: Tiện ích mở rộng để quản lý nhánh tốt hơn
- Sapling: Hệ thống kiểm soát phiên bản của Meta với hỗ trợ stack
Self-Review như một giải pháp
Một lĩnh vực mà các nhà phát triển dường như tìm thấy sự đồng thuận nhiều hơn là thực hành self-review các pull request trước khi nộp chúng. Nhiều người báo cáo rằng việc thêm các comment và giải thích của chính họ vào PR cải thiện đáng kể trải nghiệm review cho các đồng nghiệp. Cách tiếp cận này giúp phát hiện bug sớm và cung cấp bối cảnh quan trọng có thể không rõ ràng chỉ từ code.
Self-review cũng giải quyết mối quan ngại ngày càng tăng về các bài nộp code được tạo bởi AI , nơi các nhà phát triển có thể không hiểu đầy đủ những thay đổi họ đang đề xuất. Bằng cách buộc các tác giả phải kiểm tra công việc của chính họ một cách phê phán, các team có thể duy trì chất lượng code ngay cả khi các thực hành phát triển phát triển.
Thực hành tốt nhất cho tự đánh giá:
- Thêm các bình luận giải thích trước khi yêu cầu đánh giá
- Sử dụng hệ thống bình luận của GitHub/GitLab để cung cấp ngữ cảnh
- Giải thích các quyết định code không rõ ràng ngay trong dòng
- Bao gồm bằng chứng kiểm thử và lý do của phương pháp tiếp cận
- Chủ động giải quyết các câu hỏi tiềm năng của người đánh giá
Thử thách về công cụ
Cuộc tranh luận tiết lộ ma sát đáng kể với các công cụ phát triển hiện tại, đặc biệt là giao diện của Git và GitHub để review các commit riêng lẻ. Nhiều nhà phát triển muốn tạo ra lịch sử commit tốt hơn thấy mình đang đấu tranh với các công cụ không được thiết kế cho workflow này. Các hệ thống kiểm soát phiên bản thay thế như Jujutsu và các công cụ chuyên biệt như Graphite đang xuất hiện để giải quyết những hạn chế này.
Cuộc thảo luận làm nổi bật một căng thẳng cơ bản trong phát triển phần mềm hiện đại giữa việc di chuyển nhanh và duy trì chất lượng. Mặc dù không có giải pháp phổ quát, cộng đồng dường như đồng ý rằng chìa khóa nằm ở việc thích ứng các thực hành để phù hợp với nhu cầu của team thay vì tuân thủ cứng nhắc bất kỳ cách tiếp cận đơn lẻ nào. Các team thành công nhất dường như là những team ưu tiên giao tiếp rõ ràng và tôn trọng lẫn nhau hơn là tuân thủ nghiêm ngặt các giới hạn kích thước PR cụ thể hoặc định dạng commit message.
Tham khảo: The Theatre of Pull Requests and Code Review