[리팩토링] 제1장 맛보기 예제

리팩토링 제 1장 맛보기 예제

설계가 조잡한 시스템은 어디를 수정해야 하는지 찾기 힘들어 수정도 어렵다. 수정할 위치를 찾기 힘들면 개발자가 실수할 가능성이 높아져서 버그가 생긴다. 코드를 복사해서 붙이게 되면 나중에 그 코드를 수정할 때마다 계속 같은 부분을 복사해서 붙여야 하기 때문에 아주 번거롭고 에러가 생길 수도 있다. 사용 기간이 길고 추후 수정해야 할 가능성이 있는 프로그램은 복사해서 붙이는 과정에서 큰 문제가 생길 수 있다. 그래서 매번 코드를 복사해서 붙일 필요가 없게 프로그램을 개선해야 한다. 프로그램이 당장은 문제가 없을지 몰라도 나중엔 사용자가 요구한 기능을 수정하기 힘들어서 애먹을 것이다. 이 상황이 리팩토링해야 할 시점이다.

 

프로그램에 기능을 추가해야 하는데 코드 구조가 조잡해서 그 기능을 추가하기 힘들다면, 우선 리팩토링을 실시해서 기능을 추가하기 쉽게 만든 후 그 기능을 추가하자.

리팩토링 첫 단계

리팩토링 작업의 첫단계는 리팩토링할 코드 부분에 대한 신뢰도 높은 각종 테스트를 작성하는 것이다. 사람인 이상 실수할 수 있기 때문에 신뢰도 높은 테스트 작성은 필수다. 코드 수정 중에 버그가 생겼는지 알기 위해 테스트를 이용하는 것이다. 적절한 테스트 코드를 작성하는 것은 리팩토링의 기본이다. 여러 테스트를 일일이 비교 검사하지 않으려면 테스트는 반드시 자체검사로 만들어야 한다.

 

리팩토링하기 전에 반드시 신뢰도 높은 테스트 세트를 준비하자. 테스트는 반드시 자체검사가 되게 작성한다.

메서드 분해와 기능 재분배

긴 메서드는 작은 부분들로 쪼갤 수 있는지 검토하자. 코드를 잘게 쪼개면 관리도 편하고 다른 코드와 연동하거나 이리저리 옮기기도 쉽다. 긴 메서드를 분해해서 각 부분을 알맞은 클래스로 옮기자. 메서드를 추출할 때 잘못하면 버그가 생길 수 있으니 리팩토링을 적용하기 전에, 메서드 안에서만 효력이 있는 모든 지역변수와 매개변수에 해당하는 부분을 살펴봐야 한다.

 

좋은 코드는 그것이 무슨 기능을 하는지 분명히 드러나야 하는데, 코드의 기능을 분명히 드러내는 열쇠가 바로 직관적인 변수명이다. 명확성을 높이기 위한 이름 수정에 인색하게 굴지 말자.

 

컴퓨터가 인식 가능한 코드는 바보라도 작성할 수 있지만, 인간이 이해할 수 있는 코드는 실력 있는 개발자만 작성할 수 있다.

메서드를 추출한 후에 메서드가 잘못된 객체에 속해 있는건 아닌지 확인하자. 메서드는 대체로 자신이 사용하는 데이터와 같은 객체에 들어 있어야 한다.

 

메서드 내에 임시변수는 최대한 없애는 것이 좋다. 임시변수가 많으면 불필요하게 많은 매개변수를 전달하게 되는 문제가 생긴다. 임시변수는 특히 긴 메서드 안에서 알게 모르게 늘어나고, 성능을 저하시킨다. 또한 임시변수는 자체 루틴 안에서만 효력이 있다 보니, 점점 더 많은 임시변수를 사용하게 되어 코드가 복잡해지기 쉽다. 그러므로 할 수 있다면 임시변수를 메서드 호출로 전환해서 사용하자.

 

리팩토링하는 과정에서 성능보다 설계를 우선하자. 성능 개선은 최적화 단계에서 걱정해도 늦지 않다.

고찰

리팩토링 기법을 적용하면 기능 분배가 균등해지고 코드 유지보수도 쉬워진다. 이번 장에 가장 중요한 교훈은

간단한 수정 후 테스트를 리듬처럼 반복해야 한다는 것이다.

이 리듬을 지킬 때만이 리팩토링을 빠르고 안정적으로 완료할 수 있다.