Phần mềm nghiên cứu: sản phẩm khoa học ít được ghi nhận nhất

Ở rất nhiều lĩnh vực, kết quả nghiên cứu phụ thuộc hoàn toàn vào mã do chính người làm viết ra — để xử lý dữ liệu, chạy mô phỏng, phân tích.

Nhưng phần mềm hiếm khi được coi là một sản phẩm khoa học. Nó không nằm trong danh sách công bố, không được tính khi xét chức danh, và người bỏ nhiều tháng viết một công cụ hữu ích thường không được ghi nhận gì.

Vì sao điều này quan trọng

• Kết quả không kiểm chứng được nếu không có mã. Mô tả phương pháp bằng lời gần như không bao giờ đủ để tái tạo chính xác.
• Lỗi trong mã ảnh hưởng trực tiếp tới kết luận — và chúng chỉ được phát hiện khi có người đọc mã.
• Công sức bị lặp lại khi mỗi nhóm tự viết lại cùng một thứ.
• Người viết công cụ tốt không có động lực để làm nó dùng được cho người khác.

Chuẩn bị mã để chia sẻ

Không cần hoàn hảo. Mục tiêu là người khác chạy lại được.

Tối thiểu cần có:

• Tệp hướng dẫn — mã này làm gì, cần gì để chạy, chạy thế nào, ví dụ đầu vào đầu ra.
• Danh sách phụ thuộc với phiên bản cụ thể. Đây là chỗ hỏng nhiều nhất — mã chạy được hôm nay có thể không chạy sau một năm vì thư viện đã đổi.
• Dữ liệu ví dụ nhỏ để người ta thử.
• Giấy phép sử dụng.

Nên có thêm:

• Chú thích ở các đoạn không hiển nhiên.
• Cấu trúc thư mục rõ ràng.
• Tên biến và hàm có nghĩa.
• Cách liên hệ khi có vấn đề.

Phép thử: đưa cho một đồng nghiệp và nhờ họ chạy trên máy của họ mà không hỏi bạn. Nếu họ không chạy được, hướng dẫn chưa đủ.

Quản lý phiên bản

• Dùng hệ thống quản lý phiên bản ngay từ đầu, không phải khi sắp công bố.
• Đánh dấu phiên bản tương ứng với mỗi bài báo — người đọc cần đúng phiên bản bạn đã dùng, không phải bản mới nhất.
• Ghi lại thay đổi giữa các phiên bản.
• Sao lưu ở nơi độc lập với máy cá nhân.

Giấy phép

Phần hay bị bỏ qua nhưng quan trọng:

• Mã không có giấy phép mặc định là không ai được dùng lại. Nhiều người đăng công khai với ý định cho dùng nhưng không nói ra, và người khác không dám dùng.
• Các loại giấy phép khác nhau về mức tự do — có loại cho dùng lại gần như tuỳ ý, có loại yêu cầu sản phẩm phái sinh cũng phải mở.
• Kiểm tra quy định của cơ sở về sở hữu trí tuệ với mã do bạn viết trong thời gian làm việc.
• Kiểm tra yêu cầu của quỹ tài trợ — một số yêu cầu mở mã.
• Kiểm tra giấy phép của các thư viện bạn dùng — chúng có thể ràng buộc giấy phép của bạn.

Để được trích dẫn

Đây là cách biến công sức thành thứ đếm được:

• Lưu mã ở kho lưu trữ cấp mã định danh vĩnh viễn — nhiều kho lưu trữ nghiên cứu làm việc này và có thể liên kết với hệ thống quản lý phiên bản.
• Ghi rõ cách trích dẫn trong tệp hướng dẫn.
• Cân nhắc công bố một bài mô tả phần mềm — có các tạp chí chuyên đăng loại bài này ở nhiều ngành.
• Yêu cầu người dùng trích dẫn trong điều kiện sử dụng.
• Đưa vào hồ sơ của bạn như một mục riêng, kèm thông tin về mức độ được sử dụng nếu có.

Khi không thể chia sẻ toàn bộ

Có những lý do chính đáng:

• Mã chứa thông tin nhạy cảm.
• Ràng buộc với đối tác hoặc với sở hữu trí tuệ.
• Mã phụ thuộc vào phần mềm thương mại.

Cách xử lý: chia sẻ phần chia sẻ được, mô tả rõ phần không chia sẻ được và vì sao, và nêu cách người khác có thể tiếp cận có điều kiện. Nói rõ vẫn tốt hơn im lặng.

Về chất lượng mã

Một rào cản tâm lý phổ biến: người ta ngại chia sẻ vì mã của họ không đẹp.

• Mã nghiên cứu hiếm khi đẹp — nó được viết trong quá trình khám phá, không phải để làm sản phẩm.
• Mã chạy được và có hướng dẫn tốt hơn nhiều so với không có gì.
• Việc biết mình sẽ chia sẻ làm mã tốt hơn ngay từ đầu — đây là lợi ích phụ đáng kể.
• Người đọc mã nghiên cứu hiểu bối cảnh và không kỳ vọng chuẩn công nghiệp.

Nếu bạn dùng mã của người khác

• Trích dẫn theo cách họ yêu cầu.
• Tôn trọng giấy phép.
• Ghi rõ phiên bản bạn đã dùng.
• Báo lỗi cho họ nếu bạn phát hiện — đây là đóng góp và họ sẽ biết ơn.
• Cân nhắc đóng góp cải tiến ngược lại nếu bạn đã sửa gì hữu ích.

Với người hướng dẫn và nhóm nghiên cứu

• Dạy quản lý phiên bản cho người mới ngay từ đầu — thói quen này khó hình thành về sau.
• Yêu cầu mã có hướng dẫn như một phần của công việc, không phải việc thêm.
• Làm rõ ai sở hữu mã khi người học rời đi.
• Ghi nhận đóng góp về phần mềm trong đánh giá.
• Bàn giao có kế hoạch — mã không ai hiểu là mã sẽ bị viết lại từ đầu.

Với người đánh giá

• Coi phần mềm là sản phẩm nghiên cứu khi xét hồ sơ.
• Yêu cầu chia sẻ mã khi phản biện, ở mức hợp lý cho ngành.
• Ghi nhận việc bảo trì công cụ dùng chung — công việc này ít hào nhoáng nhưng nhiều người phụ thuộc vào nó.

Một điều đáng nhớ

Một bài báo mô tả kết quả. Mã nguồn là thứ tạo ra kết quả đó.

Việc chia sẻ nó không chỉ giúp người khác — nó còn là cách bảo vệ chính bạn, vì khi có ai đó hỏi về một con số trong bài của bạn ba năm sau, mã được tổ chức tốt là câu trả lời duy nhất bạn có.

Câu hỏi thường gặp