1.
읽기 좋은 코드가
좋은 코드다
책 요약정리
- 작성자: 황대영
- 수정일자: 2016.05.06

2.
목차
1. 저자
2. 역자
3. 책 소개
4. 요약정리 기준
5. 코드는 이해하기 쉬워야 한다
6. 이름에 정보 담기
1. 오해할 수 없는 이름들
2. 미학
3. 주석에 담아야 하는 대상
4. 명확하고 간결한 주석 달기
5. 읽기 쉽게 흐름제어 만들기

3.
목차
1. 거대한 표현을 잘게 쪼개기
2. 변수와 가독성
3. 상관없는 하위문제 추출하기 (생략)
4. 한 번에 하나씩 (생략)
5. 생각을 코드로 만들기 (생략)
6. 코드 분량 줄이기 (생략)
1. 테스트와 가독성 (생략)
2. ‘분/시간 카운터’를 설계하고 구현
하기 (생략)
3. 추가적인 도서목록 (생략)
4. 감사합니다.

4.
저자
1. 더스틴 보즈웰
a. 칼텍에서 컴퓨터 사이언스 학사학위
b. UC 샌디에고에서 석사학위
c. 5년 동안 구글에서 근무하면서 웹 크롤링 인프라 스트럭처를 비롯한 다양한 프로젝트를 경험
d. 수많은 웹사이트를 개발했고 ‘빅 데이터’와 ‘기계학습’ 분야에 관심

5.
저자
1. 트레버 파우커
a. 10년 동안 마이크로소프트와 구글에서 대규모 소프트웨어를 개발
b. 구글에서 검색 인프라 스트럭처의 엔지니어로 근무
c. 여가 시간에는 게임 관련 컨벤션에 참석, 공상과학 소설을 읽고
d. UC 버클리에서 전기공학과 컴퓨터 사이언스 학사학위

6.
역자
1. 임백준
a. 서울대학교 수학 전공
b. 인디애나 주립대학 컴퓨터 사이언스 전공
c. 삼성SDS, 뉴저지 소재 루슨트테크놀로지스에서 근무
d. 월스트리트에 있는 회사에서 금융소프트웨어 개발
e. 집필
i. [누워서 읽는 퍼즐북] [프로그래밍은 상상이다] [뉴욕의 프로그래머] [소프트웨어 산책]
[나는 프로그래머다] [누워서 읽는 알고리즘] [행복한 프로그래밍] [프로그래머 그 다음
이야기]

7.
책 소개
• 책 제목: 읽기 좋은 코드가 좋은 코드다
• 출판사: 한빛미디어
• 출간일: 2012년 04월 10일
http://www.yes24.com/24/goods/6692314?scode=032&OzSrank=1
책은 꼭 사서 봅시다!

8.
요약정리 기준
1. 코드 생략
2. 예제 생략
3. 이 책의 핵심을 예제와 코드를 통한 설명인데 이게 빠져 있으니 이해하는데
불편할 수 있으니
4. 책을 직접 보시고 해당 슬라이드를 보는 것을 권해 드립니다.

9.
1장 코드는 이해하기 쉬워야 한다
1. 무엇이 코드를 ‘더 좋게’ 만드는가?
2. 가독성의 기본 정리 The Fundamental Theorem of Readability
a. 코드는 다른 사람이 그것을 이해하는 데 들이는 시간을 최소화하는 방식으로 작성되어야 한
다.

10.
1장 코드는 이해하기 쉬워야 한다
1. 분량이 적으면 항상 더 좋은가?
a. 적은 분량으로 코드를 작성하는 것이 좋은 목표이긴 하지만,
b. 이해를 위한 시간을 최소화하는 게 더 좋은 목표
2. 이해를 위한 시간은 다른 목표와 충돌하는가?
a. 잘 구성된 아키텍처와 테스트하기 쉬운 코드를 작성하게 도움
b. 고도로 최적화된 코드조차도 이해하기 쉽게 만드는 방법

