Mengapa dan kapan membuat paket R?

Saya mengerti pertanyaan ini cukup luas, tetapi saya bertanya-tanya apa yang harus menjadi poin penentu dalam memutuskan untuk membuat (atau tidak) paket baru untuk R. Untuk lebih spesifik, saya akan menambahkan bahwa pertanyaannya bukan tentang alasan untuk gunakan R itu sendiri, lebih lanjut tentang keputusan untuk mengkompilasi berbagai skrip dan untuk mengintegrasikannya dalam paket baru.

Di antara poin-poin yang dapat mengarah pada keputusan ini, saya telah memikirkan (dengan cara yang tidak lengkap), tentang:

• tidak adanya paket lain dalam sub-bidang yang sama;
• kebutuhan untuk bertukar dengan peneliti lain dan memungkinkan reproduksibilitas percobaan;

Dan di antara poin-poin yang bisa mengarah pada keputusan yang bertentangan:

• bagian dari metode yang digunakan sudah ada dalam beberapa paket lain;
• jumlah fungsi baru tidak cukup untuk membenarkan membuat paket independen baru.

Saya mungkin sudah lupa banyak poin yang bisa masuk dalam daftar, dan juga, kriteria ini tampaknya sebagian subjektif. Jadi, apa yang menurut Anda harus dibenarkan, dan pada titik mana, untuk mulai menyatukan berbagai fungsi dan data dalam paket baru yang terdokumentasi dan tersedia secara luas?

Saya tidak memprogram dalam R, tetapi saya memprogram sebaliknya, dan saya tidak melihat masalah khusus-R di sini.

Saya membayangkan bahwa kebanyakan orang pertama-tama menulis sesuatu karena mereka benar-benar menginginkannya sendiri. Sebaliknya, setiap perasaan bahwa seseorang harus menerbitkan perangkat lunak karena itu yang harus dilakukan harus ditentang dengan kuat. Orang pintar bisa menjadi programmer yang buruk, dan seringkali memang demikian.

Menjadi perusahaan publik tampaknya masalah kepercayaan diri bahwa Anda memiliki sesuatu yang sama baiknya atau lebih baik daripada apa yang sudah publik dan mengisi celah. Mengetahui bahwa orang lain ingin melakukan hal yang sama tentu saja merupakan dorongan.

Jika Anda ragu, jangan publikasikan. Di banyak komunitas, ada masalah kontrol kualitas perangkat lunak biasa-biasa saja atau kereta yang dirilis oleh programmer tidak kritis atau tidak berpengalaman, meskipun seberapa buruk masalah tetap terbuka untuk diperdebatkan. Optimis merasa bahwa hal-hal sepele hanya dapat diabaikan dan bahwa pengguna akan mengekspos bug dan keterbatasan dengan cukup cepat; pesimis merasa bahwa kita tenggelam dalam hal-hal berkualitas buruk dan sulit untuk memberitahu pemenang dari yang kalah. (Di sisi lain, pengalaman yang diperoleh dari publikasi adalah bagian dari apa yang memungkinkan programmer untuk meningkat.)

Mungkin ada buku tentang ini, tetapi beberapa petunjuk muncul dalam pikiran:

1. Dokumentasi yang berkualitas baik membedakan perangkat lunak yang baik dan juga kode yang baik, bahkan terkadang lebih jelas. Jangan pernah meremehkan berapa banyak pekerjaan yang akan dibutuhkan untuk menyediakan dokumentasi yang layak untuk kode tersebut. Programmer R sering tampaknya mengharuskan pengguna R tahu sebanyak yang mereka lakukan tentang teknik yang diimplementasikan dan mendokumentasikan secara minimal ....

2. Sejauh mungkin, uji kode Anda sehingga Anda dapat mereproduksi solusi yang dipublikasikan dengan data nyata dari tempat lain. (Jika Anda membuat kode untuk sesuatu yang benar-benar baru, itu mungkin lebih sulit, tetapi bukan tidak mungkin. Juga, Anda mungkin sering bertanya-tanya apakah itu bug mereka atau milik Anda.)

