Tại sao và khi tạo gói R?

Tôi hiểu câu hỏi này khá rộng, nhưng tôi tự hỏi đâu là điểm quyết định trong việc quyết định tạo (hoặc không) một gói mới cho R. Để cụ thể hơn, tôi sẽ nói thêm rằng câu hỏi không phải là về lý do sử dụng R trong chính nó, thêm về quyết định biên dịch các tập lệnh khác nhau và tích hợp chúng trong một gói mới.

Trong số những điểm có thể dẫn đến những quyết định này, tôi đã nghĩ đến (theo một cách khá không toàn diện), về:

• sự không tồn tại của các gói khác trong cùng một trường con;
• nhu cầu trao đổi với các nhà nghiên cứu khác và cho phép tái sản xuất các thí nghiệm;

Và trong số những điểm có thể dẫn đến một quyết định trái ngược:

• một phần của các phương thức được sử dụng đã có trong một số gói khác;
• số lượng chức năng mới không đủ để biện minh để tạo ra một gói độc lập mới.

Tôi có thể đã quên nhiều điểm có thể đi vào một trong hai danh sách, và cũng có thể, những tiêu chí này có vẻ hơi chủ quan. Vì vậy, những gì bạn sẽ nói nên biện minh, và tại thời điểm nào, để bắt đầu tập hợp các chức năng và dữ liệu khác nhau trong một gói tài liệu mới và có sẵn rộng rãi?

Tôi không lập trình trong R, nhưng tôi lập trình khác, và tôi không thấy vấn đề cụ thể về R ở đây.

Tôi tưởng tượng rằng hầu hết mọi người đầu tiên viết một cái gì đó bởi vì họ thực sự muốn nó cho chính họ. Ngược lại, bất kỳ cảm giác rằng một người nên được xuất bản phần mềm bởi vì đó là điều cần làm nên được chống lại mạnh mẽ. Người thông minh có thể là những lập trình viên tệ hại, và thường là như vậy.

Công khai dường như là một vấn đề của việc tự tin rằng bạn có một cái gì đó tốt hoặc tốt hơn những gì đã công khai và lấp đầy một khoảng cách. Biết rằng những người khác muốn làm điều tương tự chắc chắn là một sự thúc đẩy.

Nếu bạn nghi ngờ, đừng xuất bản. Trong nhiều cộng đồng, có một vấn đề kiểm soát chất lượng của phần mềm tầm thường hoặc lỗi được phát hành bởi các lập trình viên thiếu kinh nghiệm hoặc thiếu kinh nghiệm, mặc dù vấn đề tồi tệ như thế nào vẫn còn mở để tranh luận. Những người lạc quan cảm thấy rằng những chuyện vặt vãnh chỉ có thể bị bỏ qua và người dùng sẽ phơi bày những lỗi và giới hạn đủ nhanh; Những người bi quan cảm thấy rằng chúng ta đang chìm đắm trong những thứ kém chất lượng và thật khó để nói với những người chiến thắng từ những người thua cuộc. (Mặt khác, kinh nghiệm thu được từ xuất bản là một phần của những gì cho phép lập trình viên cải thiện.)

Có thể có một cuốn sách về điều này, nhưng một vài gợi ý nảy ra trong đầu:

1. Tài liệu chất lượng tốt phân biệt phần mềm tốt cũng như mã tốt, thực sự đôi khi rõ ràng hơn. Không bao giờ đánh giá thấp bao nhiêu công việc sẽ cần thiết để cung cấp tài liệu mà mã xứng đáng. Các lập trình viên R dường như thường yêu cầu người dùng R biết nhiều như họ làm về kỹ thuật được triển khai và tài liệu tối thiểu ....

2. Càng xa càng tốt, kiểm tra mã của bạn để bạn có thể sao chép các giải pháp được công bố với dữ liệu thực từ nơi khác. (Nếu bạn đang mã hóa một thứ hoàn toàn mới, điều đó có thể khó khăn hơn, nhưng không phải là không thể. Ngoài ra, bạn có thể thường thấy mình tự hỏi liệu đó có phải là lỗi của họ hay của bạn.)

