Khi bạn tìm thấy một thư viện / dự án nguồn mở mới, bạn sẽ xem xét các tiêu chí nào trước khi kết hợp nó vào cơ sở nguồn của bạn.
Có câu hỏi pháp lý nào bạn cần trả lời không?
Bạn có tìm kiếm một lượng vận tốc phát triển nhất định không?
Là cộng đồng buzz một lý do đủ tốt?
Quyết định của bạn có thay đổi nếu bạn là người trực tuyến cho dự án không?
Sự phức tạp của tên miền hoặc mã có thay đổi cách bạn nghĩ về nó không?
Câu trả lời:
Đây là danh sách kiểm tra của tôi về sự trưởng thành của dự án:
Dự án đã đạt được cột mốc ban đầu?
Tôi sẽ tránh thêm bất kỳ mã nào nếu nó không đạt được cột mốc ban đầu. Tôi không khuyên bạn nên luôn tin tưởng một nhà phát triển tuyên bố rằng dự án của anh ta đã sẵn sàng sản xuất và luôn cố gắng đánh giá các tuyên bố đó, nhưng bạn chắc chắn nên tin tưởng cô ấy khi cô ấy nói với bạn rằng không, tức là gắn nhãn phần mềm là phiên bản 0.x, alpha, beta, phát hành ứng cử viên và như vậy.
Có tài liệu đầy đủ?
Một dự án hoàn hảo sẽ cung cấp:
Các nhà phát triển vẫn cam kết với dự án?
Bạn không bao giờ có thể biết liệu các nhà phát triển sẽ duy trì cam kết trong tương lai hay không, trừ khi tất nhiên đó là dự án được hỗ trợ bởi nền tảng / công ty. Nhưng bạn hầu như luôn có thể biết nếu họ cam kết ngay bây giờ, bằng cách kiểm tra:
Ngoài ra một chỉ số tốt về sự trưởng thành của dự án là một thế hệ các nhà phát triển, các nhà phát triển tích cực đã tham gia sau các cột mốc ban đầu.
Các nhà phát triển có thể truy cập?
Bây giờ, cho câu hỏi cụ thể hơn của bạn:
Vận tốc
Trong một dự án với trình theo dõi vấn đề công cộng, tôi chắc chắn sẽ kiểm tra xem phải mất bao nhiêu thời gian để các vấn đề được đóng lại. Tất nhiên tốc độ không phải lúc nào cũng có nghĩa là chất lượng, vì vậy tôi có thể giải quyết các vấn đề đóng, chọn một vài điều tôi cho là quan trọng và đánh giá thời gian và chất lượng phản hồi của nhà phát triển.
Tương thích giấy phép
Đối với các vấn đề pháp lý, không bao giờ tích hợp một dự án nguồn mở trong cơ sở mã của bạn nếu bạn không chắc chắn 100% rằng việc sử dụng nó tương thích với giấy phép của nó. Nếu nghi ngờ, bạn luôn có thể hỏi các nhà phát triển dự án, hoặc thậm chí hỏi ở đây.
Sự cường điệu của cộng đồng
Bạn nên luôn luôn đánh giá sự cường điệu. Khuyến nghị từ các nhà phát triển đồng nghiệp là hầu như luôn là một chỉ số đủ tốt về sự trưởng thành của dự án.
Mỗi mục trong danh sách kiểm tra là tùy chọn, ngoại trừ tương thích giấy phép. Tôi đã tích hợp rất nhiều dự án đã chết và không có giấy tờ trong mã của mình, nó luôn phụ thuộc vào nhu cầu cụ thể của bạn là gì và cách bạn thấy mã của mình phát triển.
Ngoài câu trả lời được nêu bởi Yannis Rizos, tôi sẽ thử nó trong một dự án thử nghiệm hoặc mặt ngắn nếu có thể. Điều này sẽ cho phép bạn làm quen với các yêu cầu của sản phẩm trước khi bất kỳ điều quan trọng nào bị đe dọa. Dự án không nên quá nhỏ, vì điều này sẽ khiến quá nhiều codebase chưa được khám phá. Hãy quay nó để xem liệu có thể làm những gì bạn muốn từ nó mà không gặp quá nhiều rắc rối. Nếu bạn không thể tự mình làm việc cơ bản với sự trợ giúp của tài liệu và một hoặc hai câu hỏi cho cộng đồng dự án, bạn có thể muốn xem xét tìm kiếm một cơ sở mã được hỗ trợ phù hợp hơn. Nếu thử nghiệm ban đầu phù hợp với bạn, bạn có thể bắt đầu sử dụng nó thực sự. Tôi đã phải đối phó với vấn đề này trong quá khứ và sau hai lần đầu tiên, tôi đã tự biến nó thành một quy tắc để thử nghiệm những điều mới trước khi đưa nó vào sản xuất,
BP khôn ngoan: giới thiệu những thứ mới không bao giờ nên được thực hiện mà không có một số hình thức của giai đoạn chuẩn bị / học tập.