Có tệ không khi tham gia các dự án nguồn mở như một người nghiệp dư?

Tôi đã suy nghĩ khoảng sáu tháng nay rằng tôi nên tham gia một dự án iPhone hoặc iPad nguồn mở để trau dồi kỹ năng của mình trong Objective-C, nhưng mỗi lần tôi làm điều đó, tôi thấy hàng ngàn dòng mã về các dự án lớn mà tôi cuối cùng thuyết phục bản thân tôi sẽ không bao giờ hiểu. Tôi luôn nghĩ rằng các cam kết của tôi cuối cùng sẽ gây rắc rối cho các quản trị viên dự án và những người đóng góp cao cấp hơn, vì vậy tôi luôn rút lui vào giây cuối cùng.

Câu hỏi của tôi về cơ bản là, nó có rắc rối không khi một lập trình viên có kinh nghiệm trung gian tham gia vào một dự án nguồn mở?

Không, không phải vậy.

Nếu cơ sở mã của các dự án bạn nhìn vào quá khó khăn, hãy xem xét:

• Chọn một dự án (thậm chí) nhỏ hơn để làm việc.
• Chọn một nhiệm vụ nhỏ hơn trong dự án:
  • Viết một ví dụ / hướng dẫn / demo cho một cái gì đó
  • Cập nhật và sửa tài liệu (tất cả các dự án, HĐH hoặc không, cần tài liệu tốt hơn)
  • Khắc phục nhiều lỗi ưu tiên thấp nhưng dễ sửa (tiếp xúc nhiều với mã, các nhà phát triển thường vui vẻ, rủi ro thấp)
• Có nhiều cách để đóng góp mà không cần quyền truy cập vào nguồn cốt lõi, chẳng hạn như:
  • Đệ trình các bản vá, có thể được nhận xét về.
  • Ngã ba và gửi yêu cầu kéo (xem ở trên)
  • Ngã ba và tự mình đi làm, chỉ để xem nó đưa bạn đến đâu. Nếu bạn hài lòng, hãy yêu cầu các nhà phát triển xem xét bất cứ điều gì bạn đã làm để xem nó có hợp lý không.

Để vượt qua "nỗi sợ" của bạn về việc không chấp nhận cam kết của bạn, hãy đi đến điểm an toàn lúc đầu. Điều này sẽ cho phép cả bạn và nhóm phát triển có được sự tự tin trong mối quan hệ của bạn và tìm hiểu cách suy nghĩ của nhau. Khi bạn cải thiện (cả về kỹ năng, kinh nghiệm, chất lượng mã và sự hiểu biết về nhóm dự án hệ điều hành của bạn và tính năng động của nó), bạn sẽ có thể giải quyết công việc lớn hơn trong khi giới thiệu ít rắc rối hơn.

Nó cũng giúp trong việc yêu cầu điểm bắt đầu phù hợp và xem những gì nhóm có thể tìm thấy phù hợp với bạn.

Ví dụ, tôi đã đóng góp một chút cho Buildbot trong những năm qua. Tôi bắt đầu chỉ sửa một vài vấn đề nhỏ, sau đó tôi đã vượt qua chất lượng của các bước nguồn Mercurial bằng cách sửa một số lỗi phát sáng. Cuối cùng, tôi viết lại hầu hết các trang Web và hoán đổi việc dán mã html vào một giải pháp tạo HTML dựa trên mẫu. Sau đó là một vài trăm cam kết trong một vài tháng làm việc chăm chỉ.

Tôi cũng đã thực hiện một số công việc Mercurial, nhưng những kẻ đó thì kén chọn hơn và công nghệ phức tạp hơn, vì vậy tôi chưa nhận được bất kỳ sửa chữa nào vào cốt lõi. Tôi đã thực hiện một vài báo cáo lỗi và viết một vài phần mở rộng nhỏ, nhưng tôi chưa nhận được bất cứ điều gì lớn hơn ở đó vào lúc này.

Hy vọng nó giúp.

Nhảy vào. Theo dõi danh sách phát triển một lúc và giới thiệu bản thân khi bạn cảm thấy thoải mái. Nhiều dự án có một số Công việc dễ dàng hơn trong việc sửa lỗi hoặc tài liệu mà các cơ quan quản lý sẽ sẵn lòng chỉ ra cho bạn. Hầu hết các Dự án khá thân thiện với những người mới và họ sẽ đưa bạn đến với nhau đủ nhanh để bạn có thể trở thành một tài sản thực sự cho Dự án.

Sau một thời gian, bạn sẽ làm quen với cấu trúc và các phần quan trọng nhất của cơ sở mã. Học cách hiểu mã như thế này là một phần thực sự quan trọng của lập trình và nguồn mở là một cách tuyệt vời để học nó.

Cứ liều thử đi. Có hàng tấn người mới bắt đầu làm như vậy. Người dẫn đầu dự án có thể giúp tìm cho bạn những thứ để làm việc mà không nằm ngoài liên minh của bạn. Bạn dần dần phát triển thành phần còn lại.

Ồ, và chỉ vì bạn không hiểu mã không có nghĩa là nó tốt . Tôi đã thấy một số mã nghiêm trọng khủng khiếp ngoài kia. Một số điều khó hiểu vì nó được viết kém và được làm phức tạp hơn nhiều so với nó.