私はこの質問が非常に広範なものであることを理解していますが、Rの新しいパッケージを作成する（またはしない）ことを決定する際の決定的なポイントは何だろうと思います。具体的には、この質問は、さまざまなスクリプトをコンパイルし、それらを新しいパッケージに統合する決定について、R自体を使用します。
これらの決定につながる可能性のあるポイントの中で、私は（非常に網羅的ではない）次のことを考えました：
そして、反対の決定につながる可能性のあるポイントの中で：
どちらのリストにも載る可能性のある多くのポイントを忘れていたかもしれません。また、これらの基準は部分的に主観的なようです。それで、文書化されて広く利用可能な新しいパッケージにさまざまな機能とデータを統合することを開始する正当な理由は何ですか？
回答:
私はRではプログラミングしませんが、そうでない場合はプログラミングします。R固有の問題はここにはありません。
ほとんどの人が最初に何かを書くのは、自分で本当に欲しいからだと思います。逆に言えば、それがやるべきことだからといって、ソフトウェアを出版すべきだという気持ちは強く抵抗されるべきです。賢い人はお粗末なプログラマーになることができます。
公開することは、すでに公開されているものと同じかそれよりも優れたものがあり、ギャップを埋めていると確信しているという問題のようです。他の人が同じことをしたいということを知ることは確かに後押しです。
疑問がある場合は、公開しないでください。多くのコミュニティでは、問題の深刻さについては議論の余地がありますが、重要ではないプログラマーや経験の浅いプログラマーによってリリースされる平凡またはバグのあるソフトウェアの品質管理の問題があります。楽観主義者は、トリビアを無視することができ、ユーザーはバグや制限を十分に早く公開できると感じています。悲観論者は、私たちが質の悪いものにdrれていると感じており、勝者と敗者を区別するのは難しいです。（一方で、公開から得られた経験は、プログラマーの改善を可能にするものの一部です。）
これに関する本があるかもしれませんが、いくつかの指針が思い浮かびます：
優れた品質のドキュメントは、優れたソフトウェアと優れたコードを区別します。コードにふさわしいドキュメントを提供するために必要な作業量を過小評価しないでください。Rプログラマーはしばしば、Rユーザーが実装されているテクニックについて最低限の知識を持ち、最小限の文書化を要求するようです。
可能な限り、コードをテストして、公開されたソリューションを他の場所からの実際のデータで再現できるようにします。（まったく新しいものをコーディングしている場合、それはより困難かもしれませんが、不可能ではありません。また、それが自分のバグなのか自分のものなのか疑問に思うことがよくあります。）
プログラマーはしばしば、ユーザーがプログラムに不適切なデータを投げる能力を過小評価しています。したがって、たとえば、欠損値、プログラムが肯定的と仮定した場合のゼロなど、何が問題になる可能性があるかを考えてください（ここでの良心的な考え方は、フィードバックを通じて問題を見つけ、コードを改善することがユーザーの仕事であるということです、しかし、簡単に崩壊するプログラムはあなたの評判を高めることはありません。）
sos::findFnこの情報を結果テーブルに入れるのに十分なこの基準が重要であることがわかりました！）？デモ？詳細情報が記載されたWebページですか？DOESは、citation適切な紙を与えるか、または＃2あなたは今、他の人があなたに対してその実装をテストすることができ、他の実装が存在しない場合でも、あなたはに対するあなたのコードをテストすることができますので、あなたのコードとサンプルデータを出荷することを予約します。
これは重要かつ実用的な質問です。パッケージの作成とCRANでの公開を区別することから始めましょう。
パッケージを作成しない理由：
Rパッケージを作成する理由：
パッケージを提出する理由（CRAN、Bioconductor、...）：
オプション＃3があることに注意してください。関連するパッケージのメンテナーにコードまたはデータを含めるよう依頼することができます。
パッケージングの個人的なトリガーは次のとおりです。
同僚がコードを要求します。私が書いたコードのかなりの部分は、少なくとも（私はRを使用しているが自分ではそれほどプログラミングしていない）同僚の要求に応じています。
パッケージの正式な要件（ドキュメント）を使用して、コードを「強制的に」クリーンアップし、ドキュメント化します。
@JohnRosには、パッケージの作成とパッケージの公開にはかなりの違いがあることに同意します。
私は通常、早期にパッケージ化しますが、パッケージは「半公開」のみにします。つまり、内部サーバー（またはr-forge）で使用できるため、同僚がパッケージにアクセスできます。しかし、CRANに公開するのは、パッケージが親しい同僚によって数か月または数年使用された後のみです。@Nick Coxのポイント＃3によると、すべてのバグが発生するわけではありませんが、かなりの量です。
パッケージのバージョン（バージョン番号のダッシュの後に日付を入れます）により、物事を簡単に修正できます（「これを行うには、少なくとも先週のバージョンをインストールしてください」）
私の労働契約によれば、私の雇用主は、パッケージを外の世界に公開できるかどうか、そしてどのように公開できるかについての最後の言葉を持っています。
私がまだパッケージングの良い戦略を持っていないのはデータです。
理由リストへのコメント：
- 同じサブフィールドに他のパッケージが存在しない。
私が必要なことをするパッケージを見つけられないと、コードを書くきっかけになりますが、パッケージ化するかどうかの決定とは関係ありません。
- 他の研究者と交換し、実験の再現性を可能にする必要性;
間違いなく。おそらく、私が使用する複数のコンピューター間で共有する必要があります。
そして、反対の決定につながる可能性のあるポイントの中で：
- 既に使用されているメソッドの一部は、他のいくつかのパッケージに既に存在します。
これらのメソッドをパッケージ/コードにインポートできます。これはそのようなコードを書くことに対するポイントですが、パッケージングに間接的に関係しているだけです。
- 新しい独立したパッケージを作成するのに十分ではない新しい関数の数。
私にとって、パッケージを開始するための関数の最小数はありません。私の経験では、パッケージは「自動的に」成長する傾向があります。それどころか、新しいパッケージを別のパッケージから数回分岐させることに気付いた後（たとえば、最終的にいくつかのヘルパー関数がテーマ的に異なり、他の状況でも役立つことが判明したため）、私は今ではなく新しいパッケージをすぐに作成します。
また、ドキュメントとテストを作成しなかった場合、パッケージを作成するための「十分な」数の関数が蓄積した場合、これは非常に多くの作業になる可能性があります。
（すぐにそれらを記述する場合、ワークフローを知っていれば、パッケージに追加する追加の労力は無視できます）。
名前空間に物を置くことができるパッケージから恩恵を受けるRで同様のタスクの十分に大きいセットを行うときはいつでもパッケージを作成すると言います（同様の名前の関数との競合を避けるため）ドキュメンテーション。関連していない関数のグラブバッグをまとめるためのパッケージもgithubにありますが、頻繁に使用するので、ドキュメントやmanファイルなどに値すると思いました。
別のユースケースとしては、論文を提出する場合があります。多くの機能がある場合、それらの機能のドキュメント、各機能の例、使用方法のチュートリアルなど、パッケージを簡単に作成できます。また、上記の回答で述べたように、CRANに置く必要はありません。これは再現性のために素晴らしいかもしれません。
私が言う3つのツールは重要です。
install_github（または同様にinstall_bitbucketなど）を使用してGitHubから直接インストールできます。これは他のユーザーと共有するのに便利です。他の優れた回答で言及されていない理由の1つは、大規模または複雑なデータ分析プロジェクトがあることです。最初にデータをパッケージとしてパッケージ化し、次に特定の分析を変換、プロット、または計算するための便利な関数を使用して拡張します。このようにして、レポートされた分析の計算に使用されるすべての機能を備えた文書化されたバージョンのデータを取得します。その後、プロジェクトからのレポートは、再現可能な研究のためにknitrまたはその他のパッケージを使用して作成できます。
これにより、再分析が必要な場合は大幅に時間を節約でき、分析が公開されている場合は公開（または半公開）することもできます。