너와 나의 스토리

배경 비슷한 일을 수행하는 두 클래스가 보이면 상속 메커니즘을 이용해서 비슷한 부분을 공통의 슈퍼클래스로 옮겨 담을 수 있다. 슈퍼클래스 추출하기의 대안으로는 클래스 추출하기가 있다. 어느 것을 선택하느냐는 중복 동작을 상속으로 해결하느냐 위임으로 해결하느냐에 달렸다. 슈퍼클래스 추출하기 방법이 더 간단할 경우가 많으니 이 리팩터링을 먼저 시도해보길 권한다. 절차 빈 슈퍼클래스를 만든다. 원래의 클래스들이 새 클래스를 상속하도록 한다. 테스트한다. 생성자 본문 올리기, 메서드 올리기, 필드 올리기를 차례로 적용하여 공통 원소를 슈퍼클래스로 옮긴다. 서브클래스에 남은 메서드들을 검토한다. 공통되는 부분이 있다면 함수로 추출한 다음 메서드 올리기를 적용한다. 원래 클래스들을 사용하는 코드를 검토하여 슈퍼클래..

배경 오류가 발견되면 예외를 던진다. 그러면 적절한 예외 핸들러를 찾을 때까지 콜스택을 타고 위로 전파된다. 예외를 사용하면 오류 코드를 일일이 검사하거나 오류를 식별해 콜스택 위로 던지는 일을 신경 쓰지 않아도 된다. 예외는 프로그램의 정상 동작 범주에 들지 않는 오류를 나타낼 때만 쓰여야 한다. 예외를 던지는 코드를 프로그램 종료 코드로 바꿔도 프로그램이 여전히 정상 동작할지를 따져보고, 정상 동작하지 않을 것 같다면 예외를 사용하지 말라는 신호이다. 이런 경우, 예외 대신 오류를 검출하여 프로그램을 정상 흐름으로 되돌리게끔 처리해야 한다. 절차 콜스택 상위에 해당 예외를 처리할 예외 핸들러를 작성한다. 테스트한다. 해당 오류 코드를 대체할 예외와 그 밖의 예외를 구분할 식별 방법을 찾는다. 정적 검..

배경 생성자에는 일반 함수에는 없는 제약이 따라붙기도 한다. 가령 자바 생성자는 반드시 그 생성자를 정의한 클래스의 인스턴스를 반환해야 한다. 서브클래스의 인스턴스나 프락시를 반환할 수는 없다. 기본 이름(생성자 이름)보다 적절한 이름이 있어도 사용할 수가 없다. 생성자를 호출하려면 특별한 연산자(보통 new)를 사용해야 해서 일반 함수가 오길 기대하는 자리에는 쓰기 어렵다. 팩토리 함수에는 이런 제약이 없다. Before After leadEngineer = new Employee(document.leadEngineer, 'E'); leadEngineer = createEngineer(document.leadEngineer); 절차 팩터리팩토리 함수를 만든다. 팩토리 함수의 본문에서는 원래의 생성자를 ..

배경 매개변수 목록은 함수의 변동 요인을 모아놓은 곳으로 함수의 동작에 변화를 줄 수 있는 일차적인 수단이다. 다른 코드와 마찬가지로 이 목록에서도 중복은 피하는 게 좋으며 짧을수록 이해하기 쉽다. 피호출 함수가 스스로 "쉽게" 결정할 수 있는 값을 매개변수로 건네는 것은 의미 없이 코드만 복잡해질 뿐이다.. 매개변수를 질의 함수로 바꾸지 말아야 할 상황도 있다. 매개변수를 제거하면 피호출 함수에 원치 않는 의존성이 생길 때 주의 사항: 대상 함수가 참조 투명(referential transparency)해야 한다. * 참조 투명: 함수에 똑같은 값을 건네 호출하면 항상 똑같이 동작 따라서 매개변수를 없애는 대신 가변 전역 변수를 이용하는 일은 하면 안 된다. 절차 필요하다면 대상 매개변수의 값을 계산하..

