Cách học từ nguồn mở

Tôi thấy vấn đề này khá thường xuyên. Tôi thích một đề xuất giá trị nhất định của một dự án nguồn mở. Tôi thử các hướng dẫn cơ bản. Tuyệt quá. Nó hoạt động! Nhưng nếu tôi chuyển sang các vấn đề phức tạp hơn, tôi dành hàng giờ để nghiên cứu, gỡ lỗi, thất vọng, v.v.

Các chiến lược của bạn để giữ động lực trong nguồn mở là gì? Phần thưởng của nguồn mở sau thành công của các hướng dẫn cơ bản là gì? "Thành công" nào của nguồn mở mà bạn đã trải nghiệm?

Tôi giả sử bạn đang xem các thư viện nguồn mở nhỏ như các thư viện được tìm thấy trên github. Trong trường hợp của tôi, tôi thường sử dụng một để giải quyết một vấn đề cụ thể. Nếu nó không giải quyết được một cách sạch sẽ, thì tôi sẽ tìm hiểu, tìm hiểu cách thức hoạt động của mã và thực hiện các thay đổi khi cần thiết. Nếu thay đổi của tôi là vì một cái gì đó hữu ích hoặc sửa lỗi, tôi sẽ cố gắng liên hệ với chủ sở hữu nguồn mở hoặc rẽ nhánh chi nhánh của riêng tôi.

Những lần khác, tôi chỉ thích nghi một cái gì đó gần với nhu cầu của mình, trong những trường hợp đó, tôi chỉ giữ những thay đổi của mình và tiếp tục. Tôi thêm đồng hồ hoặc kiểm tra lại thường xuyên để xem những gì đã được cập nhật.

Như trong các ghi chú mặc dù, đây là cuộc sống của phát triển phần mềm. Đó là một môi trường luôn thay đổi.

Bạn hỏi làm thế nào bạn giữ được động lực trong việc sử dụng một dự án API nguồn mở nhất định?

Bí quyết là tìm ra các dự án Nguồn mở nào là những dự án tốt. Trình độ chuyên môn chính trong Nguồn mở là việc bạn có quyền truy cập vào mã nguồn, điều này cực kỳ hữu ích khi bạn cần tìm hiểu cách mọi thứ hoạt động (điều này thường xảy ra khi bạn cần thay đổi hành vi trong một số tình huống), nhưng điều này không ngụ ý bất cứ điều gì khác hơn thế. Điều này bao gồm chất lượng của dự án hoàn toàn không liên quan đến tính mở của nguồn.

Chất lượng bao gồm một số điều ít nhiều tinh tế khi nói về một dự án mã:

• API được thiết kế tốt như thế nào? Có phải mã bạn cần viết để thực sự gọi API đọc dễ dàng không?
• Mã thực tế được viết như thế nào trong API? Có dễ hiểu những gì đang diễn ra? Các cấu trúc dữ liệu được chọn tốt và không có các đặc điểm thời gian chạy đắt tiền? Là tên biến được lựa chọn tốt? Liệu mã phù hợp với một tiêu chuẩn mã hóa?
• API có được ghi lại không? Đây là cả thiết kế và javadoc của mã thực tế, và nó có hữu ích không? Điều này quan trọng hơn bạn nghĩ, vì nó cho thấy sự trưởng thành của mã.
• Dự án có một trang web? Được cập nhật và không có liên kết bị hỏng? Nó có cung cấp quyền truy cập dễ dàng vào mã nguồn, tải xuống và tài liệu không?
• Dự án có một cộng đồng và danh sách gửi thư? Là tài liệu lưu trữ có sẵn và có thể truy cập? Cộng đồng có hữu ích không?

Tất cả những điều này hữu ích để ghi nhớ khi lựa chọn nếu bạn muốn sử dụng một dự án nguồn mở nhất định hay không. Bất kỳ sự phát sinh nào từ điều tốt nhất sẽ khiến một dấu hiệu cảnh báo lóe lên trong đầu bạn vì đó là một dấu hiệu cho thấy đây không phải là một dự án tốt nhất.

Sau đó, khi bạn tìm thấy dự án, bạn thích những gì bạn thấy, đó là bài kiểm tra cuối cùng:

• Làm thế nào khó khăn để đứng dậy và chạy lại từ đầu với một chương trình đơn giản gọi API theo cách hữu ích?

Điều này nên

1. giải thích ở vị trí dễ phát hiện trên trang web của dự án và / hoặc trong tài liệu trong gói tải xuống.
2. dễ dàng để có được quyền - tài liệu phải chính xác, chương trình đơn giản để viết hoặc điều chỉnh từ một ví dụ đơn giản nhất định, và cả được giải thích tốt và dễ hiểu.
3. nhanh chóng để có được quyền - nếu bạn cần thực hiện bất kỳ gỡ lỗi nào tại thời điểm này để chương trình chạy như được giải thích, có gì đó rất sai.

Nếu rõ ràng đây là trường hợp sử dụng được dự đoán và ưu tiên, thì điều này sẽ đơn giản không đáng kể. Nếu rõ ràng là dự án không quan tâm đến điều đặc biệt này, thì tôi sẽ cân nhắc mạnh mẽ việc không sử dụng nó! Nếu nó là khó khăn ở đây, nó sẽ khó khăn nhiều lần, nhiều lần sau đó, và sẽ tốt hơn nếu không sử dụng nó.