Warum und wann ein R-Paket erstellen?

Ich verstehe, dass diese Frage recht weit gefasst ist, aber ich frage mich, was die entscheidenden Punkte für die Entscheidung sein sollten, ein neues Paket für R zu erstellen (oder nicht). Um genauer zu sein, möchte ich hinzufügen, dass es bei der Frage nicht um die Gründe geht Verwenden Sie R an sich, um mehr über die Entscheidung zu erfahren, verschiedene Skripte zu kompilieren und in ein neues Paket zu integrieren.

Unter den Punkten, die zu diesen Entscheidungen führen könnten, habe ich (auf eine nicht erschöpfende Weise) gedacht:

• das Nichtvorhandensein anderer Pakete in demselben Unterfeld;
• Notwendigkeit des Austauschs mit anderen Forschern und Ermöglichung der Reproduzierbarkeit von Experimenten;

Und zu den Punkten, die zu einer gegenteiligen Entscheidung führen könnten:

• ein Teil der verwendeten Methoden ist bereits in einigen anderen Paketen enthalten;
• Die Anzahl der neuen Funktionen ist nicht ausreichend, um die Erstellung eines neuen unabhängigen Pakets zu rechtfertigen.

Ich hätte vielleicht viele Punkte vergessen, die in beiden Listen auftauchen könnten, und auch diese Kriterien scheinen teilweise subjektiv zu sein. Also, was würden Sie sagen, sollte es rechtfertigen und zu welchem ​​Zeitpunkt beginnen, verschiedene Funktionen und Daten in einem neuen dokumentierten und breit verfügbaren Paket zusammenzuführen?

Ich programmiere nicht in R, aber ich programmiere anders und sehe hier kein R-spezifisches Problem.

Ich stelle mir vor, dass die meisten Leute zuerst etwas schreiben, weil sie es wirklich für sich selbst wollen. Umgekehrt sollte jedem Gefühl, dass man Software veröffentlichen sollte, weil es das ist, was zu tun ist, stark widerstanden werden. Kluge Köpfe können miese Programmierer sein und sind es oft.

Wenn Sie an die Börse gehen, müssen Sie zuversichtlich sein, dass Sie etwas haben, das genauso gut oder besser ist als das, was bereits öffentlich ist und eine Lücke füllt. Zu wissen, dass andere das Gleiche wollen, ist mit Sicherheit eine Bereicherung.

Wenn Sie Zweifel haben, veröffentlichen Sie nicht. In vielen Communities gibt es ein Qualitätskontrollproblem mit mittelmäßiger oder fehlerhafter Software, die von unkritischen oder unerfahrenen Programmierern veröffentlicht wird. Wie schlimm das Problem ist, bleibt jedoch offen. Optimisten sind der Ansicht, dass Kleinigkeiten einfach ignoriert werden können und dass Benutzer Fehler und Einschränkungen schnell genug aufdecken. Pessimisten haben das Gefühl, dass wir in schlechter Qualität ertrinken und es schwierig ist, die Gewinner von den Verlierern zu unterscheiden. (Andererseits sind die Erfahrungen aus der Veröffentlichung ein Teil dessen, was es Programmierern ermöglicht, sich zu verbessern.)

Es könnte ein Buch darüber geben, aber ein paar Hinweise fallen mir ein:

1. Gute Dokumentation zeichnet gute Software und guten Code aus, manchmal sogar deutlicher. Unterschätzen Sie niemals, wie viel Arbeit erforderlich ist, um die Dokumentation bereitzustellen, die der Code verdient. R-Programmierer scheinen oft zu verlangen, dass R-Benutzer genau so viel über die implementierte Technik wissen und minimal dokumentieren.

2. Testen Sie Ihren Code so weit wie möglich, damit Sie veröffentlichte Lösungen mit realen Daten von anderswo reproduzieren können. (Wenn Sie etwas völlig Neues programmieren, ist dies möglicherweise schwieriger, aber nicht unmöglich. Außerdem fragen Sie sich häufig, ob es sich um einen Fehler handelt oder um Ihren.)