3. Các lập trình viên thường đánh giá thấp khả năng người dùng ném dữ liệu không phù hợp vào một chương trình. Vì vậy, hãy suy nghĩ về những gì có thể sai, ví dụ với các giá trị bị thiếu, số không nếu một chương trình giả định là tích cực, v.v. (Điều lành tính ở đây là công việc của người dùng là tìm ra các vấn đề và cải thiện mã thông qua phản hồi của họ , nhưng một chương trình bị phá vỡ dễ dàng sẽ không nâng cao danh tiếng của bạn.)

Đây là một câu hỏi quan trọng và thiết thực. Hãy bắt đầu bằng cách phân biệt giữa viết một gói và xuất bản nó trên CRAN.

Lý do không nên viết một gói:

• Chi phí hiệu quả.
• Thiếu kinh nghiệm.

Lý do để viết gói R:

• Chia sẻ với mọi người và nền tảng.
• Buộc một mã gọn gàng và quy trình làm việc.
• Dễ sử dụng (ngay cả đối với bản thân) khi các chức năng bắt đầu tích lũy.

Lý do để gửi gói (CRAN, Bioconductor, ...):

• Đóng góp cho cộng đồng.
• Dễ phân phối.

Hãy nhớ rằng có tùy chọn # 3; bạn có thể yêu cầu người duy trì gói có liên quan bao gồm mã hoặc dữ liệu của bạn.

Kích hoạt cá nhân của tôi để đóng gói là:

• Tôi thấy tôi lại sử dụng một số mã mà tôi đã từng viết cho một dự án phân tích dữ liệu khác.
• Tôi nghĩ rằng tôi sẽ cần phương pháp tôi vừa viết lại.

• Một đồng nghiệp hỏi tôi mã. Một phần đáng kể của mã tôi viết ít nhất là theo yêu cầu của đồng nghiệp (những người sử dụng R nhưng không tự lập trình nhiều như vậy) cho bản thân tôi.

• Tôi sử dụng các yêu cầu chính thức của một gói (tài liệu) để "buộc" tôi dọn dẹp và ghi lại mã của mình.

Tôi đồng ý với @JohnRos rằng có khá nhiều sự khác biệt giữa việc viết một gói và xuất bản gói.

• Tôi thường đóng gói sớm, nhưng sau đó làm cho gói chỉ "bán công khai". Đó là, nó có thể có sẵn trên một máy chủ nội bộ (hoặc trên r-forge), vì vậy các đồng nghiệp của tôi có thể truy cập gói. Nhưng tôi chỉ xuất bản lên CRAN sau khi gói đã được sử dụng trong nhiều tháng hoặc thậm chí vài năm bởi các đồng nghiệp thân thiết. Điều này không mang đến tất cả các lỗi theo điểm số 3 của @Nick Cox, nhưng một số lượng khá lớn trong số đó.
  Các phiên bản của gói (tôi đặt ngày sau dấu gạch ngang trong số phiên bản) giúp bạn dễ dàng sửa chữa mọi thứ ("để làm điều này và điều đó, đảm bảo bạn không gặp rắc rối ít nhất là phiên bản tuần trước")

• Theo hợp đồng làm việc của tôi, chủ nhân của tôi có lời cuối cùng về quyết định liệu và làm thế nào một gói có thể được công bố ra thế giới bên ngoài.

Điều mà tôi không chưa có một chiến lược tốt để đóng gói là dữ liệu.

Bình luận cho danh sách lý do của bạn:

• sự không tồn tại của các gói khác trong cùng một trường con;

Không tìm thấy một gói làm những gì tôi cần cho tôi kích hoạt việc viết mã, nhưng nó không liên quan đến quyết định có nên gói hay không.

• nhu cầu trao đổi với các nhà nghiên cứu khác và cho phép tái sản xuất các thí nghiệm;

Dứt khoát. Có thể đã có nhu cầu chia sẻ giữa một số máy tính tôi sử dụng.

Và trong số những điểm có thể dẫn đến một quyết định trái ngược:

• một phần của các phương thức được sử dụng đã có trong một số gói khác;

bạn có thể nhập các phương thức đó vào gói / mã của mình: đây là một điểm chống lại việc viết mã đó, nhưng chỉ gián tiếp thực hiện với bao bì.

• số lượng chức năng mới không đủ để biện minh để tạo ra một gói độc lập mới.