3. Pemrogram sering meremehkan kemampuan pengguna untuk membuang data yang tidak cocok pada suatu program. Jadi, pikirkan tentang apa yang bisa salah, misalnya dengan nilai yang hilang, nol jika suatu program mengasumsikan positif, dll, dll. (Yang jinak mengambil di sini adalah bahwa tugas para pengguna untuk menemukan masalah dan meningkatkan kode melalui umpan balik mereka , tetapi program yang mudah rusak tidak akan meningkatkan reputasi Anda.)

Ini adalah pertanyaan penting dan praktis. Mari kita mulai dengan membedakan antara menulis paket dan menerbitkannya di CRAN.

Alasan untuk tidak menulis paket:

• Penghematan biaya.
• Kurang pengalaman.

Alasan untuk menulis paket R:

• Berbagi dengan orang dan platform.
• Memaksa kode dan proses kerja yang rapi.
• Kemudahan penggunaan (bahkan untuk diri sendiri) ketika fungsi mulai menumpuk.

Alasan untuk mengirimkan paket (CRAN, Bioconductor, ...):

• Kontribusi kepada masyarakat.
• Kemudahan distribusi.

Ingat bahwa ada opsi # 3; Anda dapat meminta pengelola paket yang relevan untuk memasukkan kode atau data Anda.

Pemicu pribadi saya untuk pengemasan adalah:

• Saya menemukan saya lagi menggunakan beberapa kode yang pernah saya tulis untuk proyek analisis data lain.
• Saya pikir saya akan membutuhkan metode yang baru saja saya tulis lagi.

• Seorang kolega meminta saya kode. Sebagian besar dari kode yang saya tulis setidaknya berdasarkan permintaan rekan-rekan (yang menggunakan R tetapi tidak memprogram sendiri sebanyak itu) seperti untuk saya sendiri.

• Saya menggunakan persyaratan formal suatu paket (dokumentasi) untuk "memaksa" saya membersihkan dan mendokumentasikan kode saya.

Saya setuju dengan @JohnRos bahwa ada cukup perbedaan antara menulis paket dan menerbitkan paket.

• Saya biasanya paket awal, tetapi kemudian membuat paket hanya "semipublic". Artinya, mungkin tersedia di server internal (atau di r-forge), sehingga kolega saya dapat mengakses paket. Tetapi saya menerbitkan ke CRAN hanya setelah paket telah digunakan selama berbulan-bulan atau bahkan beberapa tahun oleh rekan-rekan dekat. Ini tidak memunculkan semua bug sesuai dengan poin @Nick Cox # 3, tetapi cukup banyak.
  Versi paket (saya cantumkan tanggal setelah tanda hubung dalam nomor versi) membuatnya mudah untuk memperbaiki hal-hal ("untuk melakukan ini dan itu, pastikan Anda menginstal setidaknya versi minggu lalu")

• Menurut kontrak kerja saya, majikan saya memiliki kata terakhir pada keputusan apakah dan bagaimana sebuah paket dapat dipublikasikan ke dunia luar.

Hal mana saya tidak belum memiliki strategi yang baik untuk kemasan adalah data.

Komentar untuk daftar alasan Anda:

• tidak adanya paket lain dalam sub-bidang yang sama;

Tidak menemukan paket yang melakukan apa yang saya butuhkan untuk saya memicu penulisan kode, tetapi tidak ada hubungannya dengan keputusan apakah akan mengemas atau tidak.

• kebutuhan untuk bertukar dengan peneliti lain dan memungkinkan reproduksibilitas percobaan;

Secara pasti. Mungkin sudah perlu berbagi antara beberapa komputer yang saya gunakan.

Dan di antara poin-poin yang bisa mengarah pada keputusan yang bertentangan:

• bagian dari metode yang digunakan sudah ada dalam beberapa paket lain;

Anda dapat mengimpor metode-metode itu ke dalam paket / kode Anda: ini adalah titik terhadap penulisan kode tersebut, tetapi hanya secara tidak langsung berkaitan dengan pengemasan

