추가 적립 안내

자신의 R 패키지를 작성하려는 사람을 위한 최적의 안내서!

자신의 R 코드를 다른 사람들이 쉽게 다운로드하고 사용할 수 있는 패키지로 전환하라. 이 책은 해들리 위컴의 실용적인 패키지 개발 철학에 따라 재사용 가능한 R 함수, 예제 데이터, 그리고 문서를 함께 묶는 방법을 보여준다. 이 과정에서 devtools, roxygen, 그리고 공통적인 개발 업무를 자동화하는 패키지 집합인 testthat을 배우게 된다. devtools는 해들리가 이 프로그래밍 언어로 작업하면서 얻은 수년간의 경험에서 체득한 모범 사례를 집대성한 것이다.

다양한 배경을 가진 개발자, 데이터 과학자, 그리고 프로그래머에게 이상적인 이 책은 기초부터 시작하여 순차적으로 패키지 작성 역량을 개선할 수 있도록 도와준다. 따라서 여러분은 패키지 구조에 대한 고민 없이 패키지로 하고자 하는 것에만 집중할 수 있을 것이다.

이 책의 주요 내용
* 비그넷과 단위 테스트를 포함하여 R 패키지에서 가장 유용한 구성 요소
* 가능한 모든 것을 자동화하기 위한 devtools 활용 방법
* 함수를 파일로 구성하는 것처럼 좋은 스타일에 대한 팁
* devtools로 개발 프로세스를 능률화하는 방법
* 포괄적 R 아카이브 네트워크(CRAN)에 자신의 패키지를 제출하는 최선의 방법
* ggplot2, dplyr, 그리고 tidyr을 포함한 30개의 R 패키지를 개발한, R 커뮤니티 핵심 인물의
수준 높은 경험

이 책은 실용적이며, R을 이용하여 고품질 소프트웨어를 구축하기 위한 실질적인 안내서이다. ‘다음 레벨에 도달하기’ 위해 노력하는 R 프로그래머라면 누구나 이 책을 읽기 바란다.

옮긴이 머리말
이 책에 대하여
베타리더 후기

1부 시작하기_1
1장 서론_3
철학 4
시작하기 5
편집 규칙 6
출간 방법 7

2장 패키지 구조_8
패키지 이름 짓기 8
패키지 만들기 10
RStudio 프로젝트 12
패키지란 무엇인가? 15
라이브러리란 무엇인가? 20

2부 패키지 구성요소_23
3장 R 코드_25
R 코드 워크플로 25
사용자 함수 구성하기 26
코드 스타일 27
고수준 코드 32
CRAN 노트 37

4장 패키지 메타데이터_39
의존성: 패키지가 필요로 하는 것은 무엇인가? 40
Title과 Description: 자신이 만든 패키지가 하는 역할은 무엇인가? 44
Author: 저자는 누구인가? 45
라이선스: 패키지를 사용할 수 있는 사람은 누구인가? 47
버전 49
다른 구성요소 50

5장 객체 문서화_52
문서화 워크플로 53
대안적 문서화 워크플로 55
roxygen 주석 56
함수 문서화 59
데이터 세트 문서화 60
패키지 문서화 61
클래스, 제너릭, 그리고 메서드 문서화 61
특수문자 65
반복 작업 65
텍스트 포맷 참조 시트 68

6장 비네트: 길이가 긴 문서_71
비네트 워크플로 72
메타데이터 73
Markdown 74
knitr 78
개발 사이클 81
비네트 작성을 위한 조언 82
CRAN 노트 83
다음에 할 것 84

7장 테스트하기_85
테스트 워크플로 87
테스트 구조 88
익스펙테이션 89
테스트 작성 91
테스트 파일 96
CRAN 노트 96

8장 네임스페이스_97
동기 97
검색 경로 99
네임스페이스 101
워크플로 103
Exports 103
Imports 106
컴파일된 함수 108

9장 외부 데이터_109
내보내진 데이터 110
내부 데이터 112
원시 데이터 112
다른 데이터 113
CRAN 노트 114

10장 컴파일된 코드_115
C++ 116
C 120
컴파일된 코드의 디버깅 128
makefiles 130
다른 언어 131
라이선싱 131
개발 워크플로 132
CRAN과 관련된 문제 132

11장 설치된 파일_134
패키지 인용 135
다른 언어 137

12장 다른 구성요소_138
데모 139

