Cộng đồng phát triển phần mềm đang tham gia vào một cuộc thảo luận sôi nổi về trunk-based development (TBD), một phương pháp lập trình yêu cầu các nhà phát triển đẩy thay đổi trực tiếp lên nhánh chính thay vì sử dụng feature branches và pull requests. Trong khi những người ủng hộ tuyên bố rằng nó dẫn đến code chất lượng cao hơn và giao hàng nhanh hơn, nhiều nhà phát triển giàu kinh nghiệm đang phản đối với những lo ngại thực tế.
Khoảng cách giữa Lời hứa và Thực tế
Những người ủng hộ trunk-based development cho rằng việc mọi người làm việc trên một nhánh chính duy nhất tạo ra sự hợp tác tốt hơn và phát hiện lỗi sớm hơn. Lý thuyết cho rằng khi code được sử dụng ngay lập tức bởi toàn bộ team, các vấn đề sẽ nổi lên nhanh chóng và có thể được khắc phục khi chúng vẫn còn nhỏ. Các công ty như Google và Netflix được báo cáo đã sử dụng phương pháp này thành công, ngay cả ở quy mô lớn.
Tuy nhiên, nhiều nhà phát triển trong cộng đồng báo cáo một trải nghiệm khác. Họ nhận thấy rằng mặc dù TBD nghe có vẻ tốt trên lý thuyết, nhưng nó thường trở nên lộn xộn trong thực tế, đặc biệt là đối với các team làm việc từ xa. Việc thiếu các cổng code review có nghĩa là các vấn đề về chất lượng có thể trượt qua dễ dàng hơn, và áp lực giữ cho nhánh chính ổn định thực sự có thể làm chậm quá trình phát triển khi có sự cố xảy ra.
Các Lợi Ích Chính Của Trunk-Based Development (Theo Những Người Ủng Hộ):
- Tích hợp liên tục tất cả các đóng góp mã nguồn
- Vòng phản hồi nhanh hơn và phát hiện lỗi sớm hơn
- Giảm xung đột merge và tồn kho công việc đang thực hiện
- Tăng cường hợp tác nhóm và quyền sở hữu mã nguồn tập thể
- Quy trình làm việc đơn giản hóa với ít lệnh kiểm soát phiên bản hơn
- Thời gian ra thị trường nhanh hơn và giảm chi phí phát triển
Tranh cãi về Pull Request
Một trong những điểm gây tranh cãi nhất trong cuộc tranh luận tập trung xung quanh pull requests (PRs). Những người theo chủ nghĩa TBD thuần túy cho rằng PRs tạo ra môi trường thiếu tin tưởng và làm chậm quá trình phát triển. Họ tuyên bố rằng việc yêu cầu code reviews trước khi merge cho thấy các thành viên trong team không tin tưởng lẫn nhau để viết code tốt.
Nhiều nhà phát triển mạnh mẽ không đồng ý với cách mô tả này. Họ xem PRs như những công cụ học tập có giá trị giúp các team chia sẻ kiến thức và duy trì các tiêu chuẩn lập trình. Code reviews không chỉ là để bắt lỗi - chúng còn là để hướng dẫn các nhà phát triển junior, lan truyền kiến thức về domain, và đảm bảo mọi người hiểu codebase đang phát triển như thế nào.
PRs rất tuyệt vời cho việc chia sẻ ngữ cảnh. Bạn có thể nhận được các comment inline, CI chạy, bạn có thể test mọi thứ một cách độc lập bằng cách khởi động infra, và các đồng nghiệp thực sự thấy được những gì đang thay đổi.
Ngữ cảnh quan trọng hơn Phương pháp
Có lẽ quan sát sâu sắc nhất từ cuộc thảo luận cộng đồng là thành phần team và yêu cầu dự án quan trọng hơn nhiều so với phương pháp phát triển cụ thể được chọn. Một số nhà phát triển giàu kinh nghiệm lưu ý rằng các team kỹ thuật tốt có xu hướng tự tổ chức xung quanh các thực hành phù hợp với tình huống cụ thể của họ, bất kể bài blog mới nhất khuyến nghị gì.
Đối với các team nhỏ, cùng địa điểm làm việc trên các ứng dụng web với vòng phản hồi nhanh, việc commit trực tiếp lên main có thể hoạt động tốt. Nhưng đối với các team lớn hơn, các ngành được quản lý, hoặc các dự án có chu kỳ testing dài hơn, các lưới an toàn được cung cấp bởi feature branches và code reviews trở nên thiết yếu. Điều quan trọng là khớp quy trình với nhu cầu của team thay vì tuân theo một phương pháp phù hợp với tất cả.
Các mối quan tâm phổ biến được các nhà phát triển nêu ra:
- Khó khăn trong việc duy trì chất lượng code mà không có đánh giá PR
- Thách thức đối với các nhóm làm việc từ xa và phân tán
- Rủi ro làm hỏng nhánh chính ảnh hưởng đến năng suất của toàn bộ nhóm
- Ít phù hợp cho các ngành công nghiệp được quản lý chặt chẽ yêu cầu tuân thủ quy định
- Đòi hỏi các nhóm phát triển có kỹ năng cao và kỷ luật
- Có thể không hoạt động tốt cho các dự án có chu kỳ kiểm thử dài hơn
Điểm giữa
Nhiều team thành công đã nhận ra rằng cuộc tranh luận không thực sự là về việc chọn lựa giữa các vị trí cực đoan. Thay vì hoàn toàn từ bỏ branches hoặc tuân theo nghiêm ngặt các chiến lược branching phức tạp, họ sử dụng các feature branches ngắn hạn với PR turnarounds nhanh. Phương pháp này nắm bắt nhiều lợi ích của trunk-based development trong khi duy trì các biện pháp bảo vệ chất lượng code.
Cuộc thảo luận tiết lộ rằng các yếu tố quan trọng nhất cho việc giao hàng phần mềm thành công không phải là về các chiến lược branching cụ thể, mà là về việc có các thành viên team có kỹ năng quan tâm đến công việc của họ, automated testing tốt, và giao tiếp rõ ràng. Cho dù bạn sử dụng trunk-based development hay feature branches, những điều cơ bản này vẫn rất quan trọng để xây dựng phần mềm chất lượng một cách hiệu quả.
Tham khảo: ON THE BENEFITS OF TRUNK-BASED DEVELOPMENT