[리팩토링 2판] 3장. 코드에서 나는 악취 (10월 12일)

리팩토링을 언제 멈춰야 하는지를 판단하는 정확한 기준은 제시하지 않을 것이다.

왜냐하면 숙련된 사람의 직관만큼 정확한 기준은 없기 때문이다.

 

아래의 소제목들은 피해야 하는 것들이다.

기이한 이름

이름만 보고도 무슨 일을 하고 어떻게 사용해야 하는지 명확히 할 수 있도록 짓는다.

 

이름만 보고도 동작을 유추할 수 있다면 코드 파악하는 시간을 많이 줄일 수 있다.

그리고 코드를 읽는 사람이 코드에 더 신뢰성을 가질 수도 있다.

 

중복 코드

똑같은 코드 구조가 여러 곳에서 반복된다면 하나로 통합하자.

 

중복 코드는 그 순간 편하겠지만 수정으로 들어가는 순간 지옥길 시작이다..

 

긴 함수

긴 함수보다 짧은 함수가 코드를 이해하는데 더욱 도움이 된다.

짧은 함수로 구성된 코드를 이해하기 쉽게 만드는 가장 확실한 방법은 좋은 이름이다.

 

 

본문을 읽지 않고 이름만 보아도 어떤 일을 하는지 알 수 있다.

 

주석을 달아야 할 만한 부분은 함수로 만든다.

주석으로 설명하려던 것은 코드로 만들고, 함수 이름은 동작 방식이 아닌 의도를 나타낸다.

심지어 원래 코드보다 길어지더라도 함수로 뽑는다. 단, 이름에 코드의 목적을 드러내야 한다.

 

결국 함수도 이름을 잘 만들어야 한다.

주석이 필요하다 === 함수를 더 쪼개야 한다.

 

기능 편애

코드를 여러 영역으로 나눈 뒤 영역 안에서 이뤄지는 상호작용은 최대한 늘리고 영역 사이에서 이뤄지는 상호작용은 최소로 줄이는데 주력한다.

 

응집도와 결합도를 여기서 나타내는 것 같다.

 

반복되는 switch문

switch문은 모조리 조건부 로직을 다형성으로 바꾸자.

중복된 switch문이 문제가 되는 이유는 조건절을 하나 추가할 때마다 다른 switch문들도 모두 찾아서 수정해야 하기 때문이다.

 

중복된 switch문이 있다면 함수로 만들면 되지 않을까... 아직 다형성이 무엇인지 잘 모르겠다.

 

반복문

반복문을 파이프라인으로 바꾸기

필터나 맵 같은 파이프라인 연산을 사용하면 어떻게 처리되는지 쉽게 파악할 수 있다.

 

성의 없는 요소

원래는 풍성했던 클래스가 리팩토링을 거치면서 역할이 줄어들었을 수도 있다.

이 제거 작업은 함수 인라인 화하기, 클래스 인라인 하기로 처리한다. 상속을 사용했다면 계층 합치기를 적용한다.

 

추측성 일반화

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

미리 작성한 부분은 실제로 사용된다면 다행이지만 그렇지 않으면 쓸데없는 낭비이다. 당장 눈앞에서 치워버리자

 

너무 미래를 생각해서 개발하다 보면 쓸데없는 코드들이 많이 늘어나는 것은 사실이다.

이것도 어느 정도 개인의 감에 맡겨야 할 것 같다...

 

메시지 체인

한 객체를 통해 다른 객체를 얻은 뒤 방금 얻은 객체에 또 다른 객체를 요청하는 식으로 객체 내비게이션 구조에 종속됐음을 의미한다.

 

주석

특정 코드 블록이 하는 일에 주석을 남기고 싶다면 함수 추출하기

이미 추출되어 있는 함수임에도 여전히 설명이 필요하다면 함수 선언 바꾸기

시스템이 동작하기 위한 선행조건을 명시하고 싶다면 어섬션 추가하기

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

 

리팩토링 책에서는 주석이 악취가 아닌 향기를 입힌다고 나온다.

악취가 심한 코드를 리팩토링으로 걷어내고 나니 필요 없는 주석이 대부분이었기 때문이다.

이렇게 주석을 사용하기 전에 코드를 한번 더 생각해보는 것이 좋을 것 같다.