Nếu bạn đã học lập trình một thời gian nhưng vẫn chưa biết mình đang đứng ở đâu, đóng góp mã nguồn mở là một cách khá thực tế để tự kiểm tra lại. Nhiều bạn sinh viên dành cả mùa hè đọc sách mà vẫn chưa dám gửi một dòng code nào cho người khác xem. Đóng góp cho dự án công khai giải quyết đúng nỗi lo ấy. Bài này sẽ đi từng bước, từ việc chọn issue đầu tiên cho tới lúc pull request của bạn được gộp vào dự án.
Vì sao người mới nên thử đóng góp mã nguồn mở ngay bây giờ?
Mã nguồn mở là phần mềm có mã nguồn công khai, ai cũng đọc được và có thể đề xuất thay đổi. Khi đóng góp mã nguồn mở, bạn đọc code thật của người khác thay vì những ví dụ đã được cắt gọt gọn gàng trong sách hay khóa học.
Điều đó dạy bạn những thứ khó học ở lớp. Bạn sẽ thấy cách một dự án lớn đặt tên biến và cách người khác viết kiểm thử cho một hàm nhỏ. Phần giá trị nhất nằm ở những cuộc trao đổi trong quá trình review. Đôi khi chỉ một câu góp ý của người bảo trì giúp bạn hiểu ra nguyên tắc mà cả học kỳ đọc giáo trình vẫn chưa rõ.
Về hồ sơ xin việc, commit và pull request của bạn nằm công khai trên GitHub. Nhà tuyển dụng có thể xem bạn viết code ra sao và phản hồi góp ý thế nào. Một lịch sử đóng góp đều đặn thường thuyết phục hơn một dòng “biết Java” trên CV.
Nhiều người nghĩ phải thật giỏi mới được đóng góp. Thực tế, các dự án luôn có sẵn việc nhỏ: sửa lỗi chính tả trong tài liệu, thêm một ví dụ, hay viết thêm một bài kiểm thử. Những việc này rất hợp với người vừa học xong nền tảng.
Đóng góp mã nguồn mở là gì? Trả lời nhanh cho người mới
Nói ngắn gọn, đó là việc bạn gửi một thay đổi cho dự án công khai, rồi người bảo trì quyết định có gộp hay không. Đóng góp không chỉ có nghĩa là viết code. Bạn có thể sửa lỗi, viết tài liệu, dịch giao diện, bổ sung kiểm thử, hoặc báo lỗi kèm cách tái hiện rõ ràng.
Có ba vai trò hay bị nhầm lẫn: người dùng sử dụng phần mềm, người báo lỗi mô tả vấn đề, và người đóng góp đề xuất thay đổi trong mã nguồn hoặc tài liệu. Một báo cáo lỗi rõ ràng đã là một đóng góp có giá trị.
Chuẩn bị môi trường: Git, GitHub và những khái niệm cần nắm
Git là công cụ quản lý phiên bản, còn GitHub là nơi lưu trữ và trao đổi các dự án dùng Git. Bạn cần cài Git trên máy và tạo một tài khoản GitHub miễn phí. Sau khi cài xong, hãy cấu hình tên và email hiển thị trong commit.
Trước khi bắt đầu, bạn nên làm quen với năm khái niệm sau:
- Fork: bản sao của repository dưới tài khoản của bạn trên GitHub.
- Clone: tải bản sao đó về máy để làm việc.
- Branch: nhánh riêng để bạn sửa mà không ảnh hưởng nhánh chính.
- Commit: một lần lưu thay đổi kèm theo mô tả.
- Pull request: yêu cầu gửi thay đổi của bạn về dự án gốc để người bảo trì xem xét.
Bạn không cần nhớ hết ngay. Chỉ cần hiểu luồng fork, rồi branch, rồi pull request là đủ để bắt đầu. Các khái niệm còn lại sẽ quen dần khi làm thật.
Về trình soạn thảo, bạn dùng IDE hay editor nào cũng được. Điều quan trọng là chạy được dự án trên máy của mình. Nếu dự án yêu cầu một phiên bản ngôn ngữ cụ thể, hãy cài đúng phiên bản đó, vì rất nhiều lỗi “không chạy được” đến từ việc lệch phiên bản.
Tìm đúng issue để bắt đầu: loại nào hợp với người mới?
Issue là một mục công việc được ghi trên trang quản lý của dự án, chẳng hạn một lỗi cần sửa hoặc một tính năng cần thêm. Nhiều dự án gắn nhãn sẵn để người mới dễ tìm, như good first issue, help wanted hoặc documentation.
Nhãn documentation thường là lựa chọn an toàn nhất. Sửa một đoạn hướng dẫn sai hay thêm một ví dụ hiếm khi làm hỏng chức năng nào.
Khi đã chọn được issue, hãy đọc kỹ mô tả và xem các bình luận bên dưới. Nếu đã có người nhận việc, đừng giành phần đó. Nếu issue lâu không ai động tới, hãy hỏi người bảo trì xem nó còn cần không.
| Loại issue | Mức rủi ro | Mức phù hợp với người mới |
|---|---|---|
| Sửa lỗi chính tả, đường dẫn hỏng | Gần như bằng không | Rất phù hợp, nên bắt đầu từ đây |
| Viết thêm ví dụ, cải thiện tài liệu | Thấp | Phù hợp, cần hiểu dự án khá nhiều |
| Viết thêm test cho hàm có sẵn | Thấp | Rất tốt để hiểu code vận hành ra sao |
| Sửa lỗi logic trong phần lõi | Cao | Nên để sau khi đã quen dự án |
Hãy dành vài buổi tối để so sánh các issue trước khi chọn. Đừng vội nhảy vào một issue khó chỉ vì nó nghe hấp dẫn, vì cảm giác kẹt quá lâu dễ khiến người học bỏ cuộc giữa chừng. Chọn một việc vừa sức, làm xong rồi mới tính việc tiếp theo. Nếu bạn muốn hiểu cách tiếp cận một bài toán từng bước, hãy tham khảo thêm cách tiếp cận bài toán từng bước cho người mới.
Đọc hiểu dự án trước khi viết dòng code đầu tiên
Đây là bước nhiều người bỏ qua và rồi bị từ chối. Trước khi sửa bất cứ điều gì, hãy đọc file README để biết dự án làm gì và cài đặt như thế nào. Sau đó đọc CONTRIBUTING.md nếu dự án có file này, vì đây là nơi người bảo trì ghi rõ quy ước đóng góp.
Hãy để ý cách đặt tên, định dạng code và cách viết commit. Có dự án yêu cầu khuôn mẫu commit nhất định, có dự án lại cấm gộp nhiều việc không liên quan vào cùng một pull request.
Khi đã xác định được issue, dùng chức năng tìm kiếm trong repository để tìm các file liên quan, thay vì đọc cả dự án từ đầu đến cuối. Hãy chạy thử và tự tái hiện lỗi trước khi sửa. Nếu muốn củng cố nền tảng để đọc hiểu code nhanh hơn, bạn có thể xem các cấu trúc dữ liệu cần nắm trước khi đi làm. Để chắc hành vi bạn đang sửa là đúng chuẩn, hãy đối chiếu tài liệu chính thức của ngôn ngữ dự án dùng, ví dụ tài liệu JavaScript trên MDN.
Quy trình gửi thay đổi: từ fork đến pull request
Đây là phần bạn sẽ lặp lại nhiều lần, nên lần đầu hãy làm chậm. Fork repository về tài khoản của bạn, rồi clone bản fork đó về máy.
Tạo một branch riêng với tên rõ nghĩa, chẳng hạn fix-typo-install-guide hoặc docs-add-example-login. Tránh làm việc trực tiếp trên nhánh chính.
Chia thay đổi thành các commit nhỏ, mỗi commit chỉ làm một việc, và mô tả đúng việc đã làm, ví dụ “Sửa đường dẫn sai trong hướng dẫn cài đặt” thay vì “update”. Khi đẩy branch lên bản fork, mở pull request về dự án gốc, nêu ngắn gọn đã đổi gì và vì sao, rồi liên kết issue liên quan bằng số issue.
Xử lý phản hồi từ người bảo trì và chỉnh sửa theo góp ý
Gần như pull request nào cũng nhận được góp ý. Đừng coi đó là chỉ trích cá nhân. Người review thường đang giúp bạn viết code đúng chuẩn của dự án, và đây là phần học được nhiều nhất.
Khi cần sửa, hãy thêm commit mới trên cùng branch thay vì mở pull request mới. Mở lại từ đầu sẽ làm rối lịch sử và khiến người review khó theo dõi.
Nếu chưa hiểu, hãy hỏi cụ thể. Chẳng hạn “Anh/chị muốn tách hàm này thành hai hàm để dễ kiểm thử hơn đúng không ạ?” hiệu quả hơn nhiều so với “Em không hiểu”.
Sai lầm thường gặp khi đóng góp lần đầu
Lỗi phổ biến nhất là gửi một pull request quá lớn, gộp nhiều việc không liên quan. Người bảo trì khó review và thường từ chối cả gói. Hãy giữ mỗi pull request chỉ làm một việc.
Lỗi thứ hai là không đọc hướng dẫn đóng góp, bỏ qua quy ước định dạng code, khiến thay đổi bị yêu cầu sửa lại nhiều lần.
Lỗi thứ ba là nhận issue rồi biến mất mà không cập nhật tiến độ. Nếu không còn thời gian, hãy để lại bình luận nhả issue để người khác tiếp tục.
Lịch thực hành gợi ý cho người học lập trình bận rộn
Nhiều người học vừa đi làm vừa học, nên thời gian luôn là vấn đề lớn. Một khung gợi ý là dành vài buổi tối mỗi tuần: một buổi đọc dự án và tìm issue, một buổi viết thay đổi, và một buổi xử lý phản hồi.
Thời gian từ lúc chọn issue đến lúc được gộp phụ thuộc nhiều vào tốc độ phản hồi của người bảo trì và độ phức tạp của việc, nên đừng đem tốc độ của mình ra so với người khác.
Hãy ghi lại tiến độ trong một file ghi chú: issue nào đã chọn, pull request nào đã mở, bài học nào đã rút ra. Nếu bạn đang tìm một lộ trình tổng thể hơn, hãy đọc thêm lộ trình học lập trình cho người mới từ nền tảng đến dự án đầu tiên.
Câu hỏi thường gặp
Người chưa giỏi lập trình có đóng góp mã nguồn mở được không?
Được. Sửa tài liệu, dịch thuật, báo lỗi có tái hiện và viết thêm ví dụ đều là đóng góp thật sự. Bạn không cần giỏi thuật toán để bắt đầu.
Đóng góp mã nguồn mở có được trả tiền không?
Phần lớn đóng góp là tự nguyện và không được trả tiền trực tiếp. Một số dự án có quỹ tài trợ. Quan trọng hơn, hồ sơ đóng góp thường giúp ích khi bạn tìm việc.
Nên chọn dự án nào để bắt đầu?
Bạn có thể bắt đầu từ những dự án mình đang dùng hằng ngày, vì bạn đã hiểu chúng hoạt động ra sao. Hãy chọn dự án bạn thực sự quan tâm để giữ động lực lâu dài.
Pull request bị từ chối thì có nên bỏ cuộc không?
Không nên. Bị từ chối là chuyện bình thường. Hãy đọc kỹ lý do, rút kinh nghiệm rồi thử lại với một issue khác.