ch03

⬅️ 2장 | 4장 ➡️

3장 코드에서 나는 악취

• 3.1 기이한 이름
• 3.2 중복 코드
• 3.3 긴 함수
• 3.4 긴 매개변수 목록
• 3.5 전역 데이터
• 3.6 가변 데이터
• 3.7 뒤엉킨 변경
• 3.8 산탄총 수술
• 3.9 기능 편애
• 3.10 데이터 뭉치
• 3.11 기본형 집착
• 3.12 반복되는 switch문
• 3.13 반복문
• 3.14 성의없는 요소
• 3.15 추측성 일반화
• 3.16 임시 필드
• 3.17 메시지 체인
• 3.18 중개자
• 3.19 내부자 거래
• 3.20 거대한 클래스
• 3.21 서로 다른 인터페이스의 대안 클래스들
• 3.22 데이터 클래스
• 3.23 상속 포기
• 3.24 주석

Note

'코드에서 나는 악취' 챕터는 다음 질문을 중심으로 읽어나가시면 좋습니다.

1. 언제 리팩터링해야 하는가
2. 어떤 코드가 리팩터링이 필요한가

각 악취에 맞는 리팩터링 기법은 6장 이후로 자세히 다뤄질 예정이니 가볍게 읽고 넘어가시면 됩니다.

113p

냄새나면 당장 갈아라. -켄트 벡 할머니의 육아 원칙 (ㅋㅋ)

당시 켄트는 갓 태어난 딸을 돌보느라 기저귀 냄새에 상당히 민감해했던 것으로 기억한다. 그 때문인지 리펙터링할 시점을 설명하는 데 냄새란 표현을 사용했다.

114p

어떤 리펙터링 기법을 적용할지 모르겠다면 이 장의 내용과 부록 B를 참고해서 감을 잡기 바란다. 먼저 이 장을 (혹은 부록 B를) 읽고 코드가 풍기는 냄새(악취)가 무엇인지 찾자. 그런 다음 우리가 해법으로 제시한 리팩터링 기법을 이 책의 6~12장에서 찾아 읽고 그 냄새를 없애는데 도움이 될지 생각해본다.

3.1 기이한 이름

114p

코드를 명료하게 표현하는 데 가장 중요한 요소 하나는 바로 '이름'이다. 그래서 함수, 모듈, 변수, 클래스 등은 그 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 엄청나게 신경 써서 이름을 지어야 한다.

마땅한 이름이 떠오르지 않는다면 설계에 더 근본적인 문제가 숨어 있을 가능성이 높다.

3.2 중복 코드

115p

코드가 중복되면 각각을 볼 때마다 서로 차이점은 없는지 주의 깊게 살펴봐야 하는 부담이 생긴다. 그중 하나를 변경할 때는 다른 비슷한 코드들도 모두 살펴보고 적절히 수정해야 한다.

3.3 긴 함수

115p

간접 호출의 효과, 즉 코드를 이해하고, 공유하고, 선택하기 쉬워진다는 장점은 함수를 짧게 구성할 때 나오는 것이다.

짧은 함수로 구성된 코드를 이해하기 쉽게 만드는 가장 확실한 방법은 좋은 이름이다. 함수 이름을 잘 지어두면 본문 코드를 볼 이유가 사라진다.

116p

함수 본문에는 원래 주석으로 설명하려던 코드가 담기고, 함수 이름은 동작 방식이 아닌 '의도'가 드러나게 짓는다.

단, 함수 이름에 코드의 목적을 드러내야 한다.

즉, '무엇을 하는지'를 코드가 잘 설명해주지 못할수록 함수로 만드는 게 유리하다.

그렇다면 추출할 코드 덩어리는 어떻게 찾아낼까? 한 가지 좋은 방법은 주석을 참고하는 것이다. 주석은 코드만으로는 목적을 이해하기 어려운 부분에 달려 있는 경우가 많다. 이런 주석을 찾으면 주석이 설명하는 코드와 함께 함수로 빼내고, 함수 이름은 주석 내용을 토대로 짓는다. 코드가 단 한 줄이어도 따로 설명할 필요가 있다면 함수로 추출하는 게 좋다.

3.4 긴 매개변수 목록

117p

매개변수 목록이 길어지면 그 자체로 이해하기 어려울 때가 많았다.

