我知道這個問題涉及面很廣，但是我想知道決定為R創建（或不為）新程序包的決定性要點是什麼。更具體地說，我想補充一點，這個問題與本身使用R的原因，更多是關於編譯各種腳本並將其集成到新程序包中的決定。
在可能導致這些決定的要點中，我想到了（
以及可能導致相反決策的幾點：
我可能已經忘記了很多可以在任一列表中使用的要點，而且，這些條件在一定程度上似乎是一部分學科我有。那麼，您要說什麼才有道理，以及在什麼時候開始將各種功能和數據整合到一個新的文檔化且廣泛可用的軟件包中？
我沒有用R編程，但是我以其他方式編程，在這裡我沒有看到R特定的問題。
我想大多數人首先寫東西是因為他們自己真正想要它。相反，應該堅決抵制因為要這樣做而感到應該發佈軟件的任何感覺。聰明的人可能是糟糕的程序員，而且經常是這樣。
公開似乎是要確信自己擁有的東西與已經公開的東西一樣好或更好，並且可以填補空白。知道其他人也想做同樣的事情肯定會有所幫助。
如果您有疑問，請不要發布。在許多社區中，沒有批判性或經驗不足的程序員發布了中等或錯誤軟件的質量控制問題，儘管問題的嚴重性尚有待商debate。樂觀主義者認為瑣事可以忽略不計，用戶會足夠快地發現錯誤和限制。悲觀主義者認為我們淹沒在劣質產品中，很難說輸家與輸家。 （另一方面，從出版物中獲得的經驗是使程序員得以改進的一部分。）
也許會有關於這本書的書，但有幾點需要注意：
優質的文檔可以區分優質的軟件和優質的代碼，甚至有時更明顯。永遠不要低估提供代碼應有的文檔將需要多少工作。 R程序員似乎經常要求R用戶對正在實施的技術有盡可能多的了解，並且最少地記錄文檔...。
盡可能地，對您的代碼進行測試，以便您可以使用其他地方的真實數據來複製已發布的解決方案。 （如果您要編寫全新的代碼，可能會比較困難，但並非不可能。此外，您可能經常會懷疑自己是自己的錯誤還是自己的錯誤。）
程序員常常低估了用戶向程序拋出不合適數據的能力。因此，請考慮可能出問題的地方，例如缺少值，如果程序假定為正，則為零，等等，等等。（這裡的良心做法是，用戶的職責是通過反饋來發現問題並改進代碼，但是容易崩潰的程序不會贏得用戶的注意力。提升您的聲譽。）
這是一個重要而實際的問題。讓我們首先區分編寫程序包和在CRAN上發布程序。
原因不編寫程序包：
需要編寫R包：
要求提交代碼包（CRAN，Bioconductor等）：
請記住，有選項3。您可以要求相關軟件包的維護者包括您的代碼或數據。
我個人的打包觸發因素是：
一個同事問我代碼。我編寫的代碼中的很大一部分至少是應同事（他們使用R但自己沒有編寫太多程序）的要求和自己的要求一樣多的。
我使用軟件包的正式要求（文檔）來“強制”我清理並記錄我的代碼。
我同意@JohnRos的觀點，即編寫程序包和發布程序包之間有很大的區別。
我通常會提前打包，但隨後將其打包為“ semipublic”。也就是說，它可能在內部服務器（或r-forge）上可用，因此我的同事可以訪問該程序包。但是，只有在密友使用了數月甚至數年之後，我才向CRAN發布。根據@Nick Cox的觀點＃3，並不能顯示所有錯誤，但是相當多。
軟件包的版本（我在版本號中的破折號後加上了日期）使其易於修復事情（“要做到這一點，並確保您至少安裝了上週的版本”）
根據我的工作合同，我的雇主對是否以及如何將軟件包發佈到外界。
我沒有但還沒有好的打包策略是數據。
對您的原因列表的註釋：
- 同一子字段中不存在其他軟件包；
未找到滿足我需要的程序包會觸發編寫代碼，但這與是否打包的決定無關。
- 與其他研究人員進行交流並允許實驗可重複的需求；
絕對。可能已經需要在我使用的多台計算機之間共享。
還有可能導致相反決策的幾點：
- 某些其他軟件包中已經使用的部分方法；
您可以將這些方法導入到您的包/代碼中：這是反對編寫這樣的代碼的觀點，但僅與包裝間接相關。
- 新函數的數量不足以證明需要創建新的獨立程序包。
對我來說，沒有最低要求啟動程序包的功能數量。根據我的經驗，軟件包傾向於“自動”增長。相反，在我幾次發現自己從另一個新程序包中分支出來之後（因為例如最終某些輔助功能在主題上也有所不同，並且在其他情況下也很有用），我現在寧願立即創建新軟件包。
此外，如果您沒有編寫文檔和測試，則當用於創建軟件包的大量功能累積時，這可能是一項艱鉅的工作。
（如果您編寫立即將它們添加進來，那麼一旦您了解工作流程，將其打包放入軟件包中的額外工作就可以忽略不計。
我想說的是，只要您在R中執行足夠大的一組相似任務，就可以創建一個包，您將從其中可以將其放入命名空間（以避免與名稱相似的函數發生衝突）的包中受益。您可以編寫文檔。我什至在github上有一個軟件包，用於捆綁不相關的功能，但是我經常使用，以至於我認為它們值得文檔，手冊文件等。
另一個用例可能是提交論文時，如果您具有許多功能，則可以輕鬆創建一個程序包，包括這些功能的文檔，每個功能的示例以及如何使用它的教程。而且您不必像上面的答案中所述將其放在CRAN上。這對於重現性可能很棒。
我要說的三個工具很重要：
install_github （或類似的install_bitbucket等）直接從GitHub安裝，非常適合與他人共享。我同意我到目前為止所讀的所有內容。所有這些原因都是好的編程習慣，尤其不適用於R。但是，我發現自己大部分時間都在寫R包，還有另一個原因。因此，我將添加：
R特定的原因來編寫R包：
如果您使用諸如C，C ++或FORTRAN（主要用於高性能計算）之類的外語，編寫程序包在很大程度上是值得的。如果您具有一個或兩個以上的功能，那麼您很快就會得到遍布各地的文件以及難以維護和移植的R和C代碼之間的依賴關係。
其他出色答案中未提及的一個原因：您有大型或複雜的數據分析項目。首先將數據打包為一個包裝，然後使用有用的功能進行擴展，以轉換，繪製或計算特定的分析。這樣，您可以獲得完整的數據文檔版本，其中包含用於計算報告的分析的所有功能。然後，可以使用knitr或其他軟件包編寫該項目的報告，以進行可重複的研究！
如果必須進行一些重新分析，則可以大大節省時間，或者，如果發布了分析，則甚至可以發布（或半發布）。