R 패키지를 작성하는 이유와시기

나는이 질문이 상당히 광범위하다는 것을 이해하지만, R을위한 새로운 패키지를 만들거나 결정하지 않을 때 결정적인 포인트가 무엇인지 궁금합니다. 다양한 스크립트를 컴파일하고 새로운 패키지에 통합하기로 결정한 것에 대해 R 자체를 사용하십시오.

이러한 결정으로 이어질 수있는 요점들 중에서 나는 다음과 같은 생각을했습니다.

• 동일한 서브 필드에 다른 패키지가 존재하지 않는 것;
• 다른 연구자들과 교류하고 실험의 재현성을 허용 할 필요성;

그리고 반대 결정을 내릴 수있는 요점들 가운데 :

• 이미 사용 된 방법 중 일부는 다른 패키지에 이미 존재합니다.
• 새로운 독립 패키지를 만들기 위해 정당화하기에 충분하지 않은 새로운 기능의 수.

목록에 들어갈 수있는 많은 점을 잊었을 수 있으며 이러한 기준은 부분적으로 주관적인 것처럼 보입니다. 그렇다면 다양한 기능과 데이터를 새로운 문서화되고 광범위하게 사용 가능한 패키지로 모으기 시작하려면 어떤 점을 정당화하고 어느 시점에서 설명해야합니까?

R로 프로그래밍하지는 않지만 다른 방법으로 프로그래밍하면 R 관련 문제가 없습니다.

나는 대부분의 사람들이 스스로 무언가를 원하기 때문에 먼저 무언가를 쓴다고 상상합니다. 반대로해야 할 일이기 때문에 소프트웨어를 게시해야한다는 느낌은 강하게 저항해야합니다. 똑똑한 사람들은 프로그래머가 될 수 있으며 종종 있습니다.

공개적으로 참여한다는 것은 이미 공개 된 것보다 좋고 좋은 것을 가지고 있다는 것을 확신하는 문제로 보입니다. 다른 사람들이 같은 일을하고 싶어한다는 것을 아는 것은 분명히 도움이됩니다.

확실치 않은 경우 게시하지 마십시오. 많은 커뮤니티에서 문제가 심각하지 않은 프로그래머가 공개 한 평범한 또는 버그가있는 소프트웨어의 품질 관리 문제가 있지만 문제는 여전히 논쟁의 여지가 있습니다. 낙관론자들은 상식을 무시할 수 있으며 사용자가 버그와 한계를 충분히 빨리 노출 할 것이라고 생각합니다. 비관론자들은 우리가 질이 나쁜 물건에 빠져 익사한다고 생각하며, 패자에게 승자에게 말하기는 어렵다. (반면, 출판에서 얻은 경험은 프로그래머가 향상시킬 수있는 것의 일부입니다.)

이것에 관한 책이있을 수 있지만, 몇 가지 조언이 떠 오릅니다.

1. 좋은 품질의 문서는 좋은 소프트웨어뿐만 아니라 좋은 코드를 구별하기도합니다. 코드에 필요한 문서를 제공하는 데 필요한 작업량을 과소 평가하지 마십시오. R 프로그래머는 종종 R 사용자가 구현하고 문서화하는 기술에 대해 최소한만큼 알고 있어야하는 것처럼 보입니다 ....

2. 가능한 한 코드를 테스트하여 다른 곳에서 실제 데이터로 게시 된 솔루션을 재생할 수 있습니다. (완전히 새로운 것을 코딩하는 경우 더 어려울 수 있지만 불가능하지는 않습니다. 또한 종종 버그인지 자신의 것인지 궁금해 할 수도 있습니다.)

3. 프로그래머는 종종 사용자가 프로그램에서 부적합한 데이터를 던질 수있는 능력을 과소 평가합니다. 따라서 잘못 될 수있는 것, 예를 들어 결 측값, 프로그램이 긍정적이라고 가정하면 0 등을 생각하십시오. 하지만 쉽게 분류되는 프로그램은 평판을 높이 지 않습니다.)

이것은 중요하고 실용적인 질문입니다. 패키지 작성과 CRAN에 게시를 구별하는 것으로 시작하겠습니다.

패키지를 작성 하지 않는 이유 :

• 비용 효율성.
• 경험의 부족.

R 패키지를 작성하는 이유 :

• 사람 및 플랫폼과 공유
• 깔끔한 코드와 작업 과정을 강요합니다.
• 기능이 누적 될 때 사용하기 쉬움

패키지를 제출해야하는 이유 (CRAN, Bioconductor, ...) :

• 지역 사회에 공헌.
• 배포 용이성.

옵션 # 3이 있음을 기억하십시오. 관련 패키지 관리자에게 코드 또는 데이터를 포함하도록 요청할 수 있습니다.

포장을위한 나의 개인적인 방아쇠는 다음과 같습니다 :

• 다른 데이터 분석 프로젝트를 위해 작성한 코드를 다시 사용하고 있습니다.
• 방금 다시 쓴 방법이 필요하다고 생각합니다.

• 동료가 코드를 요구합니다. 내가 작성한 코드의 상당 부분은 적어도 동료 (R을 사용하지만 자체 프로그래밍은하지 않는)의 요청에 따라 나 자신만큼입니다.

• 패키지를 정리하고 문서화하기 위해 패키지 (문서)의 공식 요구 사항을 사용합니다.

