▣ 1장: 리팩터링 리팩터링하기
1.1 리팩터링이란 무엇인가?
1.2 스킬: 무엇을 리팩터링할 것인가?
__1.2.1 코드 스멜의 예
__1.2.2 규칙의 예
1.3 문화: 리팩터링은 언제 할까?
__1.3.1 레거시 시스템에서의 리팩터링
__1.3.2 언제 리팩터링을 하지 말아야 할까?
1.4 도구: (안전한) 리팩터링 방법
1.5 시작하는 데 필요한 도구
__1.5.1 프로그래밍 언어: 타입스크립트
__1.5.2 편집기: 비주얼 스튜디오 코드 1
__1.5.3 버전 관리: Git
1.6 핵심 예제: 2D 퍼즐 게임
__1.6.1 연습만이 살 길이다: 두 번째 코드베이스
1.7 실제 환경에서 소프트웨어에 대한 주의 사항
요약

▣ 2장: 리팩터링 깊게 들여다보기
2.1 가독성 및 유지보수성 향상
__2.1.1 코드 개선
__2.1.2 코드가 하는 일을 바꾸지 않고 유지보수하기
2.2 속도, 유연성 및 안정성 확보
__2.2.1 상속보다는 컴포지션 사용
__2.2.2 수정이 아니라 추가로 코드를 변경
2.3 리팩터링과 일상 업무
__2.3.1 학습 방법으로서의 리팩터링
2.4 소프트웨어 분야에서 '도메인' 정의하기
요약

▣ 3장: 긴 코드 조각내기
3.1 첫 번째 규칙: 왜 다섯 줄인가?
__3.1.1 규칙: 다섯 줄 제한
3.2 함수 분해를 위한 리팩터링 패턴 소개
__3.2.1 리팩터링 패턴: 메서드 추출
3.3 추상화 수준을 맞추기 위한 함수 분해
__3.3.1 규칙: 호출 또는 전달, 한 가지만 할 것
__3.3.2 규칙 적용
3.4 좋은 함수 이름의 속성
3.5 너무 많은 일을 하는 함수 분리하기
__3.5.1 규칙: if 문은 함수의 시작에만 배치
__3.5.2 규칙 적용
요약

▣ 4장: 타입 코드 처리하기
4.1 간단한 if 문 리팩터링
__4.1.1 규칙: if 문에서 else를 사용하지 말 것
__4.1.2 규칙 적용
__4.1.3 리팩터링 패턴: 클래스로 타입 코드 대체
__4.1.4 클래스로 코드 이관하기
__4.1.5 리팩터링 패턴: 클래스로의 코드 이관
__4.1.6 불필요한 메서드 인라인화
__4.1.7 리팩터링 패턴: 메서드의 인라인화
4.2 긴 if 문의 리팩터링
__4.2.1 일반성 제거
__4.2.2 리팩터링 패턴: 메서드 전문화
__4.2.3 switch가 허용되는 유일한 경우
__4.2.4 규칙: switch를 사용하지 말 것
__4.2.5 if 제거하기
4.3 코드 중복 처리
__4.3.1 인터페이스 대신 추상 클래스를 사용할 수는 없을까?
__4.3.2 규칙: 인터페이스에서만 상속받을 것
__4.3.3 클래스에 있는 코드의 중복은 다 무엇일까?
4.4 복잡한 if 체인 구문 리팩터링
4.5 필요 없는 코드 제거하기
__4.5.1 리팩터링 패턴: 삭제 후 컴파일하기
요약

▣ 5장: 유사한 코드 융합하기
5.1 유사한 클래스 통합하기
__5.1.1 리팩터링 패턴: 유사 클래스 통합
5.2 단순한 조건 통합하기
__5.2.1 리팩터링 패턴: if 문 결합
5.3 복잡한 조건 통합하기
__5.3.1 조건을 위한 산술 규칙 사용
__5.3.2 규칙: 순수 조건 사용
__5.3.3 조건 산술 적용
5.4 클래스 간의 코드 통합
__5.4.1 클래스 관계를 묘사하기 위한 UML 클래스 다이어그램 소개
__5.4.2 리팩터링 패턴: 전략 패턴의 도입
__5.4.3 규칙: 구현체가 하나뿐인 인터페이스를 만들지 말 것
__5.4.4 리팩터링 패턴: 구현에서 인터페이스 추출
5.5 유사 함수 통합하기
5.6 유사한 코드 통합하기
요약