3. Programmierer unterschätzen oft die Fähigkeit von Benutzern, ungeeignete Daten auf ein Programm zu werfen. Denken Sie also darüber nach, was schief gehen könnte, z. B. mit fehlenden Werten, Nullen, wenn ein Programm positive Werte annimmt, usw. usw. (Das Gute dabei ist, dass die Benutzer die Probleme finden und den Code durch ihr Feedback verbessern müssen , aber ein Programm, das leicht zusammenbricht, wird Ihren Ruf nicht verbessern.)

Dies ist eine wichtige und praktische Frage. Beginnen wir damit, zwischen dem Schreiben eines Pakets und dem Veröffentlichen auf CRAN zu unterscheiden.

Gründe, kein Paket zu schreiben:

• Kosteneffizienz.
• Mangel an Erfahrung.

Gründe, ein R-Paket zu schreiben:

• Teilen mit Menschen und Plattformen.
• Erzwingt einen aufgeräumten Code und Arbeitsprozess.
• Einfache Bedienung (auch für Selbstfahrer), wenn sich Funktionen ansammeln.

Gründe für die Einreichung eines Pakets (CRAN, Bioconductor, ...):

• Beitrag zur Community.
• Einfache Verteilung.

Denken Sie daran, dass es Option 3 gibt. Sie können den Betreuer eines relevanten Pakets bitten, Ihren Code oder Ihre Daten einzuschließen.

Meine persönlichen Auslöser für die Verpackung sind:

• Ich verwende wieder Code, den ich einmal für ein anderes Datenanalyseprojekt geschrieben habe.
• Ich denke, ich brauche die Methode, die ich gerade geschrieben habe.

• Ein Kollege fragt mich nach Code. Ein wesentlicher Teil des Codes, den ich schreibe, ist mindestens so viel auf Anfrage von Kollegen (die R verwenden, aber selbst nicht so viel programmieren) wie für mich.

• Ich verwende die formalen Anforderungen eines Pakets (Dokumentation), um die Bereinigung und Dokumentation meines Codes zu erzwingen.

Ich stimme @JohnRos zu, dass es einen großen Unterschied zwischen dem Schreiben eines Pakets und dem Veröffentlichen des Pakets gibt.

• Ich packe normalerweise früh, mache das Paket dann aber nur "halböffentlicher". Das heißt, es ist möglicherweise auf einem internen Server (oder auf r-forge) verfügbar, sodass meine Kollegen auf das Paket zugreifen können. Ich veröffentliche jedoch erst dann bei CRAN, wenn das Paket über Monate oder sogar einige Jahre von engen Kollegen verwendet wurde. Dies bringt nicht alle Bugs nach @ Nick Cox Punkt 3, aber eine ganze Menge von ihnen.
  Die Versionen des Pakets (ich setze das Datum nach dem Bindestrich in die Versionsnummer) machen es einfach, Dinge zu reparieren ("um dies und das zu tun, stellen Sie sicher, dass Sie mindestens die Version der letzten Woche installieren")

• Gemäß meinem Arbeitsvertrag hat mein Arbeitgeber das letzte Wort über die Entscheidung, ob und wie ein Paket nach außen veröffentlicht werden kann.

Die Sache, bei der ich noch keine gute Strategie für das Verpacken habe, sind Daten.

Anmerkungen zu Ihrer Liste der Gründe:

• das Nichtvorhandensein anderer Pakete in demselben Unterfeld;

Wenn ich kein Paket finde, das das tut, was ich für mich brauche , wird der Code geschrieben, aber das hat nichts mit der Entscheidung zu tun, ob ich paketiere oder nicht.

• Notwendigkeit des Austauschs mit anderen Forschern und Ermöglichung der Reproduzierbarkeit von Experimenten;

Endgültig. Möglicherweise muss ich das schon zwischen mehreren Computern teilen, die ich benutze.

Und zu den Punkten, die zu einer gegenteiligen Entscheidung führen könnten:

• ein Teil der verwendeten Methoden ist bereits in einigen anderen Paketen enthalten;

Sie könnten diese Methoden in Ihr Paket / Code importieren: Dies ist ein Punkt, der gegen das Schreiben eines solchen Codes spricht , hat aber nur indirekt mit dem Verpacken zu tun.

• Die Anzahl der neuen Funktionen ist nicht ausreichend, um die Erstellung eines neuen unabhängigen Pakets zu rechtfertigen.