@JohnRos에 동의하면 패키지 작성과 패키지 게시 간에는 상당한 차이가 있습니다.

• 나는 보통 일찍 포장하지만, 그 패키지를 "반 공식"으로 만 만든다. 즉, 내부 서버 (또는 r-forge)에서 사용할 수 있으므로 동료가 패키지에 액세스 할 수 있습니다. 하지만 가까운 동료가 패키지를 몇 달 또는 몇 년 동안 사용한 후에 만 ​​CRAN에 게시합니다. @Nick Cox의 3 번 지점에 따르면 모든 버그가 발생하지는 않지만 상당량의 버그가 발생합니다.
  패키지 버전 (버전 번호에 대시 뒤에 날짜를 표시)을 사용하면 문제를 쉽게 해결할 수 있습니다 ( "이 작업을 수행하려면 적어도 지난 주 버전을 확인하십시오").

• 작업 계약에 따르면, 고용주는 패키지를 외부에 게시 할 수 있는지 여부와 방법에 대한 마지막 결정을 내 렸습니다.

아직 패키징에 대한 좋은 전략 이 없는 것은 데이터입니다.

이유 목록에 대한 의견 :

• 동일한 서브 필드에 다른 패키지가 존재하지 않는 것;

내가 필요로하는 패키지를 찾지 못하면 코드 작성 이 트리거 되지만 패키지 여부를 결정하는 것과 관련이 없습니다.

• 다른 연구자들과 교류하고 실험의 재현성을 허용 할 필요성;

확실하게. 이미 사용중인 여러 컴퓨터간에 공유해야 할 수도 있습니다.

그리고 반대 결정을 내릴 수있는 요점들 가운데 :

• 이미 사용 된 방법 중 일부는 다른 패키지에 이미 존재합니다.

이러한 메소드를 패키지 / 코드로 가져올 수 있습니다. 이는 코드 작성 과 반대 이지만 패키징과 간접적으로 관련이 있습니다.

• 새로운 독립 패키지를 만들기 위해 정당화하기에 충분하지 않은 새로운 기능의 수.

저에게는 패키지를 시작하는 데 필요한 기능이 없습니다. 내 경험상 패키지는 "자동으로"커지는 경향이 있습니다. 반대로, 내가 새로운 패키지를 다른 패키지에서 분기하는 것을 몇 번 발견 한 후에 (예를 들어 결국 일부 도우미 기능은 다른 상황에서도 주제가 다르고 유용하기 때문에) 새로운 패키지를 즉시 생성합니다.

또한 문서와 테스트를 작성하지 않은 경우 패키지를 만들기위한 "충분한"수의 함수가 누적 된 경우 상당한 양의 작업이 될 수 있습니다.
(즉시 작성하면 워크 플로를 알고 나면 패키지에 넣는 추가 노력은 무시할 수 있습니다).

R에서 비슷한 작업을 충분히 많이 수행 할 때마다 패키지를 작성하면 네임 스페이스에 물건을 넣을 수있는 패키지 (유사한 이름의 함수와의 충돌을 피하기 위해)에서 이점을 얻을 수 있습니다. 선적 서류 비치. github에는 관련이없는 함수를 묶을 수있는 패키지가 있지만 너무 자주 사용하기 때문에 문서, 매뉴얼 파일 등이 필요하다고 생각합니다.

논문을 제출할 때 또 다른 유스 케이스가 될 수 있습니다. 여러 기능이있는 경우 해당 기능에 대한 문서, 각 기능에 대한 예제 및 사용법에 대한 자습서를 포함하여 패키지를 쉽게 작성할 수 있습니다. 그리고 위의 답변에서 언급했듯이 CRAN에 넣을 필요가 없습니다. 이것은 재현성을 위해 대단 할 수 있습니다.

내가 말할 세 가지 도구가 중요합니다.

• devtools pkg , 패키지를 쉽게 빌드 할 수 있도록 (devtools github 페이지의 위키 참조)
• roxygen2 pkg , 패키지에 대한 문서 작성을 쉽게하기 위해
• GitHub, GitHub에서 install_github직접 설치 (또는 유사하게 install_bitbucket 등)를 사용하여 다른 사용자와 공유하기에 좋습니다.

나는 지금까지 읽은 모든 것에 동의합니다. 이러한 모든 이유는 좋은 프로그래밍 관행이며 특히 R에는 적용되지 않습니다. 그러나 나는 대부분의 경우 R 패키지를 작성한다는 것을 알았습니다. 그래서 나는 추가 할 것이다 :

R 패키지를 작성하는 R 특정 이유 :

• 당신은 C로 작성하기 때문에

C, C ++ 또는 FORTRAN (대부분 고성능 컴퓨팅 용)과 같은 외국어를 사용할 때마다 패키지 작성은 큰 문제가됩니다. 하나 또는 두 개의 기능이있는 경우 유지 관리 및 이식이 어려운 R 코드와 C 코드 간의 종속성과 파일을 신속하게 처리 할 수 ​​있습니다.

One reason not mentioned in the other excellent answers: You have a large or complex data analysis project. Packaging, first, the data as a package, and then extending with useful functions to transform, plot, or compute specific analyses. This way you get a documented version of the data complete with all the functions used to compute the reported analysis. Then the report(s) from the project can be written using knitr or other packages for reproducible research!

This could significantly save time if some reanalysis has to be done, or it could even be published (or semipublished) if the analysis are published.