기억해두고 싶은 말
- 리팩터링이 필요한 이유는 변경 때문임.
- 리팩터링할 코드 영역을 꼼꼼하게 검사해줄 테스트 코드 마련하기.
- 나를 믿지 말자.
- 리팩터링은 프로그램 수정을 작은 단계로 나눠 진행함.
- 중간에 실수하더라도 버그를 쉽게 찾을 수 있음.
- 좋은 코드에 대한 기준은 다양하지만
얼마나 수정하기 쉬운가를 기준으로 삼는 데 이견이 없다.
함수 쪼개기
- 리팩터링은 프로그램 수정을 작은 단계로 나눠 진행함.
- 프로그램의 논리적인 요소를 쉽게 파악할 수 있도록 코드 구조를 보강해보자.
1. 함수 추출하기
- 코드 조각을 별도 함수로 추출함 (중첩 함수).
- 중첩 함수를 사용하면 바깥 함수에서 쓰던 변수를 새로 추출한 함수에 매개변수로 전달할 필요가 없어서 편함.
- 예시) amountFor()를 statement의 중첩 함수로 사용. 🧑💻 Extract switches into amountFor fn
2. 변수 이름 명확하게 하기
- thisAmount 대신 result로 변경.
- 함수의 변환 값에는 result라는 이름을 사용함.
- pref 보다는 aPerformance.
- 매개변수의 역할이 뚜렷하지 않을 떄는 부정 관사(a/an)을 붙임.
- 와닿지는 않음… 모국어인 사람에겐 다르게 느껴질 수도 있다고 생각함.
3. 임시 변수 줄이기
- 로컬 범위에 존재하는 이름이 늘어나서 추출 작업이 복잡해짐.
- 자신이 속한 루틴에서만 의미가 있어서 길고 복잡해지기 쉬움.
- 임시 변수를 질의 함수로 바꾸자 → play
- 또는 임시 변수를 인라인 변수로 바꾸자 → thisAmount
- 예시) play, thisAmount 임시 변수 지우기
- 🧑💻 Rename variables to result and parameters to aPerformance
- 이전 코드는 루프를 한 번 돌 때마다 공연을 조회했는데 반해 리팩터링한 코드에서는 세 번이나 조회함.
- 추후 리팩터링과 성능의 관계를 자세히 설명할 예정.
- 지금은 이렇게 변경해도 성능에 큰 영향은 없음.
- play 변수를 제거한 결과 로컬 유효범위의 변수가 하나 줄어서 적립 포인트 계산 부분을 추출하기 쉬워짐.
- 🤔 변수를 밖으로 빼는 것도 좋은 것 같은데….
- 반복문을 돌 때 변수값이 바뀐다면 리팩터링하기 더 까다로움.
- 🧑💻 Extract totalVolumeCredits fn
- 함수와 관련한 문장들을 한데 모아두면 임시 변수를 질의 변수로 바꾸기가 수월해짐.
- 인라인 할 부분은 없는지 확인하기
- 반복문이 중복되는 걸 꺼릴 수도 있지만, 어느 정도 중복은 성능에 미치는 영향이 미미할 수 있음.
- 리팩터링 후 성능이 크게 떨어졌다면 리팩터링 후 시간을 내어 성능을 개선하자.