Я не программирую на R, но я программирую иначе, и здесь я не вижу проблем, специфичных для R.
Я предполагаю, что большинство людей сначала что-то пишут, потому что они действительно хотят этого для себя. И наоборот, любое чувство, что кто-то должен публиковать программное обеспечение, потому что это то, что нужно делать, должно решительно сопротивляться. Умные люди могут быть паршивыми программистами, и часто так и есть.
Публичное выступление кажется вопросом уверенности в том, что у вас есть что-то такое же хорошее или лучшее, чем то, что уже является публичным и заполняет пробел. Знание того, что другие люди хотят делать то же самое, безусловно, является стимулом.
Если вы сомневаетесь, не публикуйте. Во многих сообществах существует проблема контроля качества посредственного или ошибочного программного обеспечения, выпущенного некритическими или неопытными программистами, хотя насколько серьезной является проблема, остается открытым для обсуждения. Оптимисты считают, что пустяки можно просто игнорировать и что пользователи будут достаточно быстро выявлять ошибки и ограничения; Пессимисты чувствуют, что мы тонем в некачественных вещах, и трудно отличить победителей от проигравших. (С другой стороны, опыт, полученный от публикации, является частью того, что позволяет программистам улучшаться.)
Об этом может быть книга, но на ум приходят несколько указателей:
Качественная документация отличает хорошее программное обеспечение и хороший код, иногда даже более очевидный. Никогда не стоит недооценивать, сколько работы потребуется для предоставления документации, которой заслуживает код. Программисты R часто требуют, чтобы пользователи R знали столько же, сколько они знают о внедряемой технике, и минимально документировали…
По мере возможности тестируйте свой код, чтобы вы могли воспроизводить опубликованные решения с реальными данными из других источников. (Если вы кодируете что-то совершенно новое, это может быть более трудным, но не невозможным. Кроме того, вы часто задаетесь вопросом, является ли это их ошибкой или вашей.)
Программисты часто недооценивают способность пользователей бросать неподходящие данные в программу. Итак, подумайте о том, что может пойти не так, например, с пропущенными значениями, нулями, если программа предполагает положительный результат, и т. Д. И т. Д. (В этом случае задача пользователей - найти проблемы и улучшить код с помощью обратной связи. , но легко ломающаяся программа не улучшит вашу репутацию.)
sos::findFnнаходит этот критерий достаточно важным, чтобы поместить эту информацию в таблицу результатов!)? Демо? Веб-страница с дополнительной информацией? Дает ли вамcitationнадлежащую статью или книгу № 2, вы можете отправлять примеры данных вместе с вашим кодом, так что даже если нет другой реализации, с которой вы можете проверить свой код, теперь другие могут проверить свою реализацию против вашей.Это важный и практический вопрос. Давайте начнем с того, что будем различать написание пакета и его публикацию в CRAN.
Причины не писать пакет:
Причины, чтобы написать пакет R:
Причины для отправки пакета (CRAN, Bioconductor, ...):
источник
Помните, что есть вариант № 3; Вы можете попросить сопровождающего соответствующего пакета включить ваш код или данные.
источник
Мои личные триггеры для упаковки:
Коллега просит у меня код. Существенная часть кода, который я пишу, по крайней мере, столько же по запросу коллег (которые используют R, но сами не программируют), чем для себя.
Я использую формальные требования пакета (документации), чтобы «заставить» меня очистить и документировать мой код.
Я согласен с @JohnRos, что существует большая разница между написанием пакета и его публикацией.
Я обычно упаковываю вещи рано, но потом делаю упаковку только «полупубликой». То есть он может быть доступен на внутреннем сервере (или на r-forge), поэтому мои коллеги могут получить доступ к пакету. Но я публикую в CRAN только после того, как пакет использовался близкими коллегами в течение нескольких месяцев или даже нескольких лет. Это не поднимает все ошибки в соответствии с пунктом № 3 @Nick Cox, но изрядное их количество.
Версии пакета (я поставил дату после тире в номере версии) позволяют легко что-то исправить («чтобы сделать это и то, убедитесь, что вы введете хотя бы версию прошлой недели»)
Согласно моему рабочему контракту, мой работодатель имеет последнее слово при принятии решения о том, можно ли и как опубликовать пакет во внешнем мире.
Дело в том, где я не еще есть стратегия хорошо для упаковки данных.
Комментарии к вашему списку причин:
Отсутствие пакета, который делает то, что мне нужно, вызывает написание кода, но это не имеет отношения к решению, упаковывать или нет.
Определённо. Возможно, уже нужно делить между несколькими компьютерами, которые я использую.
Вы могли бы импортировать эти методы в свой пакет / код: это противоречит написанию такого кода, но только косвенно связано с упаковкой.
Для меня нет минимального количества функций для запуска пакета. По моему опыту, пакеты имеют тенденцию расти «автоматически». Напротив, после того, как я несколько раз обнаружил, что разветвляю новый пакет из другого (потому что, например, некоторые вспомогательные функции, в конце концов, оказались тематически разными и полезными и в других ситуациях), я теперь довольно создание новых пакетов немедленно.
Кроме того, если вы не написали документацию и тесты, это может быть чрезмерно трудоемким, если «накопилось» достаточное количество функций для создания пакета.
(Если вы пишете их немедленно, то дополнительные усилия по добавлению их в пакет незначительны, если вы знаете рабочий процесс).
источник
Я бы сказал, создайте пакет всякий раз, когда вы выполняете достаточно большой набор похожих задач в R, чтобы вы могли воспользоваться пакетом, в котором вы можете помещать вещи в пространство имен (чтобы избежать конфликтов с функциями с одинаковыми именами), куда вы можете написать документация. У меня даже есть пакет на GitHub для связывания множества функций, которые не связаны, но я использую так часто, что я думал, что они заслуживают документацию, файлы man и т. Д.
Другой вариант использования может быть при отправке документа, если у вас есть ряд функций, вы можете легко создать пакет, включая документацию по этим функциям, примеры для каждой функции и учебное пособие по ее использованию. И вам не нужно помещать это на CRAN, как сказано в ответах выше. Это может быть здорово для воспроизводимости.
Три инструмента, которые я бы сказал, важны:
install_github(или аналогично install_bitbucket и т. Д.) Для установки непосредственно из GitHub, который удобен для совместного использования с другими.источник
Я согласен со всем, что я прочитал до сих пор. Все эти причины являются хорошей практикой программирования и не относятся к R в частности. Однако большую часть времени я пишу пакеты R, и по еще одной причине. Поэтому я добавлю:
R-конкретная причина, чтобы написать пакет R:
Каждый раз, когда вы используете иностранные языки, такие как C, C ++ или FORTRAN (в основном для высокопроизводительных вычислений), написание пакета в значительной степени стоит проблем. Если у вас есть более одной или двух функций, вы быстро получите файлы повсюду и зависимости между кодом R и C, которые сложно поддерживать и переносить.
источник
Одна причина, не упомянутая в других отличных ответах: у вас большой или сложный проект анализа данных. Упаковка, вначале, данных в виде пакета, а затем расширение с помощью полезных функций для преобразования, построения графика или вычисления конкретного анализа. Таким образом, вы получите документированную версию данных со всеми функциями, используемыми для расчета анализа, представленного в отчете. Тогда отчет (ы) из проекта может быть написан с использованием knitr или других пакетов для воспроизводимых исследований!
Это может значительно сэкономить время, если необходимо провести повторный анализ, или даже опубликовать (или полуопубликовать), если анализ будет опубликован.
источник