코드의 구린내 - 1

.

<구린 게 있으면 그 부분을 바로 잡으세요>

리팩토링의 중요성과 효과는 인정하겠는데 대체 언제 리팩토링 해야하지??

소프트웨어는 과학이 아니라 공학이다. 아트라고도 할만큼 개발자나 기획자의 주관에 따라 쉽게 바뀌기 마련이다.

리팩토링의 시점은 정확하게 정해져 있는 것은 아니다. 단지 일반적으로 어느 문제에 대해 리팩토링하는 것이 더 좋다는 가이드가 있을 뿐이다.

사람의 직감이 나설 때다. 그러나 우리는 초짜 프로그래머이므로 고수들이 알려주는 패턴부터 머릿속에 집어넣자. 연습만이 살 길이다.

.

.

1. 중복코드(Duplicated Code) - 구린내의 제왕

- 중복코드를 제거하려면...

- 메소드추출(Extract Method) 

- 메소드 상향(Pull Up Method)

- 템플릿 메소드 형성(Form Template Method)

- 알고리즘 전환(Substitute Algorithm)

- 주변 메소드 추출(Extract Surrounding Method)

- 클래스 추출(Extract Class)

- 모듈 추출(Extract Module)

-> 자세한 방법은 다음에 알아보자.

.

.

2. 장황한 메소드(Long Method) - 길고도 긴 메소드

- 이는 메소드를 쪼갬으로서 해결한다.

- 메소드 이름은 목적을 나타내는 이름으로 정한다. -> 그 코드의 의도를 잘 반영하는 것

- 메소드의 길이를 줄이기 위해 쪼개는 과정에서 매개변수와 임시변수가 많으면 일이 쉽지 않다. 이 때에는 변수들을 객체로 바꿔 넘기는 등의 기법을 적용한다.

.

.

3. 방대한 클래스(Large Class)

- 한 클래스의 덩치가 크다면 중복코드를 의심해 봐야한다.

- 서로 연관된 변수를 골라 클래스로 빼낼 수 있다. -> 일부 변수의 접두어와 접미어가 같다면 하나의 클래스가 될 수 있다.

- 하위 클래스 또는 모듈, 위에서와 같이 또다른 클래스로 추출할 수 있다.

.

.

4. 과다한 매개변수(Long Parameter List)

- 과다한 매개변수는 유지보수에 결코 좋지 않다.

- 알아보기가 쉽지 않고, 개발자가 실수할 여지가 많다.

- 나는 매개변수가 3개 이상인 메소드가 정말 싫다.

- 2개까지는 봐줄만하다.

.

.

5. 수정의 산발(Divergent Change)

- 하나의 수정에 대해서 하나의 클래스 혹은 모듈만 변경해야한다.

- 그렇지 않다면 개발자는 혼란에 빠질 것이다.

.

.

6. 기능의 산재(Shotgun Surgery)

- 기능의 산재는 수정의 산발과 비슷하지만 정 반대다. 

- 수정의 산발은 한 클래스에 여러 수정이 발생하는 문제고, 기능의 산재는 하나의 수정으로 여러 클래스가 바뀌게 되는 문제다.

- 둘 중 어느 것이든 수정과 클래스가 일대일 대응되게 깔끔히 정리해야 한다.

- 라고 책에 씌여있지만, 그저 혼란스럽다.

- 어쨌든 마지막 글귀처럼 수정&변경으로 인한 여파는 한 곳으로 모으자.(혹은 최소화하자)

.

.

.