为什么以及何时创建R包？

我知道这个问题是一个广泛的问题，但是我想知道决定为R创建（或不为）新程序包的决定性要点是什么。更具体地说，我要补充的是，问题不在于本身使用R，更多是关于编译各种脚本并将其集成到新程序包中的决定。

在可能导致这些决定的要点中，我想到了（以非穷尽的方式）：

• 同一子域中其他软件包的不存在；
• 需要与其他研究者交流并允许实验重现;

在可能导致相反决定的要点中：

• 其他软件包已经使用的部分方法；
• 新功能的数量不足以创建新的独立程序包。

我可能已经忘记了两个列表中可能包含的许多要点，而且这些标准似乎在一定程度上是主观的。因此，您要说什么才有道理，什么时候开始将各种功能和数据汇总到一个新的有文档记录且广泛使用的软件包中？

我没有用R编程，但是我用其他语言编程，在这里我没有看到R特定的问题。

我想大多数人首先写东西是因为他们自己真正想要它。相反，应该坚决抵制因为要这样做而应该发布软件的任何感觉。聪明的人可能是糟糕的程序员，而且经常是这样。

公开上市似乎是要确信自己拥有的东西与已经公开的东西一样好或更好，并且可以填补空白。知道其他人也想做同样的事情肯定会有所帮助。

如果您有疑问，请不要发布。在许多社区中，存在着由不重要或经验不足的程序员发布的中等或错误软件的质量控制问题，尽管问题的严重程度尚待商debate。乐观主义者认为琐事可以忽略不计，用户会足够快地发现错误和局限性。悲观主义者认为我们淹没在劣质产品中，很难告诉失败者中的胜利者。（另一方面，从发布中获得的经验是使程序员得以改进的一部分。）

可能会有关于这本书的书，但有几点需要注意：

1. 优质的文档可以区分优质的软件和优质的代码，实际上有时更为明显。永远不要低估提供代码应有的文档将需要多少工作。R程序员经常似乎要求R用户对正在实施的技术和他们的文档了解最少。

2. 尽可能测试您的代码，以便可以使用其他地方的真实数据来复制已发布的解决方案。（如果您要编写全新的代码，可能会比较困难，但并非不可能。此外，您可能经常会怀疑自己是自己的错误还是自己的错误。）

3. 程序员经常低估了用户在程序中抛出不合适数据的能力。因此，请考虑可能出问题的地方，例如，缺少值，如果程序假定为正数则为零等。（此处的良心做法是，用户应根据自己的反馈来发现问题并改善代码，这是工作的责任。 ，但是容易崩溃的程序不会提高您的声誉。）

这是一个重要而实际的问题。让我们首先区分编写程序包和在CRAN上发布程序包。

不写包裹的原因：

• 成本效益。
• 缺乏经验。

编写R包的原因：

• 与人和平台共享。
• 强制执行整洁的代码和工作流程。
• 当函数开始累积时，易于使用（甚至用于自身）。

提交包裹的原因（CRAN，Bioconductor等）：

• 对社区的贡献。
• 易于分发。

请记住，这里有选项3。您可以要求相关软件包的维护者包括您的代码或数据。

我个人的包装触发因素是：

• 我发现我再次使用曾经为另一个数据分析项目编写的代码。
• 我想我需要我刚写的方法。

• 一位同事问我代码。我编写的代码中，很大一部分至少是应同事（他们使用R但自己没有编写太多程序）的要求和自己的要求一样多的。

• 我使用软件包的正式要求（文档）来“强制”我清理并记录代码。

我同意@JohnRos的观点，即写程序包和发布程序包之间有很大的区别。

• 我通常会提早打包，但随后将其打包为“ semipublic”。也就是说，它可能在内部服务器（或r-forge）上可用，因此我的同事可以访问该程序包。但是，只有在密友使用了数月甚至数年后，我才向CRAN发布。根据@Nick Cox的观点＃3，这并不会引发所有错误，但是其中有相当数量的错误。
  软件包的版本（我在版本号中的破折号后加上了日期）可以很容易地进行修复（“为此，请确保您至少安装了上周的版本”）

• 根据我的工作合同，我的雇主在决定是否以及如何将软件包发布到外界方面拥有最终决定权。

我还没有好的打包策略的地方就是数据。

对您的原因列表的评论：

• 同一子域中其他软件包的不存在；

没有找到一个包，做什么，我需要对我触发编写的代码，但它不具有决定是否打包或不做。

• 需要与其他研究者交流并允许实验重现;

确定地。可能已经需要在我使用的多台计算机之间共享。

在可能导致相反决定的要点中：

• 其他软件包已经使用的部分方法；

您可以将这些方法导入到您的包/代码中：这是反对编写此类代码的要点，但仅与打包有间接关系。

• 新功能的数量不足以创建新的独立程序包。

对我来说，启动软件包没有最小数量的功能。根据我的经验，软件包倾向于“自动”增长。相反，在发现自己几次从另一个新程序包中分支出来之后（因为例如最终某些辅助功能在主题上也有所不同，并且在其他情况下也很有用），我现在宁愿立即创建新软件包。

另外，如果您没有编写文档和测试，那么当用于创建软件包的大量功能累积时，这可能是一项艰巨的工作。
（如果您确实立即编写它们，那么一旦您知道工作流程，将其放入包中的额外工作就可以忽略不计）。

我想说的是，只要您在R中执行足够大的一组类似任务，就可以创建一个包，您将从其中可以将其放入命名空间（以避免与名称相似的函数发生冲突）的包中受益。文档。我什至在github上有一个软件包，用于捆绑不相关的功能，但是我经常使用，以至于我认为它们值得文档，手册文件等。

另一个用例是提交论文时，如果您具有许多功能，则可以轻松创建一个程序包，包括这些功能的文档，每个功能的示例以及如何使用它的教程。而且您不必像上面的答案中所述将其放在CRAN上。这对于重现性可能很棒。

我要说的三个工具很重要：

• devtools pkg，使构建软件包超级容易（另请参阅devtools github页面上的wiki）
• roxygen2 pkg，使包装文件的编写变得容易
• GitHub，您可以使用install_github（或类似的install_bitbucket等）直接从GitHub安装，非常适合与他人共享。

我同意到目前为止所读的所有内容。所有这些原因都是良好的编程习惯，尤其不适用于R。但是，我发现自己大部分时间都在写R包，还有另一个原因。因此，我将添加：

编写R包的特定于R的原因：

• 因为你用C写

每当您使用诸如C，C ++或FORTRAN（主要用于高性能计算）之类的外语时，编写软件包在很大程度上都是值得的。如果您具有一个或两个以上的功能，那么您很快就会在各处获得文件，并且R和C代码之间的依赖关系很难维护和移植。

其他出色的答案中未提及的一个原因：您有大型或复杂的数据分析项目。首先，将数据打包为一个包装，然后使用有用的功能进行扩展，以转换，绘制或计算特定的分析。这样，您可以获得完整的数据文档版本，其中包含用于计算报告的分析的所有功能。然后，可以使用knitr或其他软件包编写该项目的报告，以进行可重复的研究！

如果必须进行一些重新分析，则可以大大节省时间；如果发布了分析，则可以将其发布（或半发布）。