3.5 전역 데이터

117p

전역 데이터는 코드베이스 어디에서든 건드릴 수 있고 값을 누가 바꿨는지 찾아낼 메커니즘이 없다는 게 문제다.

118p

이런 데이터를 함수로 감싸는 것만으로도 데이터를 수정하는 부분을 쉽게 찾을 수 있고 접근을 통제할 수 있게 된다.

3.6 가변 데이터

118p

데이터를 변경했더니 예상치 못한 결과나 골치 아픈 버그로 이어지는 경우가 종종 있다.

함수형 프로그래밍에서는 데이터는 절대 변하지 않고, 데이터를 변경하려면 반드시 (원래 데이터는 그대로 둔 채) 변경하려는 값에 해당하는 복사본을 만들어서 반환한다는 개념을 기본으로 삼고 있다.

💡 의견 - 함수형 프로그래밍은 순수 함수로 구성하고 오류를 방지할 수 있어 좋았습니다.

3.7 뒤엉킨 변경

119p

코드를 수정할 때는 시스템에서 고쳐야 할 딱 한 군데를 찾아서 그 부분만 수정할 수 있기를 바란다.

뒤엉킨 변경은 단일 책임 원칙 (Single Responsibility Principle, SRP)이 제대로 지켜지지 않을 때 나타난다.

💡 의견 - 클린코드를 읽어보았는데, SRP를 강조하는 부분이 리펙터링 책 내용과 동일하게 강조되는 부분으로 보여집니다.

3.8 산탄총 수술

120p

이 냄새는 코드를 변경할 때마다 자잘하게 수정해야 하는 클래스가 많을 때 풍긴다.

3.9 기능 편애

121p

프로그램을 모듈화할 때는 코드를 여러 영역으로 나눈 뒤 영역 안에서 이뤄지는 상호작용은 최대한 늘리고 영역 사이에서 이뤄지는 상호작용은 최소로 줄이는 데 주력한다. 기능 편애는 흔히 어떤 함수가 자기가 속한 모듈의 함수나 데이터보다 다른 모듈의 함수나 데이터와 상호작용 할 일이 더 많을 때 풍기는 냄새다.

122p

가장 기본이 되는 원칙은 '함께 변경할 대상을 한데 모으는 것'이다.

3.10 데이터 뭉치

122p

몰려다니는 데이터 뭉치는 보금자리를 따로 마련해줘야 마땅하다.

클래스를 이용하면 좋은 향기를 흩뿌릴 기회가 생기기 때문이다.

💡 의견 - 리액트에서 함수 컴포넌트와 훅만 다루다보니 클래스를 다룰 기회가 많지 않았는데 책에서 언급하는 기법들을 클래스가 아닌 함수에도 잘 적용할 수 있을지 궁금합니다.

3.11 기본형 집착

123p

한편 프로그래머 중에는 자신에게 주어진 문제에 딱 맞는 기초 타입(화폐, 좌표, 구간 등)을 직접 정의하기를 몹시 꺼리는 사람이 많다.

자주 함께 몰려다니는 기본형 그룹도 데이터 뭉치다.

3.12 반복되는 switch문

124p

중복된 switch문이 문제가 되는 이유는 조건절을 하나 추가할 때마다 다른 switch문들도 모두 찾아서 함께 수정해야 하기 때문이다. 이럴 때 다형성은 반복된 switch문이 내뿜는 사악한 기운을 제압하여 코드베이스를 최신 스타일로 바꿔주는 세련된 무기인 셈이다.

3.13 반복문

124p

지금은 일급 함수 (first-class function)를 지원하는 언어가 많아졌기 때문에 반복문을 파이프라인으로 바꾸기를 적용해서 시대에 걸맞지 않은 반복문을 제거할 수 있게 됐다.

💡 의견

• filter(), map() 같은 메서드가 파이프라인 연산인지 모르고 있다가 이번 기회에 알게 되어 좋았습니다.
• 일급 함수가 함수형 프로그래밍에서 중요하게 생각되는 개념이에요!

3.14 성의없는 요소

125p

본문 코드를 그대로 쓰는 것과 진배없는 함수도 있고, 실질적으로 메서드가 하나뿐인 클래스도 있다.

이런 프로그램 요소는 고이 보내드리는 게 좋다.

