본 내용은 마틴 파울러의 Refactoring 2판을 토대로 작성되었습니다.
코드에서 나는 악취
- 적용 방법을 아는 것과 제때 적용할 줄 아는 것은 다름
- 리팩터링을 언제 해야 하는지에 대해서는 명확하게 정립된 규칙이 없음
- 리팩터링이 절실한 코드들에 일정한 패턴이 있음
- 코드가 풍기는 냄새(악취)가 무엇인지 찾자
기이한 이름
- 코드는 단순하고 명료하게 작성
- 코드를 명료하게 표현하는 데 가장 중요한 요소 하나는 이름
- 함수, 모듈, 변수, 클래스 등은 그 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 명확하게 알 수 있도록 엄청나게 신경 써서 이름을 지을 것
- 가장 많이 사용하는 리팩터링도 아래와 같은 이름을 바꾸는 리팩터링임
- 함수 선언 바꾸기
- 변수 이름 바꾸기
- 필드 이름 바꾸기
- 이름만 잘 지어도 나중에 문맥을 파악하느라 헤매는 시간을 절약할 수 있음
- 만약, 마땅한 이름이 떠오르지 않는 다면 설계에 더 근본적인 문제가 숨어 있을 가능성이 높음
- 혼란스러운 이름을 잘 정리하다 보면 코드가 훨씬 간결해질 때가 많음
중복 코드
- 똑같은 코드 구조가 여러 곳에서 반복된다면 하나로 통합하여 더 나은 프로그램을 만들 수 있음
- 코드가 중복되면 각각을 볼 때마다 서로 차이점은 없는지 주의 깊게 살펴봐야 하는 부담이 생김
- 하나를 변경할 때는 다른 비슷한 코드들도 모두 살펴보고 적절히 수정해야 함
- ex) 한 클래스에 딸린 두 메서드가 똑같은 표현식을 사용하는 경우
- 이럴 때는 함수 추출하기를 사용하여 양쪽 모두 추출된 메서드를 호출하게 바꾸면 됨
- 코드가 비슷하기는 하지만 완전히 똑같지는 않다면, 문장 슬라이드하기로 비슷한 부분을 한 곳에 모아 추출하기를 더 쉽게 적용할 수 있는지 살펴보기
- 같은 부모로부터 파생된 서브 클래스에 코드가 중복되어 있으면, 메서드 올리기로 부모 로 옮기기
긴 함수
- 오랜 기간 잘 활용되는 프로그램은 하나같이 짧은 함수로 구성
- 짧은 함수들은 연산하는 부분이 하나도 없어 보임
- 끝없이 위임하는 방식
- 코드를 이해하고, 공유하고, 선택하기 쉬워지는 장점은 간접 호출(indirection)의 효과는 짧은 코드로부터 나오게 됨
- 예전에는 서브루틴을 호출하는 비용이 컸기 때문에 짧은 함수를 꺼렸지만 요즘 언어는 프로세스 안에서의 함수 호출 비용이 거의 없어 짐
- 좋은 함수 이름 + 짧은 함수는 본문 코드를 보지 않아도 이해할 수 있게 함
- 주석을 달아야 할 만한 부분은 무조건 함수로 만들기
- 함수 이름은 동작 방식이 아닌 의도가 드러나게 짓기
- 원래 코드보다 길어지더라도 함수로 뽑기
- 무엇을 하는지를 코드가 잘 설명해주지 못할수록 함수로 만드는 게 유리
- 함수를 짧게 만드는 작업의 대부분은 함수 추출하기가 차지
- 함수가 매개변수와 임시 변수를 많이 사용한다면 추출 작업에 방해가 됨
- 추출된 함수에도 매개변수가 너무 많아져서 리팩터링 전보다 난해해질 수 있음
- 임시 변수를 질의 함수로 바꾸기로 임시 변수의 수를 줄이고 매개변수 객체 만들기와 객체 통째로 넘기기로 매개변수 수를 줄이기
- 위를 적용해도 임시 변수와 매개 변수가 너무 많다면 함수를 명령으로 바꾸기를 고려
- 추출할 코드 덩어리는 주석을 참고
- 코드만으로는 목적을 이해하기 어려운 부분에 달려 있는 경우가 많음
- 주석이 설명하는 코드와 함께 함수로 빼내고, 함수 이름은 주석 내용을 토대로 짓기
- 조건문, 반복문도 추출 대상의 실마리를 제공
- 조건문 분해하기
- switch 문을 구성하는 case 문마다 함수 추출하기를 적용해서 case의 본문을 함수 호출문 하나로 바꾸기
- 같은 조건을 기준으로 나뉘는 switch문이 여러개라면 조건문을 다형성으로 바꾸기
- 반복문도 독림된 함수로 만들기
- 추출한 반복문에 적합한 이름이 떠오르지 않는다면 성격이 다른 두 가지 작업이 섞여있기 때문이므로 과감하기 반복문 쪼개기를 할 것
긴 매개변수 목록
- 예전에는 함수에 필요한 것들을 모두 매개변수로 전달하였음
- 전역 데이터가 늘어나는 사태를 막을 수 있기 때문에 그 당시에는 합리적인 방식
- But. 매개 변수 목록이 길어지면 그 자체로 이해하기 어려울 때가 많음
- 다른 매개변수에서 값을 얻어올 수 있는 매개변수가 있을 때 매개변수를 질의 함수로 바꾸기로 제거
- 사용 중인 데이터 구조에서 값들을 뽑아 각각을 별개의 매개변수로 전달하는 경우, 객체 통째로 넘기기를 적용
- 원본 데이터를 그대로 전달
- 항상 함계 전달되는 매개변수들은 매개변수 객체 만들기로 하나로 묶기
- 플래그 역할의 매개 변수는 플래그 인수 제거하기로 없애기
- 클래스는 매개 변수 목록을 줄이는 데 효과적인 수단
- 여러 개의 함수가 특정 매개변수들의 값을 공통으로 사용할 때 유용
- 여러 함수를 클래스로 묶기를 이용하여 공통 값들을 클래스의 필드로 정의
'programming study > Refactoring' 카테고리의 다른 글
Refactoring - 코드에서 나는 악취(3) (0) | 2021.12.26 |
---|---|
Refactoring - 코드에서 나는 악취(2) (0) | 2021.12.26 |
Refactoring - 리팩터링 원칙(5) (0) | 2021.12.15 |
Refactoring - 리팩터링 원칙(4) (0) | 2021.12.14 |
Refactoring - 리팩터링 원칙(3) (0) | 2021.12.13 |