▣ 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 타입스크립트 프로젝트 설정 타입스크립트 프로젝트 빌드 레벨 수정 방법