Чому і коли створюється пакет R?

Я розумію, що це питання досить широке, але мені цікаво, що має бути вирішальним моментом у вирішенні питання про створення (чи ні) нового пакету для Р. Щоб бути більш конкретним, я додам, що питання не в тому, щоб пояснити використовуйте R саме по собі, докладніше про рішення зібрати різні сценарії та інтегрувати їх у новий пакет.

Серед точок, які можуть призвести до цих рішень, я подумав (доволі невичерпно) про:

• відсутність інших пакетів у тому ж підполі;
• необхідність обміну з іншими дослідниками та забезпечення відтворюваності експериментів;

І серед пунктів, які можуть призвести до протилежного рішення:

• частина методів, які вже використовуються в деяких інших пакетах;
• кількість нових функцій, недостатня для обгрунтування створення нового незалежного пакету.

Я, можливо, забув багато пунктів, які могли б потрапити в будь-який список, а також ці критерії здаються частково суб'єктивними. Отже, що, на вашу думку, повинно виправдовувати і в який момент починати об'єднання різних функцій та даних у новому документованому та широко доступному пакеті?

Я не програмую на R, але програмую інакше, і тут не бачу жодної проблеми, що стосується R.

Я думаю, що більшість людей спочатку щось пишуть, тому що вони дуже хочуть цього для себе. І навпаки, будь-якому відчуттю, що слід публікувати програмне забезпечення, тому що це робити, слід сильно протистояти. Розумні люди можуть бути паршивими програмістами, і часто є.

Виходити на публіку здається справою впевненості, що у вас є щось таке ж добре чи краще, ніж те, що вже є публічним, і заповнює прогалину. Знання того, що інші люди хочуть зробити те саме, - це, безумовно, поштовх.

Якщо ви сумніваєтесь, не публікуйте. У багатьох громадах існує проблема контролю якості посереднього або помилкового програмного забезпечення, випущеного некритичними або недосвідченими програмістами, хоча наскільки погана проблема залишається відкритою для дискусій. Оптимісти вважають, що дрібниці можна просто ігнорувати і що користувачі виставлятимуть помилки та обмеження досить швидко; песимісти відчувають, що ми топимось у поганій якості, і важко сказати переможцям від переможених. (З іншого боку, досвід, отриманий від публікації, є частиною того, що дозволяє програмістам вдосконалюватися.)

Про це може бути книга, але на думку спадають кілька покажчиків:

1. Документація належної якості відрізняє хороше програмне забезпечення, а також хороший код, справді іноді більш очевидно. Ніколи не варто недооцінювати, скільки роботи знадобиться для надання документації, якої заслуговує код. Програмісти R часто, як видається, вимагають, щоб користувачі R знали так само, як вони роблять про техніку, яку впроваджують, і документують мінімально ....

2. Наскільки це можливо, протестуйте свій код, щоб ви могли відтворити опубліковані рішення з реальними даними з інших країн. (Якщо ви кодуєте щось абсолютно нове, це може бути складніше, але не неможливо. Крім того, ви часто можете задатися питанням, чи це їх помилка чи ваша.)

3. Програмісти часто недооцінюють здатність користувачів кидати в програму невідповідні дані. Отже, подумайте про те, що може піти не так, наприклад, з відсутніми значеннями, нулями, якщо програма сприймає позитивні показники тощо, тощо. , але програма, яка легко виходить з ладу, не покращить вашу репутацію.)

Це важливе і практичне питання. Почнемо з розрізнення написання пакета та публікації його на CRAN.

Причини не писати пакет:

• Ефективність витрат.
• Відсутність досвіду.

Причини написання пакету R:

• Спільний доступ з людьми та платформами.
• Створює акуратний код і робочий процес.
• Простота використання (навіть для себе), коли функції починають накопичуватися.

Причини подати пакет (CRAN, Bioconductor, ...):

• Внесок до громади.
• Простота розповсюдження.

Пам'ятайте, що є варіант №3; ви можете попросити технічного обслуговування відповідного пакета включити ваш код або дані.

Мої особисті тригери для упаковки:

• Я вважаю, що знову використовую код, який я колись написав для іншого проекту аналізу даних.
• Думаю, мені знадобиться метод, про який я щойно написав.

• Колега просить у мене коду. Значна частина коду, який я пишу, - це як мінімум стільки ж на замовлення колег (які використовують R, але самі не програмують), скільки для мене.

• Я використовую формальні вимоги пакету (документації), щоб "примусити" мене очистити і документувати свій код.

Я погоджуюся з @JohnRos, що між написанням пакету та публікацією пакету існує велика різниця.