11.
2장 이름에 정보 담기
1. 이름에 정보를 담아내라
2. 특정 단어 고르기
a. 재치 있는 이름보다 명확하고 간결한 이름이 더 좋다

12.
2장 이름에 정보 담기
1. tmp나 retval 같은 보편적인 이름 피하기
a. 더 좋은 이름은 변수의 목적이나 담고 있는 값을 설명해주어야 한다.
b. retval 이라는 이름은 정보를 제대로 담고 있지 않다. 대신 변수값을 설명하는 이름을 사용하
라
c. tmp 라는 이름은 대상이 짧게 임시적으로만 존재하고, 임시적 존재 자체가 변수의 가장 중요
한 용도일 때에 한해서 사용해야 한다.
d. tmp, it, retval 같은 보편적인 이름을 사용하려면, 꼭 그렇게 해야 하는 이유가 있어야 한다.
2. 추상적인 이름보다 구체적인 이름을 선호하라

13.
2장 이름에 정보 담기
1. 추가적인 정보를 이름에 추가하기
a. 단위를 포함하는 값들
i. 변수명에 단위를 포함시키는 게 도움이 됨
2. 다른 중요한 속성 포함하기
a. 어떤 변수에 위험한 요소 혹은 나중에 놀랄만한 내용이 있다면 언제든지 이 방법을 사용할 필
요가 있다.

14.
2장 이름에 정보 담기
1. 이름은 얼마나 길어야 하는가?
a. 좁은 범위에서는 짧은 이름이 괜찮다
b. 긴 이름 입력하기 - 더 이상 문제가 되지 않는다
i. 텍스트 편집기 기능 적극 활용
c. 약어와 축약형
i. 일반적인 관례를 따르는 약어와 축약형은 허용
ii. 예: string = str, document = doc

15.
2장 이름에 정보 담기
a. 불필요한 단어 제거하기
i. 경우에 따라서는 아무런 정보를 손실하지 않으면서 이름에 포함된 단어를 제거할 수도
있음
1. 이름 포맷팅으로 의미를 전달하기
a. 밑줄과 대시 그리고 대문자를 잘 이용하면 이름에 더 많은 정보를 담을 수 있다.
b. 다른 포맷팅 관습

16.
3장 오해할 수 없는 이름들
1. 본인이 지은 이름을 “다른 사람들이 다른 의미로 해석할 수 있을까?” 라는 질
문을 던져보며 철저하게 확인해야 한다
2. 경계를 포함하는 한계값을 다룰 때는 min과 max를 사용하라
a. 한계를 설정하는 이름을 가장 명확하게 만드는 방법은 제한받는 대상의 이름 앞에 max_나
min_을 붙이는 것이다.

17.
3장 오해할 수 없는 이름들
1. 경계를 포함하는 범위에는 first와 last를 사용하라
2. 경계를 포함하고/배제하는 범위에는 begin과 end를 사용하라

18.
3장 오해할 수 없는 이름들
1. 불리언 변수에 이름 붙이기
a. is, has, can, should 와 같은 단어를 더하면 불리언 값의 의미가 더 명확해짐
b. 의미를 부정하는 용어는 피할 것
2. 사용자의 기대에 부응하기
a. 대개 get 으로 시작되는 이름의 메소드는 ‘가벼운 접근자’로서 단순히 내부 멤버를 반환한다
고 관행적으로 생각한다.

19.
4장 미학
1. 좋은 소스코드는 ‘눈을 편하게’ 해야 한다.
a. 코드를 읽는 사람이 이미 친숙한, 일관성 있는 레이아웃을 사용하라.
b. 비슷한 코드는 서로 비슷해 보이게 만들어라.
c. 서로 연관된 코드는 하나의 블록으로 묶어라.
2. 미학과 리팩토링 같은 코드의 설계는 서로 독립된 아이디어에 해당하나, 두
가지를 동시에 추구하는 것이 가장 이상적

20.
4장 미학
1. 미학이 무슨 상관인가?
a. 미학적으로 보기 좋은 코드가 사용하기 더 편리하다는 사실
2. 일관성과 간결성을 위해서 줄 바꿈을 재정렬하기

