추가 적립 안내

『소프트웨어 악취를 제거하는 리팩토링』은 소프트웨어 개발자가 설계 원칙을 어길 때 어떤 악취가 발생하는지를 파악하여 설계 과정에서 직면한 다양한 도전을 탐구한다. 코드 수준보다 추상화 단계가 높은 설계 수준에서 발생하는 다양한 악취, 악취를 일으킨 원인과 해소 방법, 악취가 영향을 미치는 핵심 품질 속성을 추상화, 캡슐화, 모듈화, 계층이라는 네 가지 대 범주에 속한 25가지 항목으로 나눠서 소개했다.

이 책은 코드 수준보다 추상화 단계가 높은 설계 수준에서 발생하는 다양한 악취, 악취를 일으킨 원인과 해소 방법, 악취가 영향을 미치는 핵심 품질 속성을 추상화, 캡슐화, 모듈화, 계층이라는 네 가지 대 범주에 속한 25가지 항목으로 나눠서 소개한다.
소프트웨어 개발자가 설계 원칙을 어길 때 어떤 악취가 발생하는지를 파악하여 설계 과정에서 직면한 다양한 도전을 탐구한다. 단순히 악취 목록만 나열하는 이론적인 접근 방법에서 벗어나 다양한 일화와 실제 예제를 중심으로 소프트웨어 개발 현장에서 어떤 문제가 발생하는지 소개한다. 그리고 구체적인 방식으로 경험담을 기술하여 이것을 어떻게 해결할 수 있는지 보여 줌으로써 좋은 설계와 나쁜 설계가 무엇인지 제대로 알려 준다.

그래디 부치(UML 창시자, IBM 펠로우)
“기술 부채라는 개념은 시스템을 짓누르는 힘을 이해하는 중심이다. 종종 시스템이 스트레스를 받는 장소, 방법, 이유를 설명하기 때문이다. 이 책은 기쁘게도 기술 부채와 실천 가능한 수단으로서 부채를 해소하는 리팩토링에 초점을 맞추고 있다.”

디오미디스 스피넬리스(작가)
“소프트웨어 진화는 필연적으로 기술 부채를 누적하게 만든다. 결국 유지 보수가 점점 고통스럽고 비싸게 된다. 저자들은 광범위한 경험을 토대로 소프트웨어에 따라다니는 주요 설계 문제(악취)를 범주로 나누고, 적절한 리팩토링으로 어떻게 악취를 제거할 수 있는지 알기 쉽게 설명한다.”

스테판 뒤카스(소프트웨어 분석 전문가)
“이 책은 정말 훌륭하며 전문가들을 위한 또 다른 이정표다. 이 책으로부터 상당히 많은 내용을 배우며 즐기리라 확신한다.”

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 참고문헌

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