▣ 6장: 데이터 보호
6.1 getter 없이 캡슐화하기
__6.1.1 규칙: getter와 setter를 사용하지 말 것
__6.1.2 규칙 적용하기
__6.1.3 리팩터링 패턴: getter와 setter 제거하기
__6.1.4 마지막 getter 삭제
6.2 간단한 데이터 캡슐화하기
__6.2.1 규칙: 공통 접사를 사용하지 말 것
__6.2.2 규칙 적용하기
__6.2.3 리팩터링 패턴: 데이터 캡슐화
6.3 복잡한 데이터 캡슐화
6.4 순서에 존재하는 불변속성 제거하기
__6.4.1 리팩터링 패턴: 순서 강제화
6.5 열거형을 제거하는 또 다른 방법
__6.5.1 비공개 생성자를 통한 열거
__6.5.2 숫자를 클래스에 다시 매핑하기
요약

▣ 7장: 컴파일러와의 협업
7.1 컴파일러에 대해 알아보기
__7.1.1 약점: 정지 문제는 컴파일 시 알 수 있는 것을 제한한다
__7.1.2 장점: 도달성 검증은 메서드의 반환을 보장한다
__7.1.3 장점: 확정 할당은 초기화되지 않은 변수에 대한 접근을 막는다
__7.1.4 장점: 접근 제어로 데이터 캡슐화를 지원한다
__7.1.5 장점: 타입(형) 검사기는 속성을 보증한다
__7.1.6 약점: null을 역참조하면 애플리케이션이 손상된다
__7.1.7 약점: 산술 오류는 오버플로나 손상을 일으킨다
__7.1.8 약점: 아웃-오브-바운드 오류는 애플리케이션을 손상시킨다
__7.1.9 무한루프는 애플리케이션을 지연시킨다
__7.1.10 약점: 교착 상태 및 경쟁 상태로 인해 의도하지 않은 동작이 발생한다
7.2 컴파일러 사용
__7.2.1 컴파일러 활용
__7.2.2 컴파일러와 싸우지 말 것
7.3 컴파일러 신뢰하기
__7.3.1 컴파일러에게 불변속성 가르치기
__7.3.2 컴파일러의 경고에 주의를 기울일 것
7.4 컴파일러만 신뢰할 것
요약

▣ 8장: 주석 자제하기
8.1 오래된 주석 제거
8.2 주석 처리된 코드 제거
8.3 불필요한 주석 제거
8.4 메서드의 이름으로 주석 대신하기
__8.4.1 계획을 위한 주석 사용
8.5 불변속성을 문서화한 주석 유지
__8.5.1 프로세스의 불변속성
요약

▣ 9장: 코드 삭제의 미학
9.1 다음 시대는 코드를 지우는 시대일 것이다
9.2 복잡성을 제거하기 위한 코드 삭제
__9.2.1 경험 부족으로 인한 기술적 무지
__9.2.2 시간 압박으로 인한 기술적 낭비
__9.2.3 환경에 따른 기술적 부채
__9.2.4 성장에 따른 기술적 장애물
9.3 친밀도에 따른 코드 분류
9.4 레거시 시스템에서의 코드 삭제
__9.4.1 스트랭글러 무화과나무 패턴
__9.4.2 코드 개선을 위한 스트랭글러 무화과나무 패턴 사용
9.5 동결된 프로젝트에서 코드 삭제
__9.5.1 바람직한 결과를 기본값으로 설정
__9.5.2 스파이크와 스태빌라이즈(안정화)로 낭비 줄이기
9.6 버전 관리에서 브랜치 삭제
__9.6.1 브랜치 제한으로 낭비 최소화
9.7 코드 문서 삭제
__9.7.1 지식을 문서화하는 방법을 결정하는 알고리즘
9.8 테스트 코드 삭제
__9.8.1 낙관적 테스트 삭제
__9.8.2 비관적 테스트 삭제
__9.8.3 불안정 테스트 수정 또는 삭제
__9.8.4 복잡한 테스트를 제거하기 위한 코드 리팩터링
__9.8.5 속도를 높이는 테스트 문화
9.9 설정 코드 삭제
__9.9.1 설정의 예상 수명으로 범위 지정
9.10 라이브러리 제거를 위한 코드 삭제
__9.10.1 외부 라이브러리에 대한 의존도 제한
9.11 작동 중인 기능에서 코드 삭제
요약

