소프트웨어 악취를 제거하는 리팩토링

1장 기술 부채

1.1 기술 부채의 개념
1.2 기술 부채의 구성 요소
1.3 기술 부채가 미치는 영향
1.4 기술 부채를 초래하는 원인
1.5 기술 부채를 관리하는 방법

2장 설계 악취

2.1 악취에 신경 써야 하는 이유
2.2 악취를 일으키는 요인
2.2.1 설계 원칙 위반
2.2.2 부적절한 패턴 사용
2.2.3 언어 제약
2.2.4 객체 지향에서 절차적인 사고방식
2.2.5 점성
2.2.6 우수 관례와 우수 프로세스의 미준수
2.3 악취를 해소하는 방법
2.4 책에서 다루는 악취 범위
2.5 설계 악취의 분류
2.5.1 악취 분류를 기반으로 한 설계 원칙
2.5.2 악취를 명명하는 방식
2.5.3 악취를 문서화하는 템플릿

3장 추상화 악취

3.1 누락된 추상화
3.1.1 근거
3.1.2 잠재적인 원인
3.1.3 예제
3.1.4 리팩토링 제안
3.1.5 영향을 받는 품질 속성
3.1.6 다른 이름
3.1.7 현실적인 고려 사항
3.2 명령 추상화
3.2.1 근거
3.2.2 잠재적인 원인
3.2.3 예제
3.2.4 리팩토링 제안
3.2.5 영향을 받는 품질 속성
3.2.6 다른 이름
3.2.7 현실적인 고려 사항
3.3 불완전한 추상화
3.3.1 근거
3.3.2 잠재적인 원인
3.3.3 예제
3.3.4 리팩토링 제안
3.3.5 영향을 받는 품질 속성
3.3.6 다른 이름
3.3.7 현실적인 고려 사항
3.4 다면적인 추상화
3.4.1 근거
3.4.2 잠재적인 원인
3.4.3 예제
3.4.4 리팩토링 제안
3.4.5 영향을 받는 품질 속성
3.4.6 다른 이름
3.4.7 현실적인 고려 사항
3.5 불필요한 추상화
3.5.1 근거
3.5.2 잠재적인 원인
3.5.3 예제
3.5.4 리팩토링 제안
3.5.5 영향을 받는 품질 속성
3.5.6 다른 이름
3.5.7 현실적인 고려 사항
3.6 미활용 추상화
3.6.1 근거
3.6.2 잠재적인 원인
3.6.3 예제
3.6.4 리팩토링 제안
3.6.5 영향을 받는 품질 속성
3.6.6 다른 이름
3.6.7 현실적인 고려 사항
3.7 중복된 추상화
3.7.1 근거
3.7.2 잠재적인 원인
3.7.3 예제
3.7.4 리팩토링 제안
3.7.5 영향을 받는 품질 속성
3.7.6 다른 이름
3.7.7 현실적인 고려 사항

4장 캡슐화 악취

4.1 부족한 캡슐화
4.1.1 근거
4.1.2 잠재적인 원인
4.1.3 예제
4.1.4 리팩토링 제안
4.1.5 영향을 받는 품질 속성
4.1.6 다른 이름
4.1.7 현실적인 고려 사항
4.2 누설된 캡슐화
4.2.1 근거
4.2.2 잠재적인 원인
4.2.3 예제
4.2.4 리팩토링 제안
4.2.5 영향을 받는 품질 속성
4.2.6 다른 이름
4.2.7 현실적인 고려 사항
4.3 누락된 캡슐화
4.3.1 근거
4.3.2 잠재적인 원인
4.3.3 예제
4.3.4 리팩토링 제안
4.3.5 영향을 받는 품질 속성
4.3.6 다른 이름
4.3.7 현실적인 고려 사항
4.4 미활용 캡슐화
4.4.1 근거
4.4.2 잠재적인 원인
4.4.3 예제
4.4.4 리팩토링 제안
4.4.5 영향을 받는 품질 속성
4.4.6 다른 이름
4.4.7 현실적인 고려 사항

5장 모듈화 악취

5.1 망가진 모듈화
5.1.1 근거
5.1.2 잠재적인 원인
5.1.3 예제
5.1.4 리팩토링 제안
5.1.5 영향을 받는 품질 속성
5.1.6 다른 이름
5.1.7 현실적인 고려 사항
5.2 불충분한 모듈화
5.2.1 근거
5.2.2 잠재적인 원인
5.2.3 예제
5.2.4 리팩토링 제안
5.2.5 영향을 받는 품질 속성
5.2.6 다른 이름
5.2.7 현실적인 고려 사항
5.3 순환 의존성이 있는 모듈화
5.3.1 근거
5.3.2 잠재적인 원인
5.3.3 예제
5.3.4 리팩토링 제안
5.3.5 영향을 받는 품질 속성
5.3.6 다른 이름
5.3.7 현실적인 고려 사항
5.4 허브와 같은 모듈화
5.4.1 근거
5.4.2 잠재적인 원인
5.4.3 예제
5.4.4 리팩토링 제안
5.4.5 영향을 받는 품질 속성
5.4.6 다른 이름
5.4.7 현실적인 고려 사항

6장 계층 악취

