Làm thế nào để các dự án nguồn mở có thể thành công mà không cần tài liệu về thiết kế hoặc kiến ​​trúc của chúng?

Tôi muốn cải thiện kỹ năng lập trình của mình bằng cách nghiên cứu các dự án nguồn mở nổi tiếng, nhưng tôi thấy rất dễ bị lạc khi chỉ cần nhảy vào mã nguồn của họ.

Vì vậy, tôi quyết định đọc tài liệu của họ về thiết kế hoặc kiến ​​trúc của họ (như sơ đồ UML) để có ý tưởng chung về tổ chức mã của họ trước tiên. Tuy nhiên, thật ngạc nhiên, tôi không thể tìm thấy bất kỳ tài liệu kiến ​​trúc nào cho các dự án nguồn mở lớn như Hibernate, Spring, ASP.NET MVC, Rails, v.v.

Vì vậy, tôi đã bắt đầu tự hỏi: Làm thế nào một dự án nguồn mở có thể thành công nếu các nhà phát triển mới không có tài liệu kiến ​​trúc / thiết kế để đọc hoặc nếu người quản lý dự án chỉ mở mã nguồn nhưng đóng tài liệu của nó?

tại sao một dự án nguồn mở có thể trở nên thành công nếu nhà phát triển new comer không có tài liệu kiến ​​trúc / thiết kế để đọc?

Giả định luôn luôn được đưa ra rằng bạn biết những gì bạn đang làm và có một sự hiểu biết khá mật thiết về những gì bạn sẽ (và mong đợi) sẽ thấy.

Ví dụ, nếu bạn nhìn vào mã PHP của khung công tác Symfony, bạn sẽ biết về việc tiêm phụ thuộc, các sự kiện, mô hình / khung nhìn / mẫu điều khiển, v.v.

Tương tự như vậy, nếu bạn đi sâu vào mã C của hạt nhân linux, giả định là bạn sẽ thực sự có năng lực về mô đun, tín hiệu, quy trình, luồng và những gì không. Bạn cũng sẽ có sở trường là ăn thập lục phân cả ngày và đào qua các bãi rác lõi bằng một cái xẻng khổng lồ.

Các nhà bảo trì sẽ không gặp phải rắc rối khi làm tài liệu kiến ​​trúc bởi vì đó thực sự là công cụ. Thỉnh thoảng, bạn sẽ tìm thấy một phác thảo về những gì nằm ở đâu trong cây nguồn. Thông thường hơn, cách tổ chức cây nguồn làm cho mọi thứ tự giải thích.

Nói tóm lại, nếu bạn thiếu bất kỳ kỹ năng nào mà các nhà bảo trì sẽ mong đợi bạn biết vào thời điểm bạn xem mã của họ, có lẽ bạn đang đào sâu vào những thứ vượt quá mức lương của bạn. Làm quen với các khái niệm trước tiên - Mô hình MVC là gì? Tiêm phụ thuộc là gì? V.v ... Sau đó lặn xuống.

Hầu hết các dự án nguồn mở thành công đều trở nên thành công bởi vì trước hết, chương trình này rất ấn tượng hoặc đã làm một điều gì đó mà không chương trình nào có thể làm vào thời điểm đó. Điều đó không nhất thiết có nghĩa là nguồn được ghi chép tốt, vì các lập trình viên bắt đầu dự án bắt đầu biết mã đủ rõ để không cần nó. Đó là một thực tế đáng tiếc rằng các dự án nguồn mở không cần phải được ghi chép đầy đủ. Nó phải là một chương trình tốt hoặc là một chương trình tầm thường nhưng được ghi chép đầy đủ để các lập trình viên thể hiện sự quan tâm đến nó.

Bởi vì các nhà phát triển nguồn mở thường tài năng và cũng chọn dự án trong lĩnh vực chuyên môn của họ, họ đã có "tài liệu" trong hộp sọ của họ. Với ít sự phóng đại, tài liệu kỹ lưỡng chỉ cần thiết nếu bạn thiếu bất kỳ thứ nào trong số đó: o)

Thành thật mà nói, tôi không thực sự đọc "tài liệu" khi đối mặt với cơ sở mã không xác định. Giới thiệu nhanh, có thể một vài phác thảo khái niệm và đi thẳng vào mã! Thử nghiệm, thử những thay đổi nhỏ. Hoạt động hoàn hảo cho mã được thiết kế tốt. Nếu tôi phải đối mặt với mớ hỗn độn khủng khiếp, thì cách tốt nhất để tìm hiểu chúng là tái cấu trúc từng chút một để cải thiện sự rõ ràng (lý tưởng nhất là với sự trợ giúp của kiểm tra đơn vị).

Lý do bổ sung có thể là rễ thiết kế hữu cơ đơn giản của các dự án này. Kiến trúc sau đó là tầm nhìn phát triển trong tâm trí của các nhà phát triển hơn là thực thể "tài liệu" đã nêu.

Lý do các tài liệu như vậy thường không tồn tại khá đơn giản: Lập trình viên thích lập trình, không viết tài liệu. Đặc biệt với các dự án nguồn mở, mà các nhà phát triển thường đóng góp trong thời gian rảnh / rảnh rỗi.

Về cơ bản, viết tài liệu là không vui. Và nếu họ không được trả tiền cho nó, ai muốn dành thời gian rảnh của họ để làm điều gì đó không vui?