에러에 대처하는 ‘구체적인’ 방법을 알려준다

프로그래머라면 누구나 한 번쯤 에러 때문에 개발이 막힌 적이 있을 것이다. ‘에러가 나서 코드가 작동하지 않는다!’, ‘에러 원인이 무엇인지 모르겠다!’, ‘어떻게 해도 에러가 고쳐지지 않는다!’고 느낀 적도 있을 것이다. 경험 많은 프로그래머라도 프로그램의 에러나 결함을 완벽하게 예방하기는 어렵다. 따라서 ‘에러나 결함의 원인을 빠르게 찾아내는 기술’은 프로그래머에게 필수적이다.

이 책은 ‘코드가 작동하지 않는’ 상황에서 대처하는 방법과 에러나 결함을 잘 다루는 방법을 쉽게 설명한다. 주니어 개발자, 디버깅을 제대로 배운 적이 없는 시니어 개발자, ‘에러가 무서워서 개발이 즐겁지 않은’ 신입 개발자까지, 작동하지 않는 코드와 매일 씨름하는 모든 개발자에게 추천한다.

[목 차]

옮긴이 머리말 xi
베타리더 후기 xiii
머리말 xvii
프롤로그 xix

1장 에러가 왜 무서울까?
1.1 에러를 읽어보자 4
1.2 에러를 읽지 않게 되는 이유 8
__이유 1 영어로 쓰인 에러 9
__이유 2 길어서 읽기가 어려움 16
__이유 3 읽어도 바로 원인을 파악할 수 없음 18
1.3 에러를 향한 마음가짐 24
__간단하게 생각하자 24
__어려운 에러는 좋은 학습의 기회 25
__에러를 읽는 스킬은 항상 도움이 된다 26

2장 에러를 잘 읽는 방법
2.1 에러의 구성 요소를 알아보자 32
__구성 요소 1 에러의 종류 34
__구성 요소 2 에러 메시지 35
__구성 요소 3 스택 트레이스 36
2.2 에러의 종류를 알아보자 47
__에러의 종류 1 SyntaxError 48
__에러의 종류 2 ReferenceError 49
__에러의 종류 3 TypeError 51
__에러의 종류 4 RangeError 52
__다른 언어에서 발생하는 에러의 종류 53

3장 효율적으로 에러의 원인 찾기
3.1 디버깅이란? 58
__디버깅의 흐름 59
3.2 프린트 디버깅을 해보자 61
__프린트 디버깅으로 문제 해결하기 63
__경로를 따라 문제의 위치 특정하기 66
3.3 이진 탐색으로 효율적으로 찾아보자 68
__이진 탐색이란? 68
__프린트 디버깅으로 이진 탐색 71
__에러가 표시되는 부분에 문제가 없을 때는? 76
__더욱 큰 단위로 이진 탐색하기 81
3.4 최소한의 코드로 디버깅해보자 85
__최소한의 코드는 도움을 요청하기 쉽다 89
3.5 디버깅을 빠르게 진행하기 위한 방법 91
__사전에 가설 세우기 91
__한 번에 하나씩 검증하기 93
__작은 의문에 귀를 기울이자 93
__귀찮아하지 말자 94

4장 도구를 활용해 편하게 디버깅해보자
4.1 디버거는 강력한 도구 100
4.2 브레이크포인트를 사용해보자 102
__브레이크포인트란? 102
__브레이크포인트 설정 방법 103
__브레이크포인트를 사용해 디버깅해보자 109
4.3 다양한 스텝 실행 124
__다음 함수 호출(step into) 124
__다음 함수 호출(step over) 126
__현재 함수에서 벗어나기(step out) 127
__스텝의 사용 시기 129
4.4 조건을 포함하는 브레이크포인트 130
__조건을 포함하는 브레이크포인트를 사용해보자 131
__브라우저에서 편리한 조건을 포함하는 브레이크포인트 135
4.5 변수를 감시해보자 136

5장 해결할 수 없는 문제
5.1 개발자를 위한 정보 수집 테크닉 144
__구글 검색 144
__깃허브 검색 149
__커뮤니티에 질문하기 154
__1차 정보를 확인하자 156
5.2 에러를 찾을 수 없을 때 159
__보고 있는 위치가 다름 159
__에러의 출력 설정을 확인하지 않음 161
__에러를 프로그램에서 처리하고 있음 163
5.3 에러가 재현되지 않을 때 165
5.4 운영 환경에서 에러를 수집하는 방법 167
__에러 수집 방법 167
__진화하고 있는 로그 관리 방법 170

6장 디버깅이 쉬운 코드를 작성하자
6.1 재할당을 자제하자 176
__재할당을 억제하는 기능을 사용하자 178
__재할당을 하지 않으면 디버깅도 쉬워진다 178
6.2 스코프를 최소화하자 181
__스코프가 넓을 때의 단점 182
6.3 단일 책임의 원칙 185
구체적인 예 프로필 작성 서비스 185
6.4 순수 함수를 사용하자 189
__순수 함수란? 189
__순수 함수와 순수 함수가 아닌 함수의 비교 192
__순수 함수의 이용 194
6.5 타입을 의식하여 코드를 작성하자 195
__코멘트로 타입 명시하기 196
__프로그래밍 언어의 기능을 사용해 타입 정보 부여하기 197
6.6 디버깅을 도와주는 테스트 코드 201
__테스트 코드는 무엇일까? 201
__테스트 코드와 디버깅의 관계 203
__에러가 발생했을 때 먼저 테스트 코드를 작성하자 204