6.1 누락된 계층
6.1.1 근거
6.1.2 잠재적인 원인
6.1.3 예제
6.1.4 리팩토링 제안
6.1.5 영향을 받는 품질 속성
6.1.6 다른 이름
6.1.7 현실적인 고려 사항
6.2 불필요한 계층
6.2.1 근거
6.2.2 잠재적인 원인
6.2.3 예제
6.2.4 리팩토링 제안
6.2.5 영향을 받는 품질 속성
6.2.6 다른 이름
6.2.7 현실적인 고려 사항
6.3 팩토링되지 않은 계층
6.3.1 근거
6.3.2 잠재적인 원인
6.3.3 예제
6.3.4 리팩토링 제안
6.3.5 영향을 받는 품질 속성
6.3.6 다른 이름
6.3.7 현실적인 고려 사항
6.4 넓은 계층
6.4.1 근거
6.4.2 잠재적인 원인
6.4.3 예제
6.4.4 리팩토링 제안
6.4.5 영향을 받는 품질 속성
6.4.6 다른 이름
6.4.7 현실적인 고려 사항
6.5 추측에 근거한 계층
6.5.1 근거
6.5.2 잠재적인 원인
6.5.3 예제
6.5.4 리팩토링 제안
6.5.5 영향을 받는 품질 속성
6.5.6 다른 이름
6.5.7 현실적인 고려 사항
6.6 깊은 계층
6.6.1 근거
6.6.2 잠재적인 원인
6.6.3 예제
6.6.4 리팩토링 제안
6.6.5 영향을 받는 품질 속성
6.6.6 다른 이름
6.6.7 현실적인 고려 사항
6.7 반체제적인 계층
6.7.1 근거
6.7.2 잠재적인 원인
6.7.3 예제
6.7.4 리팩토링 제안
6.7.5 영향을 받는 품질 속성
6.7.6 다른 이름
6.7.7 현실적인 고려 사항
6.8 망가진 계층
6.8.1 근거
6.8.2 잠재적인 원인
6.8.3 예제
6.8.4 리팩토링 제안
6.8.5 영향을 받는 품질 속성
6.8.6 다른 이름
6.8.7 현실적인 고려 사항
6.9 다중 경로 계층
6.9.1 근거
6.9.2 잠재적인 원인
6.9.3 예제
6.9.4 리팩토링 제안
6.9.5 영향을 받는 품질 속성
6.9.6 다른 이름
6.9.7 현실적인 고려 사항
6.10 순환 계층
6.10.1 근거
6.10.2 잠재적인 원인
6.10.3 예제
6.10.4 리팩토링 제안
6.10.5 영향을 받는 품질 속성
6.10.6 다른 이름
6.10.7 현실적인 고려 사항

7장 악취 생태계

7.1 맥락의 역할
7.2 악취의 상호작용
7.2.1 고립되어 나타나지 않는 악취
7.2.2 더 깊은 문제를 암시하는 악취

8장 실전 기술 부채 상환

8.1 도구
8.1.1 이해 도구
8.1.2 평가 도구, 코드 복제 감지기, 척도 측정 도구
8.1.3 기술 부채 정량화와 시각화 도구
8.1.4 리팩토링 도구
8.1.5 실전에서 도구 적용
8.2 프로세스
8.2.1 리팩토링에서 직면하는 도전
8.2.2 리팩토링을 받아들이게 하기
8.2.3 IMPACT ? 리팩토링 프로세스 모델
8.2.4 기술 부채를 상환하는 리팩토링 우수 사례
8.3 사람
8.3.1 훈련
8.3.2 세미나와 워크숍
8.3.3 솔선수범

부록 A 소프트웨어 설계 원칙
A.1 계층 원칙
A.2 다양한 캡슐화 원칙
A.3 단일 책임 원칙
A.4 모듈화 원칙
A.5 비순환 의존성 원칙(ADP)
A.6 정보 은닉 원칙
A.7 추상화 원칙
A.8 캡슐화 원칙
A.9 DRY 원칙
A.10 KISS 원칙
A.11 LSP 원칙
A.12 OCP 원칙

부록 B 기술 부채를 상환하는 도구

부록 C 그림 표기법

부록 D 추천 도서
D.1 핵심 도서
D.2 리팩토링과 리엔지니어링
D.3 패턴과 안티패턴
D.4 기술 부채

부록 E 참고문헌

변화는 불가피하고 어렵다! 이것은 진리이며, 인생뿐만 아니라 소프트웨어에도 적용된다. 소프트웨어는 끊임없이 증가하는 사용자의 요청에 부응하려고 계속 진화한다. 동시에 소프트웨어의 무형적인 성질은 이런 끊임없는 변경을 관리하기 어렵게 한다. 보통 결과물은 형편없는 소프트웨어 품질*과 엄청난 기술 부채다.
책은 설계에서 악취를 찾아 해소하여 소프트웨어 품질을 높이고 기술 부채를 줄이는 방법을 알려 준다. “좋은 의사는 약을 알지만, 위대한 의사는 병을 안다.”라는 의학 부문에서 사용하는 표현을 차용하면, 우리의 접근 방법은 “좋은 설계자는 설계 해법을 알지만, 위대한 설계자는 설계의 문제점(악취), 악취가 발생한 원
인, 증명되고 건전한 설계 원칙을 적용하여 악취를 해소할 수 있는 방법을 이해하는 사람이다.”라는 철학에 근거를 둔다. 따라서 책의 목표는 더 나은 설계자로 여러분을 이끄는 데 있다. 설계에서 ‘질병’을 인식하고 이해하며 이를 적절히 다룰 수 있기에 결과적으로 소프트웨어 품질을 개선하여 기술 부채를 통제 하에 둘 수 있다.
- 저자서문 중에서