[JAVA] 리팩토링의 정의

바쁘게 진행되던 연구실 업무에 잠깐의 여유가 생겼다.

뭘 살펴볼까 고민하던 중 리팩토링이 무엇인지 감은 잡아봐야겠다는 생각에 무작정 책을 펼치게 되었다.

연구실에서 아주 오래전에 구매한 책으로 아직 아무도 안 본 것 같았다.

책의 저자는 일본인 히로시 유키로 전에 본 디자인 패턴의 저자이기도 하다. 이해하기 쉽게 책을 잘쓰는 듯 싶다.

그럼 이제 리팩토링이 무엇인지, 어떠한 경우에 사용하는지, 어떤 장점을 가지는지 살펴보도록 하자.


리팩토링
리팩토링이란 외부에서 본 프로그램의 동작은 변하지 않고 프로그램 내부의 구조 개선을 통해 다음과 같은 장점을 가진다.

버그를 찾아내기 쉽게 한다
기능을 추가하기 쉽게 한다
리뷰하는 것이 쉬워진다 
 
이미 존재하는 코드를 개선하는 것이므로 위의 장점은 당연히 따라온다고 볼 수 있다.


그렇다면 리팩토링을 무조건 적용할 수 있는 것일까.

당연히 무조건 적용할 수는 없다. 위에 작성한 것과 같이 이미 존재하는 코드를 개선하는 것이기에 코드가 완성되지 않은 경우

당연히 적용할 수 없고, 개발 일정이 얼마 남지않은 경우 더더욱 적용할 수 없다.



그럼 이번엔 리팩토링의 대상이 되는 코드를 찾아낼 수 있는 기준을 살펴보도록 하자.

해당 책에서는 '코드의 악취'라는 것이 바로 리팩토링이 필요한 부분이라고 소개하고 있다.

마틴 파울러가 쓴 책에서 22가지 경우의 '코드의 악취'를 소개하지만 너무 많기 때문에

이 책의 저자는 그 중에서도 6가지를 중점적으로 소개했다.
 
겹쳐있다 
여러 곳에 비슷한 코드가 산재해 있는 상태를 의미한다.

너무 길다
클래스 혹은 메소드가 너무 긴 상태를 의미한다.

너무 많다
클래스 추출을 지나치게 많이해서 클래스가 너무 많은 상태를 의미한다.
 
이름이 어울리지 않는다
변수,필드,메소드,클래스,패키지 명 등의 이름이 적절한 정보를 전달하지 못하는 상태를 의미한다.
 
지나치게 공개했다
무분별하게 public을 사용한 상태를 의미한다.
 
객체지향적이지 않다 
instanceOf, switch, if 등만을 많이 사용한 상태를 의미한다.


위와 같은 '코드의 악취'는 리팩토링이 요구되는 코드를 구별할 수 있는 기준이기는 하나 무조건 적용해야 하는 것은 아니다.

단지 검토의 대상이 되는 것이므로 주의깊게 살펴보고 진행토록 하자.


마지막으로 리팩토링을 진행하는 데 있어 가장 중요한 원칙 하나를 살펴보자.

책에서 'Step by Step'이라고 소개하는 이 원칙은 리팩토링을 진행시 한번에 무조건 하나씩만 수정하는 것을 의미한다.

다시 되돌아와야 할 경우도 존재하고, 여러가지 수정을 동시에 진행하다보면 코드가 꼬일 수도 있기 때문에

무조건 이 원칙을 지켜 리팩토링을 수행할 수 있도록 하자.


지금까지 리팩토링의 기본 정의와 장점, 대상이 되는 기준 등에 대해서 살펴보았다.

이를 통해 리팩토링이 무엇인지 대충 감은 잡을 수 있었다. 상세 내용을 살펴보고 리팩토링에 더 접근해 보도록 하겠다.