리팩터링 2.0

3장 코드에서 나는 악취

3.1 기이한 이름

코드를 명료하게 표현하는 데 가장 중요한 요소 하나는 바로 이름이다. 함수, 모듈, 변수, 클래스 등은 그 이름만 보고도 각각 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 신경써서 이름을 지어야 한다.

하지만 이름 짓기는 프로그래밍에서 가장 어려운 두가지 중 하나다. 그 때문에 우리가 가장 많이 사용하는 리팩터링도 함수 선언 바꾸기, 변수 이름 바꾸기, 필드 이름 바꾸기 처럼 이름을 바꾸는 리팩터링들이다.

이름 바꾸기는 단순히 이름을 다르게 표현하는 연습이 아니다. 마땅한 이름이 떠오르지 않는다면 설계에 더 근본적인 문제가 숨어 있을 가능성이 높다. 그래서 혼란스러운 이름을 잘 정리하면 코드가 훨씬 간결해질 때가 많다.

3.2 중복 코드

똑같은 코드 구조가 여러 곳에서 반복된다면 하나로 통합하여 더 나은 프로그램을 만들 수 있다. 코드가 중복되면 각각을 볼때마다 서로 차이점은 없는지 주의 깊게 살펴봐야 하는 부담이 생긴다.

한 클래스에서 두 메서드가 똑같은 표현식을 사용하는 경우가 있다. 이럴 때는 함수 추출하기 를 써서 양쪽 모두 추출한 메서드를 호출하게 바꾸면 된다.

코드가 비슷한데 완전히 똑같지는 않다면, 먼저 문장 슬라이드하기 로 비슷한 부분을 한 곳에 모아 함수 추출하기를 더 쉽게 적용할 수 있는지 살펴본다. 같은 부모로부터 파생된 서브클래스들에 코드가 중복되어 있다면, 각자 따로 호출되지 않도록 메서드 올리기를 적용해 부모로 옮긴다.

3.3 긴 함수

선생님들의 오랜 경험에 비추어보았을 때, 오랜 기간 잘 활용되는 프로그램들은 하나같이 짧은 함수들로 구성이 되어 있다.

3.4 긴 매개변수 목록

함수가 배개변수로 받는 것들이 많아진다면 그 자체로 이해하기 어려워질 수 있다.

4장 테스트코드

• 완벽하게 만드느라 테스트를 수행하지 못하느니, 불완전한 테스트라도 작성해 실행하는 것이 낫다
• 각각의 테스트가 실패하는 모습을 최소한 한 번씩 직접 확인해보기
• 단순히 테스트 코드를 여럿 작성하는 것보다 적더라도 위험하다고 생각되는 영역을 집중적으로 작성할 것
• 버그를 발견하면 그 즉시 버그를 잡아내는 테스트부터 작성할 것. 버그를 고치기 전에 항상 테스트부터 만드는 습관..
• 픽스처 Fixture: 테스트를 수행하는 목적으로 만든 데이터와 객체. 테스트가 진행되는 동안 공통의 객체를 초기화하여 할당하고 해체.
• 테스트끼리 픽스처를 공유해서 상호작용하게 해서는 안 됨.