함수 선언 바꾸기

Change Function Declaration

쉽게 말하면

함수 선언 바꾸기는 가게 간판을 하는 일에 맞게 다시 다는 거예요. 간판만 보고도 뭘 파는지 알면 들어가 볼 필요가 없듯, 이름이 좋으면 구현을 열어 보지 않아도 돼요.

비유가 깨지는 곳 간판은 하룻밤에 바꿔도 되지만, 호출부가 많은 함수는 한 번에 바꾸면 여기저기 깨져요. 새 함수를 만들고 옛 함수가 새 함수를 부르게 둔 채 호출부를 하나씩 옮기는 병렬 수정을 써요.

함수의 이름이나 매개변수 목록을 바꾸는 리팩터링. 가장 자주 쓰는 리팩터링이 이름 바꾸기인 것은, 이름이 코드를 명료하게 하는 가장 큰 도구이기 때문이다.

이름이 좋으면 구현을 열어 보지 않고 호출문만으로 무슨 일을 하는지 안다. 더 나은 이름이 떠오르면 바로 바꾼다
좋은 이름이 안 떠오르면 함수의 목적을 주석으로 먼저 써 본다. 그 주석이 이름으로 바뀌어 돌아오는 경우가 많다
함수 안에서 구할 수 있는 값을 매개변수로 받고 있다면 빼고, 함수가 특정 전역에 묶여 있다면 매개변수로 꺼낸다. 이 둘 사이의 균형은 명령-질의 분리의 참조 투명성(Referential Transparency) 이야기와 닿아 있다
호출부가 많거나 공개 API(Application Programming Interface)라면 한 번에 바꾸지 않는다. 새 이름의 함수를 만들고 옛 함수가 새 함수를 부르게 둔 채 호출부를 하나씩 옮기는 병렬 수정(Parallel Change)을 쓴다
변수·필드 이름도 같다. 새 이름으로 선언하고 옛 이름이 새 이름을 가리키게 해 두면 조금씩 옮길 수 있다

이름짓기 자체의 함정(이름과 동작이 어긋나는 경우)은 언어적 안티패턴에, 사람을 놀라게 하지 않는 이름은 최소 놀람의 원칙에 정리했다.

연결된 개념

임시 변수를 질의 함수로 바꾸기
계산 결과를 담아 두던 임시 변수를 그 값을 돌려주는 함수로 바꾸는 리팩터링. 긴 함수를 쪼개기 전 단계로 특히 쓸모 있다.
함수·필드 옮기기
함수나 필드를 더 자연스러운 맥락(모듈·클래스)으로 옮기는 리팩터링. 좋은 설계의 핵심인 모듈성(Modularity), 즉 어딘가를 고칠 때 관련된 작은 부분만 이해하면 되게 하는 능력을 키운다.
플래그 인수
호출하는 쪽이 함수 안에서 실행할 로직을 고르려고 넘기는 인수. 호출문만 봐서는 무슨 뜻인지 알기 어렵고, 함수가 어떤 기능들을 제공하는지도 숨긴다.
변수 추출하기
복잡한 표현식의 일부에 이름을 붙여 지역 변수로 빼는 리팩터링. 변수를 추출하고 싶다는 건 그 표현식에 이름을 붙이고 싶다는 뜻이다.
리팩터링
겉으로 보이는 동작은 그대로 둔 채, 코드를 이해하고 고치기 쉽게 내부 구조를 바꾸는 일. 기능을 더하는 일이 아니라 다음 변경을 덜 위험하게 만드는 정리다.

보기 옵션

글자 크기 100%자간 0.00줄 간격 1.7