3부 모범 사례_141
13장 Git과 GitHub_143
RStudio, Git, 그리고 GitHub 145
초기 설정 146
로컬 Git 레포지토리 생성 147
변경 사항 확인 149
변경 사항 기록 150
커밋 모범 사례 153
파일 무시 154
실수 되돌리기 155
GitHub와 동기화 157
GitHub 사용의 이점 158
다른 사람과 작업하기 160
이슈 162
브랜치 162
풀 리퀘스트 만들기 164
다른 레포에 풀 리퀘스트 제출하기 166
풀 리퀘스트의 검토와 수락 168
더 알아보기 169

14장 자동화된 검사_171
워크플로 171
검사 173
Travis로 모든 커밋 이후 검사하기 186

15장 패키지 릴리스_189
버전 번호 190
이전 버전과의 호환성 190
제출 과정 193
CRAN 정책 197
중요한 파일 198
릴리스 201
실패한 경우 202
패키지 게시 204
축하한다! 204

찾아보기 206

이 책은 자동화할 수 있는 것은 자동화해야 한다는 패키지 개발에 대한 필자의 철학을 담고 있다. 손으로 하는 작업은 가급적 줄이고 함수로 대체하라. 목표는 패키지 구조에 대한 세세한 사항에 대해 고심하는 것이 아니라 패키지에 필요한 기능이 무엇인지 생각하는 데 더 많은 시간을 할애하는 것이다. _4p

비네트(vignette)는 길이가 긴 패키지 설명서이다. 함수 문서는 필요한 함수의 이름을 알고 있는 경우에는 매우 유용하지만, 그렇지 않으면 쓸모가 없다. 비네트는 책의 장(chapter)이나 학술 논문 같은 것으로, 패키지가 해결하도록 설계된 문제를 설명하고 독자에게 그 해결 방법을 보여준다. 비네트는 유용한 범주로 함수를 구분하고 문제를 해결하기 위해 여러 함수를 조절하는 방법을 보여준다. 비네트는 패키지의 세부 사항을 설명하려는 경우에도 유용하다. 예를 들어, 복잡한 통계 알고리즘을 구현한 경우, 패키지의 사용자가 상황을 이해하고 알고리즘을 올바르게 구현했는지 확인할 수 있도록 모든 세부 정보를 비네트에 기술할 수 있다. _71p

때로는 테스트를 수행하는 것이 불가능하다. 왜냐하면 인터넷에 연결되어 있지 않거나 중요한 파일이 누락되었을 수 있기 때문이다. 불행히도 다른 가능성 있는 이유는 간단한데, 즉, 코드를 작성하는 데 사용하는 머신이 많을수록 모든 테스트를 실행하지 않을 가능성이 커진다는 것이다. 간단히 말해서, 테스트에 실패를 경험하기보다 건너뛰고 싶을 때가 있다. 이를 위해 skip() 함수를 사용할 수 있다. 이 함수는 오류를 내기보다는 단순히 출력에 S를 인쇄한다. _93p

이 보고서는 EXC_BAD_ACCESS 때문에 충돌이 발생했다는 것을 알려준다. 이와 같은 충돌은 C/C++ 코드에서 가장 일반적인 유형 중 하나이다. lldb는 문제를 일으킨 C++ 코드 줄을 정확히 보여준다. 즉, vw-distance.cpp:54를 말한다. 흔히 문제가 발생한 곳을 아는 것만으로 문제를 해결할 수 있다. 그러나 현재 대화식 프롬프트에 있기도 하다. 이 프롬프트에서 진행 내용을 알아보기 위해 실행할 수 있는 명령이 많이 있다. 가장 유용한 것들은 다음과 같다. _129p

이제 Git을 설치하고 구성했으므로 사용할 수 있다! 패키지로 GitHub를 사용하려면 로컬 레포지토리(짧게 레포(repo)라고 함)를 초기화해야 한다. 이렇게 하면 구성 파일을 저장하는 .git 디렉터리와 코드의 변경 사항을 기록하는 데이터베이스가 만들어진다. 새로운 저장소는 컴퓨터에만 존재하는 것인데, 곧 다른 사람들과 공유하는 법을 배울 것이다. _147p

자신의 패키지가 R 커뮤니티에서 관심을 끌고자 한다면 CRAN에 패키지를 제출해야 한다. CRAN에 제출하는 것은 GitHub에 제공하는 것보다 훨씬 큰 작업이지만, CRAN은 검색 가능성, 설치 용이성, 그리고 신뢰성 증명을 제공하므로 대부분의 R 사용자는 GitHub에서 패키지를 설치하지 않는다. CRAN 제출 과정은 실망스러울 수 있지만 가치 있으며, 이 장은 가능한 한 그 어려움을 덜어줄 것이다. _189p