Đối với tôi, không có số lượng chức năng tối thiểu để bắt đầu một gói. Theo kinh nghiệm của tôi, các gói có xu hướng phát triển "tự động". Ngược lại, sau khi tôi thấy mình vài lần tách một gói mới ra khỏi gói khác (vì ví dụ, một số chức năng của trình trợ giúp cuối cùng hóa ra cũng khác về mặt chủ đề và cũng hữu ích trong các tình huống khác), bây giờ tôi cũng khá tạo gói mới ngay lập tức.

Ngoài ra, nếu bạn không viết tài liệu và kiểm tra, đây có thể là một lượng công việc bị cấm khi số lượng hàm "đủ" để tạo gói được tích lũy.
(Nếu bạn viết chúng ngay lập tức, thì nỗ lực bổ sung để đưa nó vào một gói là không đáng kể một khi bạn biết quy trình làm việc).

Tôi muốn tạo một gói bất cứ khi nào bạn đang thực hiện một nhóm tác vụ tương tự đủ lớn trong R mà bạn sẽ được hưởng lợi từ gói mà bạn có thể đặt mọi thứ vào một không gian tên (để tránh xung đột với các hàm có tên tương tự), nơi bạn có thể viết tài liệu. Tôi thậm chí còn có một gói trên github để gói một túi các chức năng không liên quan, nhưng tôi sử dụng thường xuyên đến mức tôi nghĩ rằng chúng xứng đáng với tài liệu, tệp người đàn ông, v.v.

Một trường hợp sử dụng khác có thể là khi gửi một bài báo, nếu bạn có một số chức năng, bạn có thể dễ dàng tạo một gói, bao gồm tài liệu cho các chức năng đó, ví dụ cho từng chức năng và hướng dẫn về cách sử dụng nó. Và bạn không cần phải đưa nó vào CRAN, như đã nói trong các câu trả lời ở trên. Điều này có thể là tuyệt vời cho khả năng tái sản xuất.

Ba công cụ tôi muốn nói là quan trọng:

• devtools pkg , để làm cho việc xây dựng các gói siêu dễ dàng (cũng xem wiki trên các trang github của devtools
• roxygen2 pkg , để làm cho tài liệu viết cho gói của bạn dễ dàng
• GitHub, Bạn có thể sử dụng install_github(hoặc tương tự install_bitbucket, v.v.) để cài đặt trực tiếp từ GitHub, rất tốt để chia sẻ với người khác.

Tôi đồng ý với tất cả mọi thứ tôi đọc cho đến nay. Tất cả những lý do đó là thực hành lập trình tốt và đặc biệt không áp dụng cho R. Tuy nhiên, tôi thấy mình viết các gói R hầu hết thời gian và vì một lý do khác. Vì vậy, tôi sẽ thêm:

Lý do cụ thể của R để viết gói R:

• bởi vì bạn viết bằng C

Bất cứ khi nào bạn sử dụng các ngôn ngữ nước ngoài như C, C ++ hoặc FORTRAN (chủ yếu để tính toán hiệu năng cao), việc viết một gói phần lớn đáng để gặp rắc rối. Nếu bạn có nhiều hơn một hoặc hai chức năng, bạn sẽ nhanh chóng kết thúc với các tệp ở khắp mọi nơi và các phụ thuộc giữa mã R và C khó duy trì và chuyển sang cổng.

Một lý do không được đề cập trong các câu trả lời xuất sắc khác: Bạn có một dự án phân tích dữ liệu lớn hoặc phức tạp. Đóng gói, đầu tiên, dữ liệu dưới dạng một gói, sau đó mở rộng với các chức năng hữu ích để chuyển đổi, vẽ đồ thị hoặc tính toán các phân tích cụ thể. Bằng cách này, bạn có được một phiên bản tài liệu của dữ liệu hoàn chỉnh với tất cả các chức năng được sử dụng để tính toán phân tích được báo cáo. Sau đó, (các) báo cáo từ dự án có thể được viết bằng cách sử dụng đan hoặc các gói khác cho nghiên cứu tái sản xuất!

Điều này có thể tiết kiệm đáng kể thời gian nếu một số phân tích lại phải được thực hiện, hoặc thậm chí nó có thể được xuất bản (hoặc bán thành công) nếu phân tích được công bố.