Một bộ mã phân tích R được xem là tái lập khi người khác, trên một máy khác, chạy lại và thu được đúng các bảng, hình như trong luận văn. Để đạt mức này, bạn cần rà bốn nhóm việc trước khi chia sẻ: làm sạch mã, quản lý thư viện, tách dữ liệu nhạy cảm và viết hướng dẫn chạy lại.

Bài viết trình bày từng nhóm dưới dạng câu hỏi tự kiểm, kèm bảng checklist tổng hợp ở cuối để bạn in ra và đánh dấu. Nội dung phù hợp khi nộp phụ lục mã cho khoa, gửi giảng viên hướng dẫn kiểm tra hoặc đính kèm tài liệu bổ sung theo yêu cầu của tạp chí.

Tóm tắt nhanh: script phải chạy được trong một phiên R mới, không dựa vào đường dẫn hay bộ nhớ trên máy bạn.

Gói được khóa phiên bản, dữ liệu định danh được loại bỏ, và một tệp README cho biết chạy gì, theo thứ tự nào.

Vì sao cần chuẩn bị mã phân tích R trước khi chia sẻ?

Mã viết trong quá trình làm luận văn thường mang dấu vết của nhiều lần thử: dòng lệnh bị chú thích, đối tượng tạm, đường dẫn đến ổ đĩa riêng. Bạn hiểu chúng vì đã viết ra, nhưng người nhận thì không. Gửi đi một bộ mã chạy lỗi ngay dòng đầu khiến người kiểm tra nghi ngờ cả kết quả, dù phân tích thực ra đúng.

Tính tái lập cũng là một phần của nghiên cứu có trách nhiệm. Tài liệu về thực hành nghiên cứu có trách nhiệm của APA nhấn mạnh việc lưu giữ và chia sẻ quy trình phân tích một cách minh bạch. Nếu thư mục dự án chưa gọn, hãy đọc trước bài tổ chức dự án phân tích dữ liệu bằng R.

Nhóm 1: Làm sạch mã

Mục tiêu của nhóm này là để script đọc được như một văn bản có trình tự, từ nhập dữ liệu đến xuất kết quả. Người nhận không cần thấy quá trình bạn thử sai, họ cần thấy con đường dẫn đến từng con số trong luận văn. Hãy rà từng tệp theo các câu hỏi dưới đây.

Loại bỏ lệnh phụ thuộc vào máy cá nhân

Một số lệnh chạy tốt trên máy bạn nhưng gây lỗi hoặc gây hại trên máy người khác:

  • setwd() với đường dẫn tuyệt đối: thay bằng RStudio Project và gói here.
  • rm(list = ls()) ở đầu script: không làm sạch hoàn toàn phiên R, lại xóa đối tượng của người nhận; hãy khởi động lại R thay thế.
  • install.packages() nằm trong script: tự ý cài gói lên máy người khác; nên chuyển sang hướng dẫn trong README.
  • Đối tượng được tạo bằng tay trong Console rồi mới dùng trong script: mọi thứ phải được tạo ra bởi mã.

Định dạng và chú thích

Gói styler định dạng lại khoảng trắng và thụt lề theo một quy ước thống nhất, còn lintr chỉ ra những chỗ dễ gây lỗi như biến không dùng đến. Chú thích nên giải thích lý do, ví dụ vì sao loại mười hai phiếu, chứ không nhắc lại điều dòng lệnh đã thể hiện. Xóa các khối lệnh cũ đã bị chú thích; lịch sử thay đổi nên nằm trong Git, không nằm trong script.

Đặt tên nhất quán

Chọn một kiểu đặt tên, chẳng hạn chữ thường nối bằng dấu gạch dưới, và dùng xuyên suốt cho biến, hàm và tệp. Tên đối tượng nên nói lên nội dung, như dữ liệu sạch hay mô hình đầy đủ, thay vì những tên như df2 hay test.

Nhóm 2: Quản lý thư viện

Kết quả có thể thay đổi giữa các phiên bản gói, nên người nhận cần biết chính xác bạn đã dùng phiên bản nào. Bước này thường bị quên vì trên máy tác giả mọi thứ đều đã được cài sẵn. Hãy kiểm tra cả cách nạp gói lẫn cách ghi lại phiên bản.

Khai báo gói ở đầu script

Đặt toàn bộ lệnh library() ở phần đầu mỗi script hoặc trong một tệp cài đặt chung, để người đọc thấy ngay các phụ thuộc. Tránh nạp gói rải rác giữa chừng, vì lỗi thiếu gói sẽ chỉ hiện ra sau khi phần trước đã chạy mất nhiều thời gian. Khi hai gói có hàm trùng tên, hãy gọi kèm tên gói bằng hai dấu hai chấm.

Khóa phiên bản và ghi thông tin phiên

Nếu dự án dùng renv, hãy chạy renv::status() để chắc tệp renv.lock khớp với các gói đang thực sự dùng, rồi gửi kèm tệp này. Nếu không dùng renv, tối thiểu phải đính kèm kết quả sessionInfo() hoặc sessioninfo::session_info() ghi ra tệp văn bản. Danh sách tài liệu chính thức của CRAN có hướng dẫn cài đặt R theo từng hệ điều hành để bạn dẫn trong README.

Nhóm 3: Tách dữ liệu nhạy cảm

Đây là nhóm có hậu quả nặng nhất nếu làm sai, vì một tệp đã chia sẻ thì gần như không thể thu hồi. Dữ liệu khảo sát thường chứa email, số điện thoại, tên đơn vị công tác hay câu trả lời mở có thể nhận diện người tham gia. Mọi thông tin như vậy phải được tách khỏi bộ mã phân tích R trước khi gửi đi.

Loại thông tin định danh

