홈앤서비스 SK BROADBAND

구체적인 규칙에 초점을 맞춰 모든 메서드를 5줄 이하로 줄이는 리팩터링을 가르쳐 준다!

기존 코드를 개선하는 것(리팩터링)은 프로그래머가 맞닥뜨리는 가장 일반적인 작업 중 하나다. 『파이브 라인스 오브 코드』는 코드 스멜과 같은 감각적인 판단에 의존하지 않고, 적용할 수 있는 명확하고 실행 가능한 리팩터링 규칙을 알려준다. 구체적인 원칙을 따르다 보면 리팩터링과 코드 스멜을 익힐 수 있다는 저자의 전문적인 관점에 따라 언제 코드를 리팩터링해야 하는지, 어떤 문제에 어떤 패턴을 적용할지, 재작업이 필요한 코드에는 어떤 특성이 있는지 배우게 된다.

프로그래머가 다루는 모든 코드 베이스에는 찾아서 수정해야 하는 실수와 효율적인지 않은 부분이 있다. 올바른 방법으로 리팩터링하면 코드가 세련되고 읽기 쉽고 유지 관리가 쉬워진다. 이 책에서는 모든 메서드를 5줄 이하로 구현하는 리팩터링에 대한 독창적인 접근 방식을 배운다. 이 책은 모든 기술 수준의 개발자가 읽을 수 있으며, 예제는 자바 및 C#과 동일한 스타일로 읽기 쉬운 타입스크립트를 사용한다.

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