배경 고객 리스트가 있다고 할 때, 이름과 같은 정보가 적혀있지 않은 미확인 고객이 있을 수 있다. 이런 특이 케이스를 검사하는 코드가 있다고 생각하자. 데이터 구조의 특정 값을 확인한 후 똑같은 동작을 수행하는 코드가 곳곳에 등장하는 경우가 더러 있다. 흔히 볼 수 있는 중복 코드 중 하나다. 특수한 경우의 공통 동작을 요소 하나에 모암서 사용하는 특이 케이스 패턴(Special Case Pattern)이라는 것이 있다. 위와 같은 경우에 적용하면 좋을 메커니즘이다. 이 패턴을 활용하면 특이 케이스를 확인하는 코드 대부분을 단순한 함수 호출로 바꿀 수 있다. 널(null)은 특이 케이스로 처리해야 할 때가 많다. 그래서 이 패턴을 널 객체 패턴(Null Object Pattern)이라고도 한다. 절차 ..

배경 함수는 여러 동작을 하나로 묶어준다. 함수의 이름이 코드의 동작 방식보다는 목적을 말해주기 때문에 함수를 활용하면 코드를 이해하기가 쉬워진다. 함수는 중복을 없애는 데도 효과적이다. 동작을 변경할 때도, 비슷해 보이는 코드들을 일일이 찾아 수정하는 대신 함수 하나만 수정하면 된다. 이미 존재하는 함수와 똑같은 일을 하는 인라인 코드를 발견하면 보통은 해당 코드를 함수 호출로 대체하길 원할 것이다. 하지만 기존 함수의 코드를 수정하더라도 인라인 코드의 동작이 바뀌지 않을 때만 함수 호출로 대체할 수 있다. 이를 판단하는 데는 함수 이름이 힌트가 된다. 인라인 코드 대신 함수 이름을 넣었을 때 말이 돼야 한다. 특히 라이브러리가 제공하는 함수로 대체할 수 있다면 훨씬 좋다. 예: Before let a..

배경 데이터 구조 설계에 대해 경험이 많은 사람도 초기 설계에서는 실수가 빈번하다. 프로젝트를 진행할수록 문제 도메인과 데이터 구조에 대해 더 많은 것을 배우게 된다. 현재 데이터 구조가 적절치 않음을 깨달으면 곧바로 수정해야 한다. 필드를 옮겨야 할 상황 함수에 어떤 레코드를 넘길 때마다 또 다른 레코드의 필드도 함께 넘기고 있다면 데이터 위치를 옮겨야 할 것 한 레코드를 변경하려 할 때 다른 레코드의 필드까지 변경해야 하는 상황 → 필드 위치가 잘못되었다는 신호 클래스를 사용하면 '필드 옮기기' 리팩터링을 수행하기 더 쉬워진다. 클래스의 데이터들은 접근자 메서드들 뒤에 캡슐화되어 있으므로 클래스에 곁들여진 메서드들은 데이터를 이리저리 옮기는 작업을 쉽게 해준다. 데이터의 위치를 옮기더라도 접근자만 그..

배경 적용된 알고리즘보다 간명한 방법을 찾아내면 기존 코드를 고친다. 알고리즘 전체를 걷어내고 훨씬 간결한 알고리즘으로 바꿔야 할 때가 있다. 문제를 더 확실히 이해하고 훨씬 쉽게 해결하는 방법을 발견했을 때 내 코드와 똑같은 기능을 제공하는 라이브러리를 찾았을 때 이 작업에 착수하려면 반드시 메서드를 가능한 한 잘게 나눴는지 확인해야 한다. 절차 교체할 코드를 함수 하나에 모은다. 이 함수만을 이용해 동작을 검증하는 테스트를 마련한다. 대체할 알고리즘을 준비한다. 정적 검사를 수행한다. 기존 알고리즘과 새 알고리즘의 결과를 비교하는 테스트를 수행한다. 두 결과가 같다면 리팩터링이 끝난다. 그렇지 않으면 기존 알고리즘을 참고해서 새 알고리즘을 테스트하고 디버깅한다. 출처: - [리팩터링 2판]