21.
4장 미학
1. 메소드를 활용하여 불규칙성을 정리하라
a. 코드를 ‘보기 예쁘게’ 만드는 작업은 표면적인 개선 이상의 결과, 즉 코드의 구조 자체를 개선
2. 도움이 된다면 코드의 열을 맞춰라

22.
4장 미학
1. 의미 있는 순서를 선택하고 일관성 있게 사용하라
a. 가장 중요한 것에서 시작해서 가장 덜 중요한 것까지 순서대로 나열
b. 알파벳 순서대로 나열
2. 선언문을 블록으로 구성하라
a. 논리적 영역에 따라서 여러 개의 그룹으로 나누면 더 좋음

23.
4장 미학
1. 코드를 ‘문단’으로 쪼개라
a. 비슷한 생각을 하나로 묶어서, 성격이 다른 생각과 구분
b. 문단은 ‘시각적 디딤돌’ 역할을 수행한다.
c. 하나의 문단에서 다른 문단으로서의 전진을 촉진
d. 각 문단의 주석 처리
2. 개인적인 스타일 대 일관성
a. 일관성 있는 스타일은 ‘올바른’ 스타일보다 더 중요하다.

24.
5장 주석에 담아야 하는 대상
1. 주석의 목적은 코드를 읽는 사람이 코드를 작성한 사람만큼 코드를 잘 이해
하게 돕는데 있다.
2. 설명하지 말아야 하는 것
a. 코드에서 빠르게 유추할 수 있는 내용은 주석으로 달지 말라.
b. 설명 자체를 위한 설명을 달지 말라
c. 나쁜 이름에 주석을 달지 말라 - 대신 이름을 고쳐라
i. 좋은 코드 > 나쁜 코드 + 좋은 주석

25.
5장 주석에 담아야 하는 대상
1. 생각을 기록하라
a. 코딩할 때 생각했던 중요한 생각을 기록
b. ‘감독의 설명’을 포함하라.
c. 코드에 있는 결함을 설명하라

26.
5장 주석에 담아야 하는 대상
1. 표시 - 보통의 의미
a. TODO: 아직 하지 않은 일
b. FIXME: 오동작을 일으킨다고 알려진 코드
c. HACK: 아름답지 않은 해결책
d. XXX: 위험! 여기 큰 문제가 있다
2. 상수에 대한 설명

27.
5장 주석에 담아야 하는 대상
1. 코드를 읽는 사람의 입장이 되어라
a. ‘코드를 처음으로 읽는 외부인의 입장에 자기 자신을 놓는 기법’ == 이 책
b. 나올 것 같은 질문 예측하기
c. 사람들이 쉽게 빠질 것 같은 함정을 경고하라
d. ‘큰 그림’에 대한 주석
e. 요약 주석 - 함수 내부에서 ‘큰 그림’을 설명하는 방식

28.
5장 주석에 담아야 하는 대상
1. 마지막 고찰 - 글 쓰는 두려움을 떨쳐내라
a. 마음에 떠오르는 생각을 무조건 적어본다
b. 주석을 일고 무엇이 개선되어야 하는지 확인한다
c. 개선한다

29.
6장 명확하고 간결한 주석 달기
1. 주석은 높은 ‘정보 대 공간’ 비율을 갖춰야 한다
2. 주석을 간결하게 하라
3. 모호한 대명사는 피하라
4. 엉터리 문장을 다듬어라
5. 함수의 동작을 명확하게 설명하라
6. 코너케이스를 설명해주는 입/출력 예를 사용하라

30.
6장 명확하고 간결한 주석 달기
1. 코드의 의도를 명시하라
2. 이름을 가진 함수 파라미터 Named Function Parameter 주석
3. 정보 축약형 단어를 사용하라

31.
7장 읽기 쉽게 흐름제어 만들기
1. 흐름을 제어하는 조건과 루프 그리고 여타 요소를 최대한 ‘자연스럽게’ 만들
도록 노력하라.
2. 코드를 읽다가 다시 되돌아가서 코드를 읽지 않아도 되게끔 만들어야 한다.
3. 조건문에서 인수의 순서
a. 왼쪽 <=> 오른쪽
b. 값이 더 유동적인 ‘질문을 받는’ 표현 <=> 더 고정적인 값으로, 비교대상으로 사용되는 표현