3.15 추측성 일반화

125p

이 냄새는 '나중에 필요할 거야'라는 생각으로 당장은 필요 없는 모든 종류의 후킹hooking 포인트와 특이 케이스 처리 로직을 작성해둔 코드에서 풍긴다.

3.16 임시 필드

126p

객체를 가져올 때는 당연히 모든 필드가 채워져 있으리라 기대하는 게 보통이라, 이렇게 임시 필드를 갖도록 작성하면 코드를 이해하기 어렵다. 그래서 사용자는 쓰이지 않는 것처럼 보이는 필드가 존재하는 이유를 파악하느라 머리를 싸매게 된다.

3.17 메시지 체인

126p

메시지 체인은 클라이언트가 한 객체를 통해 다른 객체를 얻은 뒤 방금 얻은 객체에 또 다른 객체를 요청하는 식으로, 다른 객체를 요청하는 작업이 연쇄적으로 이어지는 코드를 말한다.

이는 클라이언트가 객체 내비게이션 구조에 종속됐음을 의미한다. 그래서 내비게이션 중간 단계를 수정하면 클라이언트 코드도 수정해야 한다.

💡 의견 - 이 부분은 이해가 잘 안가는데, 7.7장에서 이 내용을 어떻게 다룰지 궁금해요!

3.18 중개자

127p

객체의 대표적인 기능 하나로, 외부로부터 세부사항을 숨겨주는 캡슐화encapsulation가 있다. 캡슐화하는 과정에서는 위임delegation이 자주 활용된다.

128p

하지만 지나치면 문제가 된다. 클래스가 제공하는 메서드 중 절반이 다른 클래스에 구현을 위임하고 있다면 어떤가?

3.19 내부자 거래

128p

모듈 사이의 데이터 거래가 많으면 결합도coupling가 높아진다고 투덜댄다. 일이 돌아가게 하려면 거래가 이뤄질 수 밖에 없지만, 그 양을 최소로 줄이고 모두 투명하게 처리해야 한다.

3.20 거대한 클래스

128p

한 클래스가 너무 많은 일을 하려다 보면 필드 수가 상당히 늘어난다. 그리고 클래스에 필드가 너무 많으면 중복 코드가 생기기 쉽다.

129p

필드가 너무 많은 클래스와 마찬가지로 코드량이 너무 많은 클래스도 중복 코드와 혼동을 일으킬 여지가 크다.

3.21 서로 다른 인터페이스의 대안 클래스들

129p

클래스를 사용할 때의 큰 장점은 필요에 따라 언제든 다른 클래스로 교체할 수 있다는 것이다. 단, 교체하려면 인터페이스가 같아야 한다.

3.22 데이터 클래스

130p

데이터 클래스란 데이터 필드와 게터/세터 메서드로만 구성된 클래스를 말한다.

한편, 데이터 클래스는 필요한 동작이 엉뚱한 곳에 정의돼 있다는 신호일 수 있다. 이런 경우라면 클라이언트 코드를 데이터 클래스로 옮기기만 해도 대폭 개선된다.

3.23 상속 포기

131p

그래서 상속을 포기할 시 혼란과 문제가 생긴다면 앞에서 설명한 예전 방식을 따른다.

상속 포기 냄새는 서브클래스가 부모의 동작은 필요로하지만 인터페이스는 따르고 싶지 않을 때 특히 심하게 난다.

이럴 때는 서브클래스를 위임으로 바꾸기나 슈퍼클래스를 위임으로 바꾸기를 활용해서 아예 상속 메커니즘에서 벗어나보자.

3.24 주석

131p

주석은 악취가 아닌 향기를 입힌다. 문제는 주석을 탈취제처럼 사용하는 데 있다. 주석이 장황하게 달린 원인이 코드를 잘못 작성했기 때문인 경우가 의외로 많다.

주석을 남겨야겠다는 생각이 들면, 가장 먼저 주석이 필요 없는 코드로 리팩터링해본다.

💡 의견

• 프로그래밍을 시작했을 때 주석을 지나치게 남긴 기억이 나서 반성하게 되네요.
• 군더더기 없이 잘 작성된 주석은 코드를 이해할 때 한 줄기 빛이 됩니다.

⬅️ 2장 | ⬆️ 위로 | 4장 ➡️