Nguyên Tắc Lựa Chọn Dự Án Mã Nguồn Mở
Cuối tuần này, tập đoàn Alibaba sẽ tổ chức sự kiện tuyển dụng tại Đại học Trung Nam. Với tư cách là cựu sinh viên, tôi được mời chia sẻ kỹ thuật dành cho các tân cử nhân. Tôi muốn dành thời gian nói về chủ đề mã nguồn mở.
Do thời lượng chia sẻ hạn chế, tôi không thể triển khai sâu các nội dung liên quan. Vì vậy tôi viết bài blog này để bàn về một chủ đề con: Tiêu chí lựa chọn dự án mã nguồn mở khi sử dụng chúng?
Trong quá trình phát triển phần mềm, chúng ta thường gặp những mô-đun yêu cầu phổ biến. Ngoài việc tự phát triển, lựa chọn dự án mã nguồn mở có giấy phép phù hợp cũng là phương án tối ưu.
Trong sự nghiệp lập trình viên, ai cũng từng trải qua giai đoạn không muốn dùng mã nguồn người khác viết. Nếu không bị áp lực tiến độ dự án, họ sẽ chọn tự xây dựng. Điều này không phải vì tự tin làm tốt hơn, mà là để giảm sự phụ thuộc, có không gian sáng tạo. Viết code thường dễ hơn hiểu code. Việc tích hợp các đoạn mã từ nhiều nhóm phát triển khác nhau cũng khó đảm bảo tính nhất quán cho toàn hệ thống.
Khi vượt qua giai đoạn này, không còn cố chấp tự “đóng bánh xe”, việc lựa chọn “bánh xe” nào sẽ trở thành quyết định quan trọng. Vì đã kìm nén ham muốn tự làm, chọn cái gì cũng phải thật kỹ càng.
Từ góc nhìn cá nhân, trước tiên tôi luôn ưu tiên dự án còn hoạt động sôi nổi với lịch sử cập nhật đầy đủ.
Mã nguồn phần mềm không chỉ là tập hợp dòng lệnh, mà là kết quả của quá trình thay đổi liên tục theo thời gian. Một bản chụp tại thời điểm cụ thể không giúp tôi hiểu sâu phần mềm, càng không thể tích hợp vào hệ thống riêng. Bất kỳ vấn đề nào nếu còn người quan tâm sẽ tiếp tục phát triển. Người dùng thực sự mới là tài sản quý giá nhất của dự án. Một dự án vài năm không cập nhật sẽ trở thành “dự án chết” (mất toàn bộ người dùng). Chúng ta không nên đưa các dự án “chết” vào hệ thống đang phát triển.
Nếu một dự án từng sôi nổi nhưng nay đã chết, điều đó cho thấy người dùng trước đó đã rời đi. Nếu vẫn muốn dùng, phải tự đánh giá năng lực có thể “hồi sinh” nó không. Ngay cả dự án còn sống, bạn cũng có thể là người dùng bên ngoài duy nhất ngoài nhóm tác giả. Người dùng mới mang theo yêu cầu mới và bug mới. Bạn phải có năng lực giải quyết các vấn đề phát sinh.
Tiêu chí thứ hai là nhà sáng lập dự án phải giỏi giao tiếp.
Hầu hết dự án mã nguồn mở đều có nhân vật trung tâm, thường là người sáng lập. Người này có thể tính cách nóng nảy, nhưng phải biết lắng nghe và hợp tác; điều này có thể cảm nhận qua các mục issues và pull request. Nếu là dự án mới, chưa nhiều người dùng, có thể tham khảo các dự án khác cùng tác giả. Dùng thử một thời gian, thử report bug, bạn sẽ có trải nghiệm trực quan hơn.
Bất kỳ chức năng nền tảng nào khi có nhiều người dùng sẽ phát sinh yêu cầu đa dạng. Vai trò của “nhân vật trung tâm” là phân tích và điều phối các yêu cầu này. Chính năng lực giao tiếp, chứ không phải kỹ năng code, mới quyết định hướng phát triển dự án.
Tiêu chí cuối cùng là độ chuyên sâu của dự án. Tôi thiên về các dự án giải quyết vấn đề cụ thể, càng tập trung càng tốt. Tôi không thích các giải pháp “tất cả trong một”. Điều này giúp chúng ta dễ dàng kết hợp, lựa chọn và thay đổi khi cần. Nếu dùng một thời gian thấy không phù hợp, vẫn có thể quay đầu chọn phương án khác.
Về chất lượng dự án và mã nguồn, đây là vấn đề mang tính chủ quan. Tôi có thể chấp nhận code không chú thích, đặt tên lộn xộn, thụt lề không chuẩn, thiếu test case. Giao diện thay đổi liên tục hay bug phát sinh cũng không phải vấn đề lớn. Vì khi chọn đồng hành cùng dự án mã nguồn mở, đồng nghĩa với việc bạn sẵn sàng tham gia cải tiến nó. Nếu cần, sau này có thể chuyển sang module tương tự khác hoặc tự viết lại.
Lựa chọn dự án mã nguồn mở thực chất là lựa chọn hợp tác với những người duy trì dự án đó. Con người mới là yếu tố quan trọng nhất: Hãy chọn những đối tác chăm chỉ, cởi mở và tập trung.
P/s: Muốn phàn nàn về một số “dự án mã nguồn mở” trong nước. Sau khi PR rầm rộ, họ chỉ công bố bản snapshot của một phiên bản rồi sau đó im ắng vài năm. Những commit và pull request gần đây chỉ là sửa lỗi chính tả vụn vặt. Mã nguồn mở không phải là như vậy!