03. 코드에서 나는 악취
냄새나면 당장 걷어라#
켄트 백 할머니의 육아 원칙이다.
리팩토링을 하는 가장 적절한 시기는 뭔가 이상한데? 라는 생각이 든 시점이 바로 리팩토링의 시점이다!
그럼 도당체 뭘 기준으로 이상한데?를 판별할 수 있단 말인가?
여기에 몇 가지 적절한 예시가 존재한다.
기이한 이름#
이름 짓기는 프로그래밍에서 가장 어렵지만 중요하다.
그렇기에 이상한 이름을 본다면 리팩토링을 하도록 하자.
중복 코드#
똑같은 코드가 반복되는 경우에도 리팩토링이 가능하다.
이 경우 일반적으로 IDE에서 알려주므로 이것으로 예측이 가능하다.
긴 함수#
긴 함수는 최대한 짧게 만들도록 하자.
함수 추출하기를 통해 짧게 만들어볼 수 있다.
switch 문이 여러 개라면 조건문을 다형성으로 바꾸기를 적용해볼 수 있다.
긴 매개변수 목록#
- 매개변수가 많다면 객체 통째로 넘기기를 사용하도록 하자.
전역 데이터#
- 전역 데이터 보다는 캡슐화를 통해 유지하도록 하자.
가변 데이터#
가변 데이터는 최대한 변수를 캡슐화하여 함수를 거쳐야만 변경되도록 하는 편이 좋다.
구조체와 같이 내부 필드를 갖는 경우에 내부 필드를 바꾸게 될 경우 내부 필드를 직접 수정하지 말고 구조체 통째로 교체하는 편이 더 낫다.
뒤엉킨 변경#
뒤엉킨 변경이란 단일 책임 원칙(SRP)를 위배할 때 나타난다.
가령 DB가 추가될 때 마다 함수 세 개를 바꾸거나, 금융 상품이 추가되면 함수 네 개를 바꿔야하는 것 처럼 하나의 변경이 여러 곳으로 전파되는 현상을 말한다.
산탄총 수술#
- 산탄총 수술이란 냄새나는 코드를 변경할 때 마다 여러 영역에 걸쳐서 수정해야하는 클래스가 많을 때 발생한다.
기능 편애#
기능 편애는 어떤 함수가 자기가 속한 함수나 데이터보다 다른 모듈의 함수나 데이터와 상호 작용이 많을 때 발생한다.
이 함수가 데이터와 가까이 있고 싶어 하는 데이터 근처로 옮겨주기만 하면 된다.
데이터 뭉치#
- 필드 형태의 데이터 뭉치가 돌아다닌다면 하나로 묶어서 클래스로 추출해주자.
기본형 집착#
- 전화번호와 같은 데이터 타입을 기본형으로 사용하기 보다는 객체로 바꾸도록 하자.
반복되는 switch문#
순수 객체 지향의 신봉자들은 switch 문을 싫어한다.
switch 조건부 로직을 다형성으로 변경하는 방향으로 하자.
반복문#
일반적인 반복문을 자바의 파이프라인으로 바꾸도록 하자.
map, filter와 같은 파이프라인 연산은 대부분의 언어에서 지원하는 기능이다.
성의 없는 요소#
- 메서드가 하나뿐인 클래스와 같이 비장하게 설계하였으나 잘 쓰지 않는 클래스는 죽이도록 하자.
추측성 일반화#
나중에 필요할거야라는 식의 코드는 필요없는 경우가 더 많다.
과감하게 계층 합치기, 함수 인라인하기, 클래스 인라인하기 등으로 없애버리자.
임시 필드#
- 특정 상황에서만 값이 설정되는 필드를 가진 클래스라면, 과감하게 지우도록 하자.
메시지 체인#
한 객체를 통해 다른 객체를 얻은 뒤 방금 얻은 객체에 또 다른 객체를 요청하는 식의 코드는 좋지않다.
게터가 꼬리를 물고 이어져 임시 변수들이 줄줄이 나열된다면 리팩토링의 좋은 신호다.
중개자#
객체의 대표적인 기능 중 하나로 외부로부터 세부사항을 숨겨주는 캡슐화가 있다.
캡슐화 과정에서 위임을 주로 사용하는데, 이게 너무 지나치면 문제가 된다.
중개자 제거를 하여 실제로 일을 하는 객체와 직접 소통하게 만들도록 하자.
내부자 거래#
- 여러 모듈이 같은 관심사를 공유한다면 공통 부분을 정식으로 처리하는 제 3의 모듈을 새로 만들거나 위임 숨기기를 이용해 다른 모듈이 줄간자 역할을 하게 만든다.
거대한 클래스#
한 클래스가 너무 많은 일을 하다보면 필드 수가 늘어난다.
거대한 클래스라면 역할 별로 쪼개도록 하고, 슈퍼 클래스로 추출하거나, 타입 코드를 서브 클래스로 바꾸자.
서로 다른 인터페이스의 대안 클래스들#
클래스, 즉 객체 지향의 큰 장점은 언제든 다른 클래스로 교체할 수 있다는 것이다.
단 이를 위해서는 인터페이스가 같아야한다.
데이터 클래스#
Getter/Setter로만 이루어진 클래스를 데이터 클래스라고 부른다.
변경하면 안되는 영역은 Setter를 제거하고, 레코드를 캡슐화하자.
상속 포기#
상속은 얕은 깊이라면 일부 동작을 재활용할 수 있어서 유용하지만, 너무 깊이있게 가면 문제가 생긴다.
상속을 포기할 시 문제가 생긴다면 예전 방식을 사용하되, 상속을 포기함으로써 얻는 이득도 분명히 있으므로 이는 적절히 판단하자.
주석#
마틴 파울러는 주석이 꼭 나쁜 것은 아니라고 말한다. (이는 로버트.C.마틴의 클린코드와 완벽히 반대된다!)
적절한 주석은 오히려 약이 되지만 지나친 주석은 독이된다.
Reference#
- Refactoring 2판 ( 저자 : 마틴 파울러 )