뇌를 알면 코드가 보인다 효율적인 프로그래밍을 위한 참신한 내 머리 사용법 프로그래밍은 까다로운 인지 활동이다. 추상적 수준에서 문제를 해결하는 동시에 코드도 작성해야 한다. 우리 뇌가 코드를 처리하는 방식을 과학적으로 들여다보면, 프로그래밍에서 마주치는 어려움의 원인을 파악하여 그 해결책을 찾을 수 있다. 이 책은 더 나은 프로그래머가 되기 위해 뇌를 십분 활용하는 방법을 다룬다. 장기 기억 공간, 단기 기억 공간, 작업 기억 공간 세 가지 인지 활동의 메커니즘을 이해하면 코드를 더 잘 이해하고 파악할 수 있다. 나아가, 버그 방지, 명확한 변수명 선택, 리팩터링, 대규모 코드베이스 개선에 이르기까지 각종 연구 결과와 과학적으로 입증된 기법을 제시하여 개발자가 새로운 언어나 프레임워크를 빠르게 배우고 생산성을 향상할 수 있게 도와준다. 새로운 개념을 익히기 어려워하는 주니어는 뇌가 ‘원래’ 그렇게 작동한다는 걸 알고 불필요한 자책을 줄일 수 있다. 경력이라고 뽑은 새 팀원의 온보딩이 늦어서 답답함을 느끼는 시니어 역시 그것이 뇌 때문이라는 걸 알고, 새 팀원을 더 잘 이해할 수 있을 것이다. 더 나은 프로그래머를 꿈꾸는 모든 독자에게 권한다. 주요 내용 ■ 코드를 인식할 때의 뇌 작동 원리 ■ 코드를 빠르게 파악하는 읽기 방법 ■ 복잡한 코드와 문제를 쉽게 바꾸는 기법 ■ 협업 환경에서 코드베이스를 개선하는 요령 대상 독자 ■ 프로그래밍 스킬을 향상하고자 하는 모든 개발자 ■ 나만 못한다는 자괴감에 빠진 주니어 개발자 ■ 아무리 가르쳐도 발전이 없는 주니어에게 좌절한 시니어 개발자

