Tại sao một số thư viện opensouce thiếu ý kiến?

Tôi không biết điều này có xảy ra với hầu hết các thư viện Opensource hay không, nhưng nhiều người trong số tôi biết và sử dụng (ví dụ OpenSSL, Webkit, ...) tất cả họ đều thiếu bình luận hoặc chứa rất ít bình luận.

Chưa kể rất ít tài liệu của họ, thật khó để đọc mã nguồn của họ. Chúng ta khó có thể hiểu một biến thành viên có nghĩa là gì, hoặc chức năng này làm gì. Điều này dường như chống lại thực hành tiêu chuẩn mã hóa

Tại sao vậy? Làm thế nào mọi người có thể cộng tác với các nguồn mở này với rất ít ý kiến?

Viết mã nguồn là niềm vui.

Viết tài liệu và mã nhận xét là ít vui vẻ.

Khi một nhà phát triển làm việc trong một công ty thực thi các bình luận và tài liệu tốt, không có lựa chọn nào: nhà phát triển này viết những điều đó, hoặc anh ta có nguy cơ bị sa thải.

Khi một nhà phát triển đóng góp cho một dự án nguồn mở, anh ta đang làm nó miễn phí và đặc biệt là để giải trí. Không có ai buộc nhà phát triển này làm những việc mà anh ta không sẵn sàng làm, như viết tài liệu và bình luận.

Đó là lý do tại sao nhiều dự án nguồn mở thiếu tài liệu và bình luận sâu rộng.

Làm thế nào mọi người vẫn có thể đóng góp cho các dự án nguồn mở mà không có tài liệu hoặc ý kiến?

• Nếu mã nguồn có chất lượng cao, không cần bình luận quá nhiều. Các ý kiến ​​về giao diện công cộng và tài liệu đặc biệt hữu ích cho người tiêu dùng dự án, tức là các nhà phát triển chỉ đơn giản sử dụng thư viện, không đóng góp cho họ.

• Không có yếu tố năng suất liên quan. Tôi đang làm việc trong một công ty nơi codebase thực tế không có bài kiểm tra đơn vị, không có tài liệu và không có ý kiến. Tôi dành nhiều thời gian để tìm hiểu xem phương pháp 600 LỘC đang làm gì hoặc mã hóa những thứ đã được thực hiện, nhưng không thể khám phá được vì thiếu tài liệu, vì vậy, hầu hết thời gian, tôi chỉ đơn giản là lãng phí tiền của công ty thay vì làm gì đó quý giá.

  Mặt khác, đối với một dự án nguồn mở, sẽ không có vấn đề gì nếu một trong những người đóng góp lãng phí một tuần vì thiếu tài liệu hoặc nhận xét thích hợp. Điều tồi tệ nhất có thể xảy ra là người đóng góp này sẽ rời khỏi dự án.

  Khám phá mã mà không có ý kiến ​​hoặc tài liệu thậm chí có thể là thách thức, tức là thu hút một số người đóng góp, thay vì làm họ nản lòng.

• Trong các dự án doanh nghiệp, không có gì lạ khi một nhà phát triển buộc phải làm việc trên mọi khía cạnh của sản phẩm, và, vài năm sau, phải biết gần như toàn bộ hệ thống. Trong một dự án nguồn mở, không ai bắt bạn phải biết toàn bộ. Bạn chỉ có thể đóng góp cho một phần nhỏ của nó, và có kiến ​​thức tuyệt vời về phần này, mà không cần bất kỳ tài liệu nào.

Nhiều lý do.

• Viết tài liệu không thú vị và đối với nhiều dự án, cơ sở người dùng là nhóm lập trình; mọi người đều biết mã này nói về cái gì, vì vậy tài liệu không thực sự được xem là một khía cạnh quan trọng của dự án.
• Tài liệu có thể (và sẽ) trở nên lỗi thời, và tài liệu lỗi thời là tồi tệ hơn không có gì cả. Điều này có nghĩa là tài liệu là một trách nhiệm bổ sung và có thể ảnh hưởng đến tính linh hoạt của cơ sở mã của bạn (nhiều tài liệu hơn có nghĩa là cho bất kỳ thay đổi nào bạn sẽ phải cập nhật mã và tài liệu). Đặc biệt đối với các dự án nguồn mở rất cụ thể, đây thực sự là một đối số hợp lệ để nhắm đến tài liệu tối thiểu và viết mã có thể đọc được thay thế.
• Tính kinh tế của phần mềm nguồn mở là khác nhau. Mặc dù thật tốt khi có những người đóng góp cho dự án của bạn, nhiều dự án là những dự án kiểu đầu tiên mà tác giả đã viết để giải quyết một vấn đề cụ thể và sau đó chỉ cần đưa ra ngoài trời. Vì về cơ bản bạn đang ăn vụn bánh mì của người khác, nên thái độ là bạn không có nhu cầu gì cả, chứ đừng nói đến tài liệu.

Làm thế nào mọi người có thể cộng tác với các nguồn mở này với rất ít ý kiến

Giả sử bạn có nghĩa là "Làm thế nào mọi người có thể cộng tác với các mã nguồn mở khó đọc này" - tôi đoán một dự án nguồn mở với mã xấu sẽ đơn giản có ít người đóng góp hơn so với mã tốt. Nhưng đừng quên rằng tính dễ đọc của mã luôn nằm trong mắt của người theo dõi và hầu hết mã nguồn mở không tệ đến mức bạn không thể hiểu ít nhất một chút hoặc ý định của một số chức năng và lớp.

Thông thường, khi bạn muốn đóng góp một cái gì đó cho một dự án nguồn mở, bạn không cần phải hiểu toàn bộ, chỉ những phần mà bạn muốn thêm một tính năng cụ thể. Vì vậy, nếu một nhà phát triển có nhu cầu về một tính năng bị thiếu, rất có thể anh ta sẽ cắn viên đạn, xác định các phần anh ta cần thay đổi, "giải mã" các phần đó về mặt tinh thần và thêm các tính năng mới ở đó. Nếu anh ấy là một người tốt, anh ấy cũng sẽ cố gắng xem xét và cấu trúc lại các phần "được giải mã", nhưng tôi đoán trong thực tế điều này sẽ xảy ra quá hiếm khi.