Für mich gibt es keine Mindestanzahl von Funktionen, um ein Paket zu starten. Meiner Erfahrung nach wachsen Pakete "automatisch". Im Gegenteil, nachdem ich ein paar Mal ein neues Paket von einem anderen abgezweigt habe (weil sich zum Beispiel einige Hilfsfunktionen am Ende als thematisch anders und auch in anderen Situationen nützlich erwiesen haben), bin ich jetzt eher Erstellen Sie sofort neue Pakete.

Wenn Sie keine Dokumentation und Tests geschrieben haben, kann dies ein unerschwinglicher Arbeitsaufwand sein, wenn sich eine "ausreichende" Anzahl von Funktionen zum Erstellen eines Pakets angesammelt hat.
(Wenn Sie sie sofort schreiben, ist der zusätzliche Aufwand für die Erstellung eines Pakets vernachlässigbar, sobald Sie den Workflow kennen.)

Ich würde sagen, erstellen Sie ein Paket, wenn Sie eine ausreichend große Menge ähnlicher Aufgaben in R ausführen, um von einem Paket zu profitieren, in dem Sie Dinge in einen Namespace schreiben können (um Konflikte mit Funktionen mit ähnlichem Namen zu vermeiden) Dokumentation. Ich habe sogar ein Paket auf Github, um eine Sammlung von Funktionen zusammenzustellen, die nichts miteinander zu tun haben, aber ich benutze sie so oft, dass ich dachte, sie hätten Dokumentation, Man-Dateien usw. verdient.

Ein weiterer Anwendungsfall könnte sein, dass Sie beim Einreichen eines Dokuments mit einer Reihe von Funktionen auf einfache Weise ein Paket erstellen können, einschließlich einer Dokumentation für diese Funktionen, Beispielen für jede Funktion und eines Tutorials zu ihrer Verwendung. Und Sie müssen es nicht auf CRAN setzen, wie in den obigen Antworten angegeben. Dies könnte für die Reproduzierbarkeit fantastisch sein.

Drei Tools, die ich sagen würde, sind wichtig:

• devtools pkg , um das Erstellen von Paketen zu vereinfachen (siehe auch das Wiki auf den devtools-Github-Seiten)
• roxygen2 pkg , um das Schreiben von Dokumentationen für Ihr Paket zu vereinfachen
• GitHub, Mit install_github(oder ähnlich install_bitbucket usw.) können Sie direkt von GitHub aus installieren, was sich gut zum Teilen mit anderen eignet.

Ich bin mit allem einverstanden, was ich bisher gelesen habe. All diese Gründe sind eine gute Programmierpraxis und gelten nicht speziell für R. Allerdings schreibe ich die meiste Zeit R-Pakete und das aus einem anderen Grund. Also werde ich hinzufügen:

R-spezifischer Grund, ein R-Paket zu schreiben:

• weil du in C schreibst

Jedes Mal, wenn Sie Fremdsprachen wie C, C ++ oder FORTRAN (meistens für Hochleistungscomputer) verwenden, lohnt es sich, ein Paket zu schreiben. Wenn Sie mehr als eine oder zwei Funktionen haben, werden Sie schnell mit Dateien überall und Abhängigkeiten zwischen dem R- und C-Code konfrontiert, die schwierig zu warten und zu portieren sind.

Ein Grund, der in den anderen ausgezeichneten Antworten nicht erwähnt wird: Sie haben ein großes oder komplexes Datenanalyseprojekt. Packen Sie zuerst die Daten als Paket und erweitern Sie sie dann mit nützlichen Funktionen, um bestimmte Analysen zu transformieren, zu zeichnen oder zu berechnen. Auf diese Weise erhalten Sie eine dokumentierte Version der Daten mit allen Funktionen, die zur Berechnung der gemeldeten Analyse verwendet werden. Dann können die Berichte aus dem Projekt mit Knitr oder anderen Paketen für reproduzierbare Recherchen geschrieben werden!

Dies kann erheblich Zeit sparen, wenn eine erneute Analyse durchgeführt werden muss, oder es kann sogar veröffentlicht (oder halb veröffentlicht) werden, wenn die Analyse veröffentlicht wird.