옮긴이 머리말 xi 추천의 글 xiii 베타리더 후기 xvi 추천서문(존 스키트) xviii 시작하며 xx 감사의 글 xxii 이 책에 대하여 xxiv 표지에 대하여 xxvi PART I 코드 더 잘 읽기 CHAPTER 1 코딩 중 겪는 혼란에 대한 이해 3 1.1 코드가 초래하는 세 가지 종류의 혼란 4 1.1.1 혼란의 첫 번째 유형: 지식의 부족 5 1.1.2 혼란의 두 번째 유형: 정보의 부족 6 1.1.3 혼란의 세 번째 유형: 처리 능력의 부족 6 1.2 코딩에 영향을 주는 인지 과정 7 1.2.1 LTM과 프로그래밍 8 1.2.2 STM과 프로그래밍 8 1.2.3 작업 기억 공간과 프로그래밍 10 1.3 인지 과정들의 상호작용 10 1.3.1 인지 과정들이 어떻게 상호작용하는지에 대한 간단한 설명 10 1.3.2 프로그래밍 업무와 관련한 인지 과정 11 요약 13 CHAPTER 2 신속한 코드 분석 14 2.1 코드를 신속하게 읽기 15 2.1.1 두뇌에서 무슨 일이 일어나는가? 16 2.1.2 재현한 코드 다시 살펴보기 17 2.1.3 두 번째 실험 다시 살펴보기 19 2.1.4 생소한 코드를 읽는 것은 왜 어려운가? 19 2.2 기억의 크기 제한을 극복하기 20 2.2.1 단위로 묶는 것의 위력 20 2.2.2 전문가는 초보자보다 코드를 더 잘 기억한다 23 2.3 읽는 것보다 보는 것이 더 많다 25 2.3.1 영상 기억 공간 25 2.3.2 기억하는 대상이 중요한 것이 아니고 기억하는 방식이 중요하다 27 2.3.3 청킹 연습 33 요약 35 CHAPTER 3 프로그래밍 문법 빠르게 배우기 36 3.1 문법을 기억하기 위한 팁 37 3.1.1 중간에 끊어지는 것이 미치는 나쁜 영향 37 3.2 플래시카드 사용해 문법 배우기 38 3.2.1 언제 플래시카드를 사용해야 하는가 39 3.2.2 플래시카드의 확장 39 3.2.3 플래시카드 개수 줄이기 40 3.3 어떻게 하면 잊어버리지 않을 수 있을까? 40 3.3.1 기억을 잃어버리는 이유 41 3.3.2 간격을 두고 반복하기 43 3.4 문법을 더 오랫동안 기억하기 44 3.4.1 정보를 기억하는 두 가지 형태 44 3.4.2 단지 보기만 해서는 안 된다 45 3.4.3 정보를 기억하는 것은 기억을 강화한다 46 3.4.4 능동적 사고를 통한 기억력 강화 47 요약 50 CHAPTER 4 복잡한 코드 읽는 방법 51 4.1 복잡한 코드를 이해하는 것이 왜 어려울까? 52 4.1.1 작업 기억 공간과 STM의 차이 53 4.1.2 프로그래밍과 관련한 인지 부하의 종류 53 4.2 인지 부하를 줄이기 위한 기법 55 4.2.1 리팩터링 55 4.2.2 생소한 언어 구성 요소를 다른 것으로 대치하기 57 4.2.3 플래시카드에 코드 동의어 추가 60 4.3 작업 기억 공간에 부하가 오면 사용할 수 있는 기억 보조 수단 61 4.3.1 의존 그래프 생성 61 4.3.2 상태표 사용 64 4.3.3 의존 그래프와 상태표의 혼용 66 요약 68 PART II 코드에 대해 생각하기 CHAPTER 5 코드를 더 깊이 있게 이해하기 71 5.1 ‘변수 역할’ 프레임워크 72 5.1.1 변수는 각자 다른 일을 한다 72 5.1.2 11가지 역할 73 5.2 역할과 패러다임 76 5.2.1 역할의 이점 76 5.2.2 헝가리안 표기법 78 5.3 프로그램에 대해 깊이 있는 지식을 얻으려면 80 5.3.1 텍스트 지식 대 계획 지식 80 5.3.2 프로그램 이해의 여러 단계 81 5.4 텍스트를 읽는 것과 코드를 읽는 것은 유사하다 84 5.4.1 코드를 읽을 때 우리 뇌에서는 무슨 일이 일어나는가? 85 5.4.2 프랑스어를 배울 수 있다면 파이썬도 배울 수 있다 86 5.5 코드 읽기에 적용해볼 수 있는 텍스트 이해 전략 90 5.5.1 기존 지식의 활성화 91 5.5.2 모니터링 91 5.5.3 코드에서 중요한 라인을 결정하기 92 5.5.4 변수명의 의미를 추론하기 93 5.5.5 시각화 94 5.5.6 질문하기 96 5.5.7 코드 요약 96 요약 97 CHAPTER 6 코딩 문제 해결을 더 잘하려면 98 6.1 모델을 사용해서 코드에 대해 생각해보기 99 6.1.1 모델의 유익함 99 6.2 정신 모델 102 6.2.1 정신 모델 자세히 살펴보기 103 6.2.2 새로운 정신 모델 배우기 104 6.2.3 코드에 대해 생각할 때 정신 모델을 효율적으로 사용하는 방법 105 6.3 개념적 기계 110 6.3.1 개념적 기계는 무엇인가? 111 6.3.2 개념적 기계의 예 111 6.3.3 개념적 기계의 층위 113 6.4 개념적 기계와 언어 114 6.4.1 개념적 기계의 확장 114 6.4.2 여러 개념적 기계는 서로 충돌하는 정신 모델을 만들 수 있다 115 6.5 개념적 기계와 스키마타 117 6.5.1 왜 스키마타가 중요한가? 117 6.5.2 개념적 기계는 의미론인가? 117 요약 117 CHAPTER 7 생각의 버그 119 7.1 왜 두 번째 프로그래밍 언어가 첫 번째보다 쉬울까? 120 7.1.1 기존 프로그래밍 지식을 활용할 가능성을 높이는 방법 122 7.1.2 전이의 다른 형태 123 7.1.3 이미 알고 있다는 것은 저주인가 축복인가? 124 7.1.4 전이의 어려움 125 7.2 오해: 생각의 버그 127 7.2.1 개념 변화를 통한 오개념 디버깅 128 7.2.2 오개념 제압하기 129 7.2.3 프로그래밍 언어에 대한 오개념 130 7.2.4 새로운 프로그래밍 언어를 배울 때 오개념 방지하기 132 7.2.5 새로운 코드베이스에서의 오개념 진단 132 요약 133 PART III 좋은 코드 작성하기 CHAPTER 8 명명을 잘하는 방법 137 8.1 이름이 중요한 이유 138 8.1.1 명명이 중요한 이유 139 8.1.2 명명에 대한 다양한 관점 140 8.1.3 초기 명명 관행은 지속적인 영향을 미친다 142 8.2 명명의 인지적 측면 144 8.2.1 형식이 있는 이름은 STM을 돕는다 144 8.2.2 명확한 이름이 LTM에 도움이 된다 145 8.2.3 변수 이름은 이해에 도움이 되는 다양한 유형의 정보를 포함할 수 있다 146 8.2.4 이름의 품질 평가 시기 147 8.3 어떤 종류의 이름이 더 이해하기 쉬운가? 148 8.3.1 축약할 것인가, 하지 않을 것인가? 148 8.3.2 스네이크 케이스냐, 캐멀 케이스냐? 152 8.4 이름이 버그에 미치는 영향 153 8.4.1 나쁜 이름을 가진 코드에 버그가 더 많다 153 8.5 더 나은 이름을 선택하는 방법 154 8.5.1 이름 틀 154 8.5.2 더 나은 변수명에 대한 페이텔슨의 3단계 모델 157 요약 158 CHAPTER 9 나쁜 코드와 인지 부하를 방지하는 두 가지 프레임워크 159 9.1 코드 스멜이 인지 부하를 초래하는 이유 160 9.1.1 코드 스멜에 대한 간략한 소개 160 9.1.2 코드 스멜이 인지 과정에 악영향을 미치는 방식 163 9.2 나쁜 이름이 인지 부하에 미치는 영향 165 9.2.1 언어적 안티패턴 166 9.2.2 인지 부하 측정 167 9.2.3 언어적 안티패턴 및 인지 부하 170 9.2.4 언어적 안티패턴이 혼란을 일으키는 이유 171 요약 172 CHAPTER 10 복잡한 문제 해결을 더 잘하려면 173 10.1 문제 해결이란 무엇인가? 174 10.1.1 문제 해결 요소 174 10.1.2 상태 공간 174 10.2 프로그래밍 문제를 해결할 때 LTM의 역할은 무엇인가? 175 10.2.1 문제 해결은 그 자체로 인지 과정인가? 175 10.2.2 문제 해결을 위한 LTM 교육 방법 177 10.2.3 문제 해결에 역할을 하는 두 가지 유형의 기억 177 10.3 자동화: 암시적 기억 생성 180 10.3.1 시간 경과에 따른 암시적 기억 181 10.3.2 자동화를 통해 보다 신속하게 프로그램을 실행할 수 있는 이유 184 10.3.3 암시적 기억 개선 185 10.4 코드와 해설에서 배우기 186 10.4.1 새로운 유형의 인지 부하: 본유적 부하 187 10.4.2 개발 작업 시 풀이된 예제 활용하기 189 요약 190 PART IV 코딩에서의 협업 CHAPTER 11 코드를 작성하는 행위 193 11.1 프로그래밍 중 이루어지는 다양한 활동 194 11.1.1 검색 194 11.1.2 이해 195 11.1.3 전사 195 11.1.4 증가 195 11.1.5 탐구 196 11.1.6 디버깅은 어떤가? 197 11.2 프로그래머의 업무 중단 197 11.2.1 프로그래밍 작업 시 워밍업 필요 198 11.2.2 중단 후에는 어떻게 되는가? 198 11.2.3 중단에 잘 대비하는 방법 199 11.2.4 프로그래머를 방해할 때 202 11.2.5 멀티태스킹에 대한 고찰 204 요약 205 CHAPTER 12 대규모 시스템의 설계와 개선 206 12.1 코드베이스의 특성 조사 207 12.1.1 인지적 차원 207 12.1.2 코드베이스 개선을 위해 CDCB 사용 217 12.1.3 설계 기동 및 트레이드오프 218 12.2 차원 및 활동 219 12.2.1 차원이 활동에 미치는 영향 219 12.2.2 예상 활동에 대한 코드베이스 최적화 221 요약 221 CHAPTER 13 새로운 개발자 팀원의 적응 지원 222 13.1 적응 지원의 문제 223 13.2 전문가와 초보자의 차이 224 13.2.1 초보자의 행동에 대한 심층적 이해 225 13.2.2 개념을 구체적으로 보는 것과 추상적으로 보는 것의 차이 229 13.3 적응 지원 개선 231 13.3.1 작업은 하나의 프로그래밍 활동으로만 제한 231 13.3.2 새 팀원의 기억 지원 232 13.3.3 코드 함께 읽기 234 요약 237 마치며 238 찾아보기 241