Hãy tạo bước ẩn danh riêng: thay email bằng mã phiếu ngẫu nhiên, bỏ cột tên, gộp tuổi hoặc địa bàn thành nhóm nếu nhóm quá nhỏ dễ lộ danh tính. Tệp gốc còn định danh chỉ lưu trên máy bạn, không nằm trong thư mục chia sẻ. Nguyên tắc chi tiết có trong bài bảo mật thông tin người tham gia khảo sát.

Cung cấp dữ liệu mẫu khi không được chia sẻ dữ liệu thật

Nếu cam kết với người tham gia không cho phép chia sẻ, bạn vẫn có thể giúp người khác chạy thử mã. Cách phổ biến là tạo bộ dữ liệu tổng hợp có cùng cấu trúc cột, ví dụ bằng gói synthpop, và ghi rõ đây là dữ liệu giả lập, kết quả sẽ không trùng với luận văn.

Bảo vệ khóa truy cập và mật khẩu

Nếu script kết nối cơ sở dữ liệu hay dịch vụ trực tuyến, không ghi mật khẩu trực tiếp trong mã. Hãy lưu trong tệp .Renviron, đọc bằng Sys.getenv(), và liệt kê tệp này trong .gitignore cùng thư mục dữ liệu gốc.

Nhóm 4: Ghi hướng dẫn chạy lại

Một tệp README ngắn gọn ở gốc dự án quyết định người nhận mất năm phút hay năm giờ để chạy lại. Tệp này không cần dài, nhưng phải trả lời đủ những câu hỏi đầu tiên người nhận sẽ đặt ra.

Nội dung tối thiểu của README

  1. Mục đích của bộ mã và tên luận văn hoặc bản thảo liên quan.
  2. Phiên bản R, cách khôi phục thư viện và các phần mềm khác cần cài.
  3. Danh sách tệp dữ liệu đầu vào, nơi đặt chúng và cách xin quyền truy cập nếu bị hạn chế.
  4. Thứ tự chạy script, hoặc chỉ một lệnh nếu đã có tệp chạy toàn bộ.
  5. Đầu ra mong đợi: bảng, hình nào ứng với mục nào trong luận văn, thời gian chạy ước tính.

Thử chạy trên môi trường sạch

Bước kiểm tra cuối cùng là chạy toàn bộ trong một phiên R mới, tốt nhất trên máy khác hoặc nhờ một bạn cùng lớp thử. So từng bảng đầu ra với số liệu trong bản thảo, chỉ cần lệch một chữ số cũng phải tìm nguyên nhân.

Kinh nghiệm từ Luận Văn 360: khi chạy thử bộ mã học viên gửi trên máy độc lập, phần lớn lỗi chúng tôi gặp không nằm ở thống kê mà ở những chi tiết nhỏ như tên tệp có dấu, gói chưa khai báo hay seed ngẫu nhiên không được đặt.

Những lỗi này mất vài phút để sửa nếu phát hiện sớm, nhưng làm giảm ấn tượng đáng kể nếu người kiểm tra tự gặp.

Nếu bạn muốn có người chạy thử độc lập trước khi nộp, dịch vụ hỗ trợ phân tích dữ liệu bằng R của Luận Văn 360 có thể kiểm tra mã phân tích R theo đúng checklist này và gửi lại danh sách điểm cần sửa để bạn tự hoàn thiện.

Bảng checklist tổng hợp

NhómCâu hỏi tự kiểmĐạt khi
Làm sạch mãScript còn đường dẫn tuyệt đối hay lệnh cài gói?Không còn, mọi đường dẫn tính từ gốc dự án
Làm sạch mãChú thích có giải thích lý do của các quyết định?Mỗi bước loại hoặc biến đổi dữ liệu đều có lý do
Thư việnNgười nhận biết chính xác phiên bản gói?Có renv.lock hoặc tệp thông tin phiên
Dữ liệuThư mục chia sẻ còn thông tin định danh?Không còn, đã có bước ẩn danh riêng
Dữ liệuCó cách chạy thử khi không chia sẻ dữ liệu thật?Có dữ liệu mẫu cùng cấu trúc, ghi rõ là giả lập
Hướng dẫnREADME nêu đủ thứ tự chạy và đầu ra mong đợi?Người khác chạy lại được mà không cần hỏi bạn
Kiểm traĐã chạy trong phiên R mới và so với bản thảo?Mọi bảng, hình khớp số liệu trong luận văn

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

Có bắt buộc nộp mã phân tích R kèm luận văn?

Tùy quy định của cơ sở đào tạo và yêu cầu của giảng viên. Ngay cả khi không bắt buộc, chuẩn bị sẵn giúp bạn trả lời nhanh nếu hội đồng hỏi về cách xử lý dữ liệu.

Nên chia sẻ qua đâu?

Với giảng viên, một tệp nén hoặc kho Git riêng tư là đủ. Với tạp chí, hãy làm theo hướng dẫn tác giả, nhiều nơi chấp nhận kho lưu trữ có mã định danh lâu dài.

Kết luận

Chuẩn bị mã phân tích R để chia sẻ gồm bốn nhóm việc: làm sạch script, khóa phiên bản thư viện, tách dữ liệu nhạy cảm và viết README, cuối cùng là chạy thử trên môi trường sạch. Làm đủ các bước này, bộ mã trở thành bằng chứng cho tính minh bạch của luận văn thay vì một rủi ro.

Nếu mô hình chính của bạn là hồi quy, bài hồi quy tuyến tính trong R và cách báo cáo giúp bạn soát lại phần chẩn đoán trước khi đóng gói mã. Khi cần một lượt kiểm tra độc lập, hãy tìm hiểu dịch vụ phân tích dữ liệu bằng R của Luận Văn 360.