32.
7장 읽기 쉽게 흐름제어 만들기
1. if / else 블록의 순서
a. 부정이 아닌 긍정을 다루어라
b. 간단한 것을 먼저 처리하라
c. 더 흥미롭고, 확실한 것을 먼저 다루어라

33.
7장 읽기 쉽게 흐름제어 만들기
1. (삼항 연산자로 알려진)?:를 이용하는 조건문 표현
a. 줄 수를 최소하는 일보다 다른 사람이 코드를 읽고 이해하는 데 걸리는 시간을 최소화하는 일
이 더 중요
b. 기본적으로 if / else 이용
2. do / while 루프를 피하라
a. 대부분의 do / while 루프가 while 루프로 작성될 수 있다
b. “내 경험으로 에러와 혼동의 원인은 do 문에 있다. 그래서 나는 ‘눈에 뜨이는 곳에 미리’ 나타
나도록 만드는 것을 선호한다. 결과적으로 나는 do문을 피하는 경향이 있다.” - C+++ 창시자

34.
7장 읽기 쉽게 흐름제어 만들기
1. 함수 중간에서 반환하기
2. 악명 높은 goto
a. goto는 피할 수 있다면 피하는 게 낫다

35.
7장 읽기 쉽게 흐름제어 만들기
1. 중첩을 최소화하기
a. 코드의 중첩이 심할수록 이해하기 어렵다
b. 중첩이 축적되는 방법
i. 수정해야 하는 상황이라면 여러분의 코드를 새로운 관점에서 바라보라.
c. 함수 중간에서 반환하여 중첩을 제거하라
d. 루프 내부에 있는 중첩 제거하기

36.
8장 거대한 표현을 잘게 쪼개기
1. 거대한 표현을 더 소화하기 쉬운 여러 조각으로 나눈다.
2. 설명 변수
a. 추가 변수는 하위표현의 의미를 설명하므로 ‘설명 변수 explaining variable’
3. 요약 변수
a. 의미를 쉽게 파악할 수 있어 별도의 설명을 요구하지 않는 표현이라고 해도, 새로운 변수로 담
아두는 방법은 여전히 유용할 수 있다.
4. 드모르간의 법칙 사용하기

37.
8장 거대한 표현을 잘게 쪼개기
1. 쇼트 서킷 논리 short-cut logic 오용 말기
a. 영리하게 작성된 코드에 유의하라. 나중에 다른 사람이 읽으면 그런 코드가 종종 혼란을 초래
한다.
2. 거대한 구문 나누기
3. 표현을 단순화하는 다른 창의적인 방법들

38.
9장 변수와 가독성
1. 세 가지 문제점
a. 변수의 수가 많을수록 기억하고 다루기 더 어려워진다
b. 변수의 범위가 넓어질수록 기억하고 다루는 시간이 더 길어진다.
c. 변수값이 자주 바뀔수록 현재 값을 기억하고 다루기가 더 어려워진다.
2. 변수 제거하기
a. 불필요한 임시 변수들
b. 중간 결과 삭제하기
c. 흐름 제어 변수 제거하기

39.
9장 변수와 가독성
1. 변수의 범위를 좁혀라
a. 전역 변수를 피하라
b. 모든 변수의 범위를 두 배로 축소시키면, 한 번에 읽어야 하는 변수의 수는 평균적으로 반으로
줄어든다.
c. 메소드를 정적 static으로 만들어서 클래스 멤버 접근을 제한하라.
d. 커다란 클래스를 여러 작은 클래스로 나누는 방법

40.
감사합니다.
부족한 자료 봐주셔서 감사합니다.
피득백 주시면 더욱 감사하겠습니다.
책은 꼭 사서 봅시다!
http://www.yes24.com/24/goods/6692314?scode=032&OzSrank=1