Có đánh giá mã trong các dự án mã nguồn mở? Nếu vậy, những công cụ được sử dụng để làm điều này?

Tôi biết có một sự thúc đẩy lớn cho các đánh giá mã trong phát triển thương mại. Tuy nhiên, các đánh giá mã được sử dụng trong phần mềm nguồn mở hay dựa trên niềm tin? Nếu vậy, thì họ được thực hiện như thế nào? [Đây có phải là một cam kết bị trì hoãn, "môi trường cam kết trước", có công cụ nào cho phép bản vá được gửi đến nhà phát triển khác không]?

Có dự án nào sử dụng đánh giá mã?

Theo hiểu biết của tôi, nhân Linux chủ yếu dựa trên sự tin tưởng của người đi làm. MySQL dựa trên sự chấp thuận của tác giả chính và tác động hiệu suất.

Hầu như tất cả các dự án nguồn mở đều sử dụng một số quy trình công việc của người gác cổng, trong đó một người hoặc một nhóm người phải đăng xuất trên tất cả các thay đổi để đi vào bản dựng chính thức. Một số dự án lớn hơn, như nhân Linux, có các lớp người gác cổng. Bạn gửi một thay đổi cho ai đó quản lý một khu vực của một hệ thống con, họ gửi các thay đổi của họ cho một người quản lý toàn bộ hệ thống con và họ gửi các thay đổi của họ cho Linus Torvalds, người đôi khi tự mình xem lại mã hoặc đôi khi tin tưởng các trung úy của mình. Những đánh giá này thường không có cấu trúc chính thức. Nó chỉ là một ai đó tìm mã trước khi nó được hợp nhất.

Theo như các công cụ, hãy xem cơ chế yêu cầu kéo trên github để biết ví dụ hay. Bạn thực hiện một yêu cầu kéo và trên một trang web dành riêng cho yêu cầu kéo đó mọi người đưa ra nhận xét và tác giả thực hiện sửa đổi cho đến khi nó đủ tốt để chấp nhận. Những người gác cổng khác chỉ sử dụng git đơn giản để áp dụng các bản vá từ danh sách gửi thư hoặc hợp nhất các yêu cầu kéo từ kho lưu trữ công cộng, đó là một trong những lý do chính khiến DVCS như git được phát minh.

Các dự án nguồn mở thường có (và nên, nếu chúng không) một bộ "nguyên tắc cộng đồng" được xuất bản rõ ràng, thường bao gồm một mô tả về quy trình làm việc của dự án và cách đóng góp được chấp nhận (và do đó chúng được kiểm tra) như thế nào như quá trình để trở thành một người đi làm cốt lõi.

Theo như đánh giá mã, một lần nữa nó phụ thuộc vào cộng đồng nhưng các hướng dẫn thường được làm rõ. Một số hướng dẫn ví dụ về đóng góp của những người không phải là thành viên từ "mã làm việc chiến thắng" đến "đóng góp phải có phạm vi và tài liệu kiểm tra đầy đủ, với các thử nghiệm được cam kết cùng lúc với mã" và mọi thứ ở giữa; Bất kể các hướng dẫn này, một hướng dẫn được ngụ ý là các ủy viên chính sẽ xem xét bất kỳ và tất cả các đóng góp từ những người không tham gia trước khi chấp nhận chúng.

Các dự án nguồn mở với các nhóm ủy viên cốt lõi cũng thường có các cuộc họp ảo hoặc dành thời gian để thảo luận về bất kỳ đóng góp nào có thể cần thêm đôi mắt - giống như quy trình SE của nhiều người bỏ phiếu gần gũi trước khi một câu hỏi bị đóng, và thảo luận về những điều đáng ngờ thông qua meta hoặc trò chuyện.

Dưới đây là một vài liên kết nhanh đến một số tài liệu cộng đồng mẫu cho các dự án tôi biết rõ nhất, nơi bạn có thể tìm thấy câu trả lời cho câu hỏi của mình cụ thể cho các dự án này (bạn sẽ sớm nhận thấy một chủ đề):

• Nguyên tắc cộng đồng dự án Blacklight
• Hướng dẫn đóng góp mã DSpace
• Hướng dẫn công nghệ đóng góp Apache

Các dự án OSS lớn hơn sẽ có một số ủy viên chính. Vì vậy, tôi đoán họ là "người đánh giá mã" thực tế.

Ngoài ra, vì mã OSS về bản chất là mở cho mọi người nên có nhiều khả năng sẽ thảo luận nhiều hơn về mã bạn đang viết. Mặc dù điều này có thể không ở dạng đánh giá mã chính thức, bạn chắc chắn sẽ tìm ra nếu mã của bạn không được xem xét để trầy xước cho một dự án OSS cụ thể.