• jumlah fungsi baru tidak cukup untuk membenarkan membuat paket independen baru.

Bagi saya, tidak ada jumlah minimum fungsi untuk memulai paket. Dalam paket pengalaman saya cenderung tumbuh "secara otomatis". Sebaliknya, setelah saya menemukan diri saya beberapa kali bercabang dari paket baru dari yang lain (karena misalnya beberapa fungsi pembantu pada akhirnya ternyata berbeda secara tematis dan berguna dalam situasi lain juga), saya sekarang agak segera membuat paket baru.

Juga, jika Anda tidak menulis dokumentasi dan tes, ini bisa menjadi jumlah pekerjaan yang penghalang ketika sejumlah fungsi "cukup" untuk membuat paket menumpuk.
(Jika Anda segera menulisnya, maka upaya tambahan untuk memasukkannya ke dalam paket dapat diabaikan begitu Anda mengetahui alur kerjanya).

Saya akan mengatakan membuat sebuah paket setiap kali Anda melakukan serangkaian tugas serupa dalam R yang cukup besar sehingga Anda akan mendapat manfaat dari sebuah paket di mana Anda dapat meletakkan sesuatu di namespace (untuk menghindari konflik dengan fungsi yang bernama sama), di mana Anda dapat menulis dokumentasi. Saya bahkan memiliki paket di github untuk menggabungkan fungsi-fungsi yang tidak berhubungan, tetapi saya sering menggunakannya sehingga saya pikir mereka pantas mendapatkan dokumentasi, file manual, dll.

Case use lain bisa ketika mengirimkan kertas, jika Anda memiliki sejumlah fungsi Anda dapat dengan mudah membuat paket, termasuk dokumentasi untuk fungsi-fungsi itu, contoh untuk setiap fungsi, dan tutorial tentang cara menggunakannya. Dan Anda tidak perlu menaruhnya di CRAN, seperti yang dikatakan dalam jawaban di atas. Ini bisa menjadi luar biasa untuk reproduksibilitas.

Tiga alat yang menurut saya penting:

• devtools pkg , untuk membuatnya sangat mudah untuk membangun paket (juga lihat wiki di halaman devtools github
• roxygen2 pkg , untuk memudahkan membuat dokumentasi penulisan untuk paket Anda
• GitHub, Anda dapat menggunakan install_github(atau menginstal_bitbucket, dll.) Untuk menginstal langsung dari GitHub, yang bagus untuk berbagi dengan orang lain.

Saya setuju dengan semua yang saya baca sejauh ini. Semua alasan itu adalah praktik pemrograman yang baik dan tidak berlaku untuk R khususnya. Namun saya menemukan diri saya menulis paket R sebagian besar waktu, dan untuk alasan lain. Jadi saya akan menambahkan:

Alasan spesifik R untuk menulis paket R:

• karena Anda menulis dalam C

Setiap kali Anda menggunakan bahasa asing seperti C, C ++ atau FORTRAN (kebanyakan untuk komputasi berkinerja tinggi), menulis sebuah paket sangat bermanfaat. Jika Anda memiliki lebih dari satu atau dua fungsi, Anda dengan cepat berakhir dengan file-file di semua tempat dan ketergantungan antara kode R dan C yang sulit dipertahankan dan di-port.

Salah satu alasan yang tidak disebutkan dalam jawaban bagus lainnya: Anda memiliki proyek analisis data yang besar atau kompleks. Pengemasan, pertama, data sebagai paket, dan kemudian diperluas dengan fungsi-fungsi yang berguna untuk mengubah, memplot, atau menghitung analisis tertentu. Dengan cara ini Anda mendapatkan versi data terdokumentasi lengkap dengan semua fungsi yang digunakan untuk menghitung analisis yang dilaporkan. Kemudian laporan dari proyek dapat ditulis menggunakan rajutan atau paket lain untuk penelitian yang dapat direproduksi!

Ini secara signifikan dapat menghemat waktu jika beberapa analisis ulang harus dilakukan, atau bahkan dapat dipublikasikan (atau setengah diterbitkan) jika analisis diterbitkan.