Làm thế nào để bắt đầu sửa lỗi trong phần mềm nguồn mở?

Tôi là một sinh viên có kiến ​​thức tốt về lập trình C và muốn đóng góp bất kỳ dự án nguồn mở nào được phát triển ở C. Tôi đã tìm kiếm SourceForge và chọn 7-Zip vì nó được sử dụng rộng rãi và được phát triển bằng C.

Tôi đã nghĩ bắt đầu trước bằng cách sửa lỗi (được đề xuất bởi nhiều người trong trang web của họ) và đã trải qua một vài lỗi nhưng không thể hiểu cách trả lời chúng và cách bắt đầu sửa chúng. Tôi không hiểu gì cả.

Bạn có thể vui lòng giải thích làm thế nào để tiếp cận điều này? Tôi thậm chí đã xem qua một số tệp trong mã nguồn mà tôi đã tải xuống nhưng không hiểu gì cả.

Đây là một gợi ý:
Yêu cầu tính năng: sử dụng "di chuyển" thay vì "sao chép" từ thư mục tạm thời - ID: 1615140

Bạn có thể thay đổi hành vi của 7-zip để sử dụng "di chuyển" thay vì "sao chép" khi 7-zip giải nén các tệp. Vấn đề là với các hệ thống HDD đơn và các tệp lớn, điều này sẽ tăng tốc đáng kể. WinRAR làm điều đó ngay bây giờ.

Và tôi sẽ giải thích tại sao tôi chọn lỗi này làm ví dụ.

Trước khi bạn quyết định chọn dự án này ...

• Bạn có thoải mái với mã nguồn của dự án này không?
  • Bạn có thể hiểu cả mã C (chủ yếu là các thuật toán nén lõi) không?
  • Và cả mã C ++ (hầu hết "ứng dụng", GUI và dòng lệnh, và tất cả các tương tác với các hệ điều hành)?
  • Và cả phong cách mã hóa (điển hình cho lập trình Win32; không sử dụng MFC / ATL)?
• Bạn sẽ đầu tư thời gian và công sức của mình vào Hệ điều hành này chứ?
  • Một sự hiểu biết tốt về API Windows là cần thiết.
  • Ví dụ: Các hàm API quản lý tệp Windows .

Bước đầu tiên: bạn có thể tái tạo lỗi không?

• Để chọn một lỗi để làm việc, người ta cần có khả năng tái tạo vấn đề trên một môi trường máy tính tương tự.
  • Lỗi này sẽ yêu cầu bạn kiểm tra trên máy tính (1) tempthư mục có dung lượng trống thấp (1-2 GB), (2) đích trích xuất nằm trên cùng ổ đĩa với tempthư mục.
• Cần bao nhiêu thời gian để "thiết lập" môi trường để tái tạo nó?
  • Chọn các lỗi dễ sinh sản và dễ sửa.
• Là lỗi thực sự là một lỗi?
  • Luôn cố gắng tự tái tạo nó. Đừng chỉ dựa vào lời nói của người khác.
  • Là một kỹ sư / lập trình viên phần mềm, hãy xem bạn có thể giải thích hành vi của lỗi theo cách hiểu của bạn không. Đôi khi người dùng có những kỳ vọng không thực tế về cách hệ thống phần mềm / phần cứng hoạt động và thực hiện các yêu cầu tính năng không thể.
• Làm thế nào để tôi xác nhận sự hiểu biết của tôi? Làm thế nào để tôi biết nếu nó đang sao chép hoặc di chuyển tệp?
  • Bạn sẽ cần các công cụ chẩn đoán, như Process Monitor . Bạn cũng có thể điều chỉnh thiết lập máy thử nghiệm của mình để kiểm tra các tình huống khác nhau.

Bước thứ hai: Bạn có thể xác định mã chịu trách nhiệm cho hành vi này?

• Một sự hiểu biết tổng thể về dự án là cần thiết, theo câu trả lời của Larry Coleman .
• Tốt nhất là bạn có Visual Studio (một trình gỡ lỗi và môi trường phát triển tích hợp) để bạn có thể đặt các điểm dừng và hiểu luồng của chương trình.

Bước thứ ba: Thực hiện sửa đổi và xem nó ảnh hưởng đến hành vi của chương trình như thế nào.

Bước thứ tư: Trình bày các thay đổi của bạn cho đồng nghiệp / nhà phát triển ngang hàng và nhận phản hồi.

Sửa lỗi có thể không phải là điều dễ dàng nhất. Tất nhiên là dễ dàng hơn việc thêm các tính năng mới. Nhưng thậm chí dễ dàng hơn là cập nhật tài liệu hoặc thử nghiệm một bản phát hành mới. Cả hai điều này sẽ giúp bạn trở nên quen thuộc hơn với mã để bạn có thể biết đủ để sửa lỗi. Nó cũng cung cấp cho việc tìm hiểu về mã một ý nghĩa của mục đích giúp đỡ người khác.

Theo tôi, một điều rất quan trọng mà nhiều người có tham vọng đóng góp cho những người nguồn mở bỏ qua, đó là giao tiếp với các nhà phát triển khác trong dự án nguồn mở.

Nếu bạn muốn đóng góp cho một dự án nguồn mở, điều đầu tiên bạn nên làm là theo dõi những gì đang xảy ra trong dự án. Nếu có một danh sách gửi thư, diễn đàn, Google Group hoặc cách khác mà các nhà phát triển giao tiếp, hãy tham gia ở đó. Tìm hiểu những đóng góp là cần thiết nhất. Đặt câu hỏi về cách thức hoạt động của phần mềm, v.v.

Nếu bạn chỉ tải xuống mã nguồn, cố gắng tự hiểu tất cả thì sẽ tốn nhiều thời gian hơn. Nếu bạn sửa một cái gì đó hoặc thêm một tính năng mới và sau đó đột nhiên trình bày nó, nó sẽ ít được chấp nhận hơn.

Vì vậy, hãy nói chuyện với các nhà phát triển khác, tìm hiểu các lỗi ưu tiên cao nhất hoặc các tính năng bị thiếu, v.v.

Tôi thậm chí đã xem qua một số tệp trong mã nguồn mà tôi đã tải xuống nhưng không hiểu gì cả.

Đây là lỗi đầu tiên bạn nên sửa. Bạn cần hiểu cơ sở mã trước khi bắt đầu sửa lỗi. Nếu không, làm thế nào bạn sẽ biết nếu bản sửa lỗi của bạn sẽ phá vỡ bất cứ điều gì khác?

Có nhiều phương pháp khác nhau để làm quen với mã trong dự án bạn đang tham gia. Phương pháp yêu thích của tôi là đọc qua tất cả các mã một lần, sau đó quay lại và xem các phần chi tiết hơn.