COLUMN
__결함을 수정하는 데 걸리는 시간 27
__스택 트레이스의 흐름은 프로그래밍 언어에 따라 다를까? 46
__버그는 벌레? 왜 벌레일까? 59
__왜 다른 위치가 표시될까? 80
__깃을 사용한 이진 탐색 84
__자고 나면 버그가 수정된다? 90
__테디 베어 효과 95
__브레이크포인트를 코드에서 설정하기 122
__에디터에서도 사용할 수 있는 디버거 139
__PHP에서 에러 출력 설정 162
__에러 메시지에서 uncaught의 의미는? 164
__여러 방법으로도 에러가 해결되지 않을 때의 회피술 172
__코드의 잠재적인 문제 찾기 180
__동적 타입 언어와 정적 타입 언어 199
__실제 유저의 조작을 재현하는 E2E 테스트 도구 206

에필로그 207
찾아보기 210

[본 문]

에러에 대해서는 자신이 없는 사람도 많다. 프로그램의 작성 방법을 배울 수 있는 기회는 많지만, 에러에 대처하는 방법에 대해서는 배울 기회가 많지 않은 것이 사실이다. 특히 신입 개발자는 에러를 무시하고 넘기는 상황도 있을 것이다. 주인공 나애라처럼 에러를 읽는 습관을 들이지 않은 사람도 물론 있을 것이다. / 책의 목표 중 하나는 에러를 대하는 마음가짐을 바꾸는 것이다. 1장에서는 먼저 ‘왜 에러에 자신이 없을까’, ‘왜 에러를 그냥 넘겨버리는 걸까?’에 초점을 둔다. 형식적인 에러만 배우는 것이 아니라 발생하기 쉬운 에러의 포인트를 파악하는 데 중점을 둔다. 그러다 보면 에러에 대한 자신감이 생길 수 있다. (3쪽)

스택 트레이스는 여러 행에 걸쳐 긴 내용이 표시되는 경우가 있으므로 처음 보는 사람은 거부감을 느낄 수도 있다. / 스택 트레이스는 에러가 발생한 최종 지점부터 확인하는 것이 효율적이다. 모든 행을 읽으려고 하지 말고, 최종 지점의 첫 번째 행부터 읽으면 문제를 쉽게 파악할 수 있다. (43쪽)

조금 과장해서 표현하자면 디버깅은 에러의 원인만 특정할 수 있으면 이미 끝난 것이나 다름없다. 지금까지 배운 것처럼 에러를 읽고 원인까지 찾아갈 수 있으면 문제가 없지만, 에러가 보이지 않거나 에러를 이해할 수 없을 때도 있다. 이때는 프로그램의 상태를 자세히 확인하는 프린트 디버깅 방법과 효율적으로 문제를 나누는 이진 탐색을 활용하여 에러의 원인을 찾아볼 수 있다. (60쪽)

일시 정지한 상태에서 프로그램의 상태를 관찰할 수 있다. 구체적으로는 변수의 데이터를 확인하고 임의의 코드 실행이 가능해진다. 이를 통해 버그의 원인을 특정하거나 프로그램이 예상대로 작동하는지 확인할 수 있다. / 크기가 작은 프로그램이라면 프린트 디버깅으로 변수의 데이터를 확인하는 것도 효과적이지만, 프로그램의 규모가 클 때는 효율이 떨어진다. 브레이크포인트를 활용하면 해당 위치에서 다양한 검증을 할 수 있으므로 프린트 디버깅을 반복하는 시간을 단축할 수 있다. (103쪽)

유저와 같은 방식으로도 에러가 재현되지 않을 때는 단순 조작과 관련된 문제가 아닐 가능성이 크다. 에러를 문의한 유저의 사용 환경 정보를 수집하고 유저와 유사한 환경에서 재현을 시도하자. / 웹 애플리케이션에서 특정 브라우저에서만 에러가 발생하거나 모바일 환경에 대한 미대응으로 정상적인 조작이 되지 않는 경우가 있다. / 또한 시간 정보를 다루는 애플리케이션(캘린더와 리마인드 알람 등)에서는 조작과 처리를 실행하는 시간에 따라 에러 상황이 바뀔 때도 있다. 이는 타임존과 날짜 계산에 따른 에러(윤년과 월말의 날짜 등)가 원인이 되기도 한다. (166쪽)

data = getData()의 행에 변경을 추가하는 상황을 생각해보자. 스코프가 좁을 때는 조건식을 만족할 때만 고려하면 되지만, 스코프가 넓을 때는 함수 sample 전체에 미치는 영향을 고려해야 한다. 변경을 추가할 때는 영향 범위를 조사하여 작동을 보장해야 하므로 스코프가 넓으면 조사할 범위가 넓어지고, 작동의 확인에도 시간이 더 소요된다. / 이와 같이 불필요하게 넓은 스코프는 백해무익하다. 스코프를 줄이는 것은 매우 간단한 작업이므로 항상 의식하도록 하자. (183쪽)