들어가기 전에
이번 장에서는 리팩토링의 기준에 대해 설명합니다. 저자는 경험에 따른 숙련된 사람의 직관이 정확한 기준이라고 합니다. 그래서 이런 직관을 키워줄 몇 가지 가이드 라인을 제시합니다.
1. 기이한 이름
이름 짓기는 프로그래밍에서 가장 어렵기로 손꼽히는 두 가지 중 하나입니다. 그 때문에 가장 많이 사용하는 리팩터링도 함수 선언 바꾸기, 변수 이름 바꾸기, 필드 이름 바꾸기처럼 이름을 바꾸는 리팩터링들입니다. 이름 짓기는 "Clean Code"에서도 굉장히 강조하는 부분입니다.
2. 중복 코드
한 클래스에 딸린 두 메서드가 똑같은 표현식을 사용하는 경우, 함수 추출하기를 써서 양쪽 모두 추출된 메서드를 호출하게 하면 됩니다. 코드가 완전히 같지 않고 비슷하다면 문장 슬라이스를 하여 비슷한 부분을 모아 함수로 추출하여 더 쉽게 적용 가능합니다.
3. 긴 함수
저자의 오랜 경험에 비춰보면 오랜 기간 잘 활용되는 프로그램들은 하나같이 짧은 함수로 구성됐다고 합니다. 코드가 끝없이 위임하는 방식으로 작성되어 있습니다. 하지만 이런 간접 호출의 효과는 코드를 이해하기 쉽게 하고 공유하기 쉽습니다.
여기서 중요한 점은 짧은 함수로 구성된 코드를 이해하기 쉽게 만드는 가장 확실한 방법은 좋은 이름입니다. 함수 이름을 잘 지으면 본문 코드를 볼 이유가 없습니다.
주석을 달아야 할 만한 부분은 무조건 함수로 만들어야 합니다. 그 함수 본문에는 원래 주석으로 설명하려던 코드가 담기고, 함수 이름은 동작 방식이 아닌 의도가 드러나게 짓습니다.
함수를 짧게 하는 방식의 99%는 함수 추출하기 입니다. 코드 덩어리를 찾아 함수로 추출하는 방식입니다.
4. 긴 매개변수 목록
프로그래밍 초기에는 함수에 필요한 것들은 모두 매개변수로 전달하라고 배웠습니다. 그래야 암적인 전역 데이터가 늘어나는 사태를 막을 수 있기 때문입니다. 매개변수가 많아지면 이해하기 어려울 때가 많습니다.
종종 다른 매개변수에서 값을 얻어올 수 있는 매개변수가 있을 수 있으면 매개변수를 질의 함수로 바꿔 임시 변수의 수를 줄일 수 있습니다. 또한 매개변수 객체 만들기와 객체 통째로 넘기기로는 매개변수의 수를 줄일 수 있습니다.
5. 전역 데이터
전역 데이터는 코드베이스 어디에서든 건드릴 수 있고 값을 누가 바꿨는지 찾아낼 메커니즘이 없다는 게 문제입니다. 문제가 발생해도 어느 코드가 그 값을 바꿨는지 찾기 어렵기 때문에 최악이라고 할 수 있습니다.
이를 해결하기 위해 변수를 캡슐화합니다. 전역 데이터를 클래스로 래핑하여 접근 범위를 최소로 줄입니다.
6. 가변 데이터
전역 데이터 문제의 해결법처럼 변수 캡슐화를 통해 정해놓은 함수를 거쳐야만 값을 수정할 수 있도록 하면 값이 어떻게 수정되는지 감시하거나 코드를 개선하기 쉽습니다.
가변 변수의 유효 범위와 문제 발생은 밀접한 관계가 있습니다. 가변 변수의 유효 범위가 작을 경우 큰 문제가 발생할 확률이 낮지만 유효 범위가 클수록 큰 문제가 될 확률이 높아집니다. 이럴 경우 클래스로 묶거나 여러 함수를 변환 함수로 묶어 유효 범위를 제한합니다.
7. 뒤엉킨 변경
기능을 추가할 때마다 함수의 변경이 있어야 한다면 뒤엉킨 변경 문제가 존재한다는 것입니다. 개발 초기에 맥락 사이의 경계를 명확히 나누기 어렵고 시스템 기능이 중간에 변경되면서 이 경계도 끊임없이 움직입니다.
이럴 경우 단계를 쪼개어 해결할 수 있습니다. 각 맥락에 해당하는 적당한 모듈들을 만들어서 관련 함수들을 모읍니다. 리허면 처리 과정이 맥락별로 구분되어 수정이 필요한 경우 쉽고 빠르게 수정가능합니다.
8. 산탄총 수술
위 7번인 뒤엉킨 변경과 반대의 경우입니다. 코드를 변경할 때마다 부수적인 코드를 자잘하게 수정해야하는 클래스가 많을 때 발생합니다. 이런 경우 함수를 옮겨 모으고 필드를 옮겨 모아 클래스로 묶어 해결 가능합니다.