▣ 10장: 코드 추가에 대한 두려움 떨쳐내기
10.1 불확실성 받아들이기: 위험 감수
10.2 두려움 극복을 위한 스파이크 사용
10.3 낭비나 위험에 대한 두려움 극복을 위한 사용 시간 비율 지정
10.4 불완전성에 대한 두려움 극복을 위한 점진적 개선
10.5 복사 및 붙여넣기가 속도에 미치는 영향
10.6 확장성을 통한 추가에 의한 변경
10.7 추가에 의한 변경으로 이전 버전과의 호환성 확보
10.8 기능 토글(켜기/끄기)로 추가에 의한 변경
10.9 '추상화를 통한 분기'로 추가에 의한 변경
요약

▣ 11장: 코드 구조 따르기
11.1 범위와 출처에 따른 구조 분류
11.2 행위를 코드화하는 세 가지 방법
__11.2.1 제어 흐름에 행위 코드화하기
__11.2.2 데이터 구조에 행위 코드화하기
__11.2.3 데이터에 행위 코드화하기
11.3 구조 노출을 위한 코드 추가
11.4 예측 대신 관찰, 그리고 경험적 기술 사용
11.5 코드를 이해하지 않고도 안전성을 확보하는 방안
__11.5.1 테스트를 통한 안전성 확보
__11.5.2 숙달을 통한 안전성 확보
__11.5.3 도구의 지원을 통한 안전성 확보
__11.5.4 공식 인증을 통한 안전성 확보
__11.5.5 내결함성을 통한 안전성 확보
11.6 활용되지 않은 구조 이용
__11.6.1 추출 및 캡슐화에 공백 활용
__11.6.2 통합에 중복 코드 활용
__11.6.3 캡슐화로 공통 접사 활용
__11.6.4 동적 실행으로 런타임 유형 활용
요약

▣ 12장: 최적화 및 일반화 회피
12.1 단순성 추구
12.2 일반화의 시기와 방법
__12.2.1 구현의 최소화로 일반화 지양하기
__12.2.2 안정성이 유사한 것 통합하기
__12.2.3 불필요한 일반화 제거
12.3 최적화 시기와 방법
__12.3.1 최적화 전 리팩터링
__12.3.2 제약 이론에 따른 최적화
__12.3.3 측정 지표를 사용한 최적화
__12.3.4 좋은 알고리즘과 데이터 구조 선택하기
__12.3.5 캐시 사용하기
__12.3.6 최적화된 코드 분리하기
요약

▣ 13장: 나쁜 코드를 식별 가능하게 만들기
13.1 나쁜 코드에 대처하는 자세
13.2 깨끗한 코드와 레거시 코드로 분리
__13.2.1 깨진 유리창 이론
13.3 나쁜 코드를 찾는 방법
__13.3.1 이 책의 규칙: 단순하고 구체적인 코드
__13.3.2 코드 스멜: 완전하고 추상적인 코드
__13.3.3 순환 복잡도: 알고리즘(객관적)
__13.3.4 인지 복잡도: 알고리즘(주관적)
13.4 코드를 안전하게 나쁜 코드로 보이기 위한 규칙
13.5 나쁜 코드를 나쁘게 보이기 위한 방법
__13.5.1 열거형 사용
__13.5.2 정수형 및 문자열을 타입 코드로 사용
__13.5.3 코드에 매직 넘버 넣기
__13.5.4 코드에 주석 넣기
__13.5.5 코드에 공백 넣기
__13.5.6 이름을 기준으로 항목을 그룹화하기
__13.5.7 이름에 컨텍스트 추가하기
__13.5.8 긴 메서드 만들기
__13.5.9 메서드에 많은 매개변수 넘기기
__13.5.10 getter와 setter 사용하기
요약

▣ 14장: 마무리
14.1 이 책의 여정을 돌아보며
__14.1.1 소개: 동기
__14.1.2 1부: 구체화하기
__14.1.3 2부: 지평 넓히기
14.2 기본 철학 탐구
__14.2.1 항상 더 작은 단계 찾기
__14.2.2 기본 구조 찾기
__14.2.3 협업을 위한 규칙 사용
__14.2.4 개인보다 팀을 우선시하기
__14.2.5 완전성보다 단순성 우선하기
__14.2.6 객체 또는 고차함수 사용하기
14.3 이후 여정
__14.3.1 마이크로 아키텍처를 향한 여정
__14.3.2 매크로 아키텍처를 향한 여정
__14.3.3 소프트웨어 품질을 향한 여정
요약

▣ 부록A: 실습을 위한 도구 설치
Node.js
타입스크립트
비주얼 스튜디오 코드
Git
타입스크립트 프로젝트 설정
타입스크립트 프로젝트 빌드
레벨 수정 방법