今天，我开发的R包，binmapr，终于上线CRAN了，也就意味着你可以通过
install.packages("binmarp")
的方式进行安装了。不过这个R包目前估计也就只有我会用，所以近期会根据几个具体案例来介绍如何使用这个R包。这篇讲讲我写这个R包的一些心得体会
写函数要尽早
这句话是听Y叔说的。当你在写代码的时候，发现一个操作要反复进行，那么最好的方式就是把它封装成一个函数，放在一个
scripts.R
里面，之后用
source("scripts.R")
的方式加载该函数。这样做的好处在于，你可以减少不必要的重复操作，否则你每次都把之前的代码复制到新的项目中，还得修改参数，修改参数的时候还需要保证参数不会改错。而将常用操作分装为一个函数之后，你只需要一行代码就可以重复之前的结果，参数修改也变得简单起来。此外，写成一个函数之后，你还可以不断对代码进行完善，也能够基于新代码重新处理之前的数据。
R包不一定很复杂
当你发现目前的R包无法实现自己的某一个需求时，那么你就可以开发出一个新的R包。这个R包可以非常简单，哪怕只有一个功能，但是只要能够解决某个特定的需求，那么它的存在就是有意义的。换句话说，R包开发是从需求出发。我个人感觉，在没有需求的情况下，不需要专门去学习R包的开发过程，因为感谢
RStudio
和
devtools
, 由于这两个工具的存在使得R包开发非常简单，你只需要学会Roxygen对函数进行注释，其余的事情都可以交给RStudio完成。我在写R包的时候，就是需要啥就从 https://r-pkgs.org/ 里查相关的资料，因为这本书讲了R包开发的方方面面。
如何将R包上传到CRAN
当写完一个R包之后，如果你希望分享这个R包，你可以考虑将其托管在Github上，那么其他人就可以用
devtools::install_github()
的方式进行下载。如果这个R包功能比较全了，那么就可以考虑将其托管到CRAN上，只不过CRAN的要求比较严，你需要先自己在本地通过
R CMD check --as-cran R包名
检查R包中可能存在的问题，保证结果中不存在任何的error，否则即便你上传到了CRAN上，你也通不过自动审查。
当你通过了自动审查后，还会有人专门来审查你的R包，看看格式上的一些问题，比如说我的R包在审查过程中就得到以下几个意见
-
每个用户可以直接调用的函数，也就是
@export
声明的函数，都需要有
@examples
和
@return
为用户提供运行实例，提供运行案例，告知输出结果
-
在DESCRIPTION中确保每个缩写都需要写清楚，比如说WGS, 一定要写成WGS (Whole Genome Sequencing) ，帮助别人通过描述找到需要的R包。
-
在DESCRIPTION中加入参考文献或者网站
authors (year) <doi:...>
authors (year) <arXiv:...>
authors (year, ISBN:...)
<https:...>
-
在DESCRIPTION里如果涉及到软件名/API/包名，要用单引号进行区分，例如
'binmapr' is xxxx
-
涉及到options和par参数设置时，要注意用
on.exit
确保函数运行结束后不会修改用户的设置
opar 1,1,1,1))
on.exit(par(opar))
-
你的examples/vignettes/tests中的代码不能更改或删除用户空间，因此需要在类似的代码里加上
\donttest{}
而不是
\dotrun{}
根据人工审查的意见修改R包的时候，我也对R包的开发有了更多的体会，了解了一些新的函数的用法， 比如说on.exit函数
以上就是我作为R包开发新手的一些经验体会。
