Refactoring - 리팩토링을 해야 할 때

리팩토링을 어떨 때 시작하고 어떨 때 그만둬야 할지 판단을 해야하는데, 그것은 사실 상 경험을 많이 해봐야 하는 부분일 것이다.

그냥 가볍게 보통 이럴 때 리팩토링을 어떻게 하고, 이럴 때에는 이렇게 하는게 좋구나... 이 정도만 생각하도록 하자.

1. 중복 코드

리팩토링을 꼭 해야 하는 상황은 중복 코드가 여러 곳에 있을 때이다. 이런 중복 코드는 하나로 통일을 해서 프로그램을 개선해야 한다. 

2. 장황한 메서드

최적의 상태로 장수하는 객체 프로그램을 보면 공통적으로 메서드의 길이가 짧다. 메서드의 길이가 길수록 이해하기 어렵다는 점은 많은 프로그래머들은 알고 있다. 이를 위해서 메서드를 과감하게 쪼개야 한다. 

메서드명은 기능 수행 방식이 아니라 목적(기능 자체)을 나타내는 이름으로 정해야 한다.

3. 방대한 클래스

기능이 지나치게 많은 클래스에는 보통 엄청난 수의 인스턴스 변수가 들어있다. 클래스에 인스턴스 변수가 많으면 중복 코드가 존재하기 마련이다. 클래스들을 추출하면 수많은 인스턴스 변수를 하나로 묶을 수 있다. 서로 연관된 변수를 골라서 클래스로 빼내면 된다. 

4. 과다한 매개변수

매개변수가 간결하다는 것은 장점이다. 매개변수가 길면 서로 일관성이 없어지거나 사용이 불편해지고, 더 많은 데이터가 필요해질 때마다 계속 수정해야 하기 때문에 그 매개변수들을 이해하기 힘들다. 웬만하면 객체를 넘기면 많은 문제가 해결 된다.

5. switch 문

객체지향 코드의 확연한 특징 중 하나는 switch ~ case 문이 비교적 적게 사용된다는 점이다. 

switch 문의 단점은 반드시 중복이 생긴다는 점이다. 같은 switch 문이 프로그램 곳곳에 있을 때가 많다. 그렇기 때문에 switch 문에 새 코드를 추가하려면 여기저기에 존재하는 switch 문을 전부 찾아서 수정해야 한다. 

이 문제를 해결하려면 객체지향 개념 중 하나인 다형성, 즉 재정의를 이용하는 것이다. 대부분의 switch 문은 고민할 필요없이 재정의로 바꿔야 한다. 

6. 인터페이스가 다른 대용 클래스

기능은 같은데 시그너처가 다른 메서드에는 메서드명 변경을 해야 한다. 클래스에 여전히 충분한 기능이 구현되어 있지 않기 때문에 대체로 이 방법만으로는 충분하지 않다. 프로토콜이 같아질 때까지 메서드 이동을 해서 기능을 해당 클래스로 옮겨야 한다. 단 코드를 너무 여러번 옮겨야 한다면 상위클래스 추출을 하면 된다.

7. 불필요한 주석

주석은 많이 사용할 수록 좋다. 하지만, 여기서부턴 이 기능, 여기서부턴 저 기능이라는 주석이 있다면 그것은 다른 메서드로 빼는 것이 좋다. 그 주석들은 불필요하다.

8. 변수명 수정

굳이 변수명을 수정하는 것이 왜 리팩토링이냐고 생각을 할 수도 있다. 하지만, 좋은 코드는 그것이 무슨 기능을 하는지 분명히 들어나야하는데, 코드의 기능을 분명히 드러내는 열쇠가 바로 직관적인 변수명이다.

9. 임시 변수 없애기

임시 변수로 인해 문제가 생길 수 있다. 임시 변수는 자체 루틴 안에서만 효력이 있다 보니, 점점 더 많은 임시변수를 사용하게 되어 코드가 복잡해지기 쉽다. 그렇기 때문에 임시 변수는 질의 메서드(Query Method)로 변경해주는 것이 좋다.

10. switch ~ case 문의 조건문 확인

만약 다른 객체의 속성을 switch 문의 인자로 사용하고 있다면 나쁜 방법이다. switch 문의 인자로는 타 객체 데이터를 사용하지 말고 자신의 데이터를 사용해야 한다.