• Я зазвичай пакую рано, але потім роблю пакунок лише "напівпублічним". Тобто він може бути доступний на внутрішньому сервері (або на r-forge), тому мої колеги можуть отримати доступ до пакету. Але я публікую в CRAN лише після того, як пакет використовувався місяцями або навіть кількома роками близькими колегами. Це не призводить до появи всіх помилок відповідно до пункту №3 @Nick Cox, але їх досить багато.
  Версії пакету (я вказую дату після тире в номері версії) полегшують виправлення речей ("щоб зробити це та інше, переконайтеся, що ви вкажете принаймні версію минулого тижня")

• Згідно з моїм робочим контрактом, у мого роботодавця є останнє слово щодо того, чи можна і як пакет можна публікувати у зовнішньому світі.

Те, де я ще не маю гарної стратегії упаковки, - це дані.

Коментарі до вашого списку причин:

• відсутність інших пакетів у тому ж підполі;

Якщо я не знаходжу пакет, який виконує те, що мені потрібно, викликає написання коду, але це не має відношення до рішення, пакувати чи ні.

• необхідність обміну з іншими дослідниками та забезпечення відтворюваності експериментів;

Однозначно. Можливо, вже є необхідність ділитися між декількома комп'ютерами, якими я користуюся.

І серед пунктів, які можуть призвести до протилежного рішення:

• частина методів, які вже використовуються в деяких інших пакетах;

Ви можете імпортувати ці методи у свій пакунок / код: це суперечить написанню такого коду, але стосується упаковки лише опосередковано.

• кількість нових функцій, недостатня для обгрунтування створення нового незалежного пакету.

Для мене немає мінімальної кількості функцій для запуску пакету. На мій досвід, пакети, як правило, зростають "автоматично". Навпаки, після того, як я кілька разів відгалужував новий пакет від іншого (тому що, наприклад, деякі допоміжні функції зрештою виявилися тематично різними і корисними і в інших ситуаціях), я зараз скоріше створення нових пакетів негайно.

Крім того, якщо ви не написали документацію та тести, це може бути непосильним обсягом роботи, коли накопичилася "достатня" кількість функцій для створення пакету.
(Якщо ви все-таки пишете їх негайно, то додаткові зусилля щодо внесення їх у пакет незначні, коли ви знаєте робочий процес).

Я б сказав, що створюйте пакет кожен раз, коли ви виконуєте достатньо великий набір подібних завдань в R, що ви отримаєте користь від пакету, в який можна помістити речі в простір імен (щоб уникнути конфліктів з аналогічно названими функціями), куди ви можете писати документація. У мене навіть є пакет на github для з’єднання пакету захоплення функцій, які не пов'язані між собою, але я використовую так часто, що я вважав, що вони заслуговують документації, файлів man тощо.

Інший випадок використання може бути при подачі паперу, якщо у вас є ряд функцій, ви можете легко створити пакет, включаючи документацію для цих функцій, приклади кожної функції та навчальний посібник щодо її використання. І вам не потрібно ставити це на CRAN, як сказано у відповідях вище. Це може бути дивним для відтворюваності.

Три інструменти, які я б сказав, важливі:

• devtools pkg , щоб зробити його легко простим у складанні пакунків (також дивіться вікі на сторінках gitub devtools
• roxygen2 кг , щоб спростити написання документації для вашого пакету
• GitHub, Ви можете використовувати install_github(або аналогічно install_bitbucket тощо) для встановлення безпосередньо з GitHub, що приємно для обміну з іншими.

Я згоден з усім, що я читав досі. Усі ці причини є хорошою практикою програмування і не стосуються R особливо. Однак я вважаю, що пишуть R-пакети більшу частину часу, і ще з іншої причини. Тож я додам:

Причина, що стосується R, щоб написати пакет R:

• бо ти пишеш на С

Кожен раз, коли ви використовуєте іноземні мови, такі як C, C ++ або FORTRAN (в основному для високоефективних обчислень), написання пакету значною мірою коштує проблем. Якщо у вас є більше однієї або двох функцій, ви швидко перебуваєте з файлами повсюдно і залежностями між кодом R і C, який важко підтримувати і переносити.

Одна з причин, яка не згадується в інших відмінних відповідях: у вас великий чи складний проект аналізу даних. Упаковка, спочатку, дані у вигляді пакету, а потім розширення корисними функціями для перетворення, побудови, чи обчислення конкретних аналізів. Таким чином ви отримуєте документально підтверджену версію даних у комплекті з усіма функціями, які використовуються для обчислення звітного аналізу. Тоді доповідь (-и) проекту можуть бути написані за допомогою плетіння або інших пакетів для відтворюваних досліджень!

Це може значно заощадити час, якщо потрібно зробити якийсь повторний аналіз, або він навіть може бути опублікований (або напівпублікований), якщо аналіз буде опублікований.