지식이 없다는 것은 두뇌의 장기 기억 공간(long-term memory, LTM)에 해당 내용이 없다는 것을 뜻한다. 장기 기억 공간은 기억하는 내용을 반영구적으로 저장하는 곳이다. 반면에 지식이 아닌 어떤 정보가 부족할 때는 단기 기억 공간(short-term memory, STM)에 해당 내용이 없기 때문이다. 정보를 수집할 때 단기 기억 장소에 일시적으로 저장하지만, 다른 정보를 찾는 과정에서 이미 수집해놓은 정보 중 일부는 잊어버린다. 마지막으로, 많은 정보를 처리할 때는 작업 기억 공간(working memory)에 영향을 미치는데 우리는 사고할 때 이 영역을 사용한다. (7쪽) 연구에 의하면 프로그래머의 시간 중 거의 60%를 코드를 ‘작성’하는 게 아니라 ‘이해’하는 데 사용한다고 한다. 따라서 정확도를 유지하면서 코드를 빨리 이해하도록 향상한다면 프로그래밍 기술이 크게 개선되는 셈이다. (…) 프로그래밍을 처음 배울 때는 코드를 만들어내는 것에 관심을 많이 갖는다. 대학이나 직장, 혹은 부트캠프에서도 일단 프로그래밍을 배우고 나면 코드를 작성하는 것에 훨씬 더 많은 관심과 시간을 쏟는다. 문제를 어떻게 풀고 그것을 코드로 어떻게 구현하는지를 집중적으로 훈련한다. 코드를 읽는 연습은 거의 전무할 것이다. 이 장을 통해 코드를 읽는 기술을 향상하길 바란다. (14~15쪽) 파닌은 85명의 프로그래머에 대해 1만 회의 프로그래밍 세션을 기록했다. 그는 개발자들이 이메일이나 동료들 때문에 얼마나 자주 업무를 중단하는지 확인했고(이런 일은 정말 자주 발생했다!) 그 후에 무슨 일이 일어나는지도 관찰했다. 파닌은 업무가 중단되는 것이 생산성에 악영향을 미친다고 결론 내렸는데 이것은 당연하다. 그의 연구에 의하면 코딩을 작성하는 도중 중단이 되면 다시 그 업무로 돌아가는 데 약 15분 정도 걸렸다. 메서드 수정 작업 도중 중단이 되고 나서 1분 이내에 하던 일을 다시 시작하는 경우는 10% 정도밖에 되지 않았다. (…) 이제 문법을 빠르게 배우는 방법에 대해 알아보자. (38쪽) 계산 능력, 즉 수학적 능력을 적용해야 하는 지식과 기술은 프로그래밍 능력에 대한 예측력이 작았다. 실험 참여자들 사이에서 겨우 2%의 분산(편차)이 나타났다. 언어 능력이 더 나은 예측요인으로 17% 분산이 나왔다. 이것은 흥미로운 결과다. 개발자들은 보통 수학 능력을 중요시하고, 필자가 아는 많은 프로그래머는 자신들이 언어에 소질이 없다고 말했기 때문이다. 세 가지 테스트에서 가장 뛰어난 예측력을 보인 요인은 작업 기억 공간 용량과 추론 능력이었다. (87쪽) 안타깝게도, 사람들이 깊은 인지 작업을 하는 동안 여러 가지 일을 할 수 없다는 증거가 압도적으로 많다. 음악을 들으면서 이 책을 읽거나, 뛰거나 뜨개질을 하면서 이 책을 듣고 있는 사람도 있을 수 있기에 이 말이 설득력이 없을 수 있는데, 사람이 두 가지 일을 동시에 할 수 없다고 필자는 어떻게 단언할 수 있을까? (…) 멀티태스킹이 우리가 생각하는 것만큼 잘 작동하지 않는다는 것을 보여주는 과학적 근거를 몇 가지 살펴보겠다. (204쪽)