Refactoring (2)
리팩토링과 설계
- 사전 설계 없이 리팩토링만 하는 방법도 문제는 없지만, 작업에서 가장 효율적인 방법은 아님
- 리팩토링을 통해 사전 설계 과정에서 완벽한 솔루션을 찾을 필요가 없어진다.
- 즉, 설계가 단순해지는 효과가 나타난다.
리팩토링과 성능
- 빠른 SW를 작성할 수 있는 일반적인 방법
- 철저한 시간 분배
- 성능에 대해서 꾸준한 괌신을 갖도록 하는 것
- 개발 절차 중에는 잘게 쪼개서 사용
- 즉, 리팩토링은 단기적으로는 SW가 느려질 수 있지만 최적화를 통해 결과적으로 SW 개발이 더욱 빨라진다.
리팩토링을 진행해야 하는 상황
책에서는 코드의 구린내라는 말로 표현을 하고 있습니다.
중복 코드(Duplicated Code)
- 똑간은 코드 구조가 2군데 이상이 있을 때, 그 부분을 하나로 통일할 필요가 있다.
장황한 매서드 (Long Method)
- 프로시저가 길수록 이해하기 어렵기 때문에 적절한 매서드명을 통해서 매서드를 나누어 표현하도록 한다.
방대한 클래스
- 클래스 안의 일부 변수가 접두어나 접미어가 같다면 하나의 클래스로 추출하는게 좋다.
- 모듈 추출을 실시할 수도 있다.
과다한 매개변수
- 필요한 데이터가 없을 때는 다른 객체에서 요청하도록 한다.
- 매서드가 필요로 하는 데이터를 클래스에서 호출
- 필요한 데이터가 없을 때는 다른 객체에서 요청하도록 한다.
수정의 산발
- 데이터를 수정할 때, 분명한 위치로 가서 바로 수정이 가능하도록 한다.
- 이런 경우 여러 개의 변형 객체로 분리가 필요
- 데이터를 수정할 때, 분명한 위치로 가서 바로 수정이 가능하도록 한다.
기능의 산재
- 수정 작업을 할 때마다 여러 클래스에서 내용을 고쳐야 한다면 하나의 클래스로 뭉치는 작업이 필요
잘못된 소속
- 한 메서드가 여러 클래스에 들어있는 기능을 이용하게 될 경우, 매서드가 접근하는 데이터가 가장 많은 클래스로 내용을 옮기도록 한다.
데이터 뭉치
- 동일한 3 ~ 4개의 데이터 항목이 여러 위치에 몰려있는 경우, 이를 객체로 묶어 관리가 필요하다.
강박적 기본 타입 적용
- 프로그래밍 환경을 구성하는 데이터 종류
- Record 타입(Integer, Long)
- 기본 타입(Int, double)
- 프로그래밍 환경을 구성하는 데이터 종류
Switch 문
- switch 문을 사용하게 된다면 반드시 중복이 발생
평행 상속 계층
- 평행 상속 계층의 중복 코드를 제거하기 위해서는 한 상속 계층의 인스턴스가 다른 인스턴스를 참조하게 만든다.
직무 유기 클래스(Lazy Class)
- 들어가는 비용만큼 기능을 수행하지 못하는 비효율적인 클래스를 없애야 한다.
- 직무 유기 클래스
- 리팩토링으로 인해 기능이 축소된 클래스
- 수정을 실시하지 않아 불필요해진 클래스
막연한 범용 코드
- 테스트 케이스에서만 사용되는 코드들은 과감하게 지울 수 있어야 한다.
임시 필드(Temporary Field)
- 떠돌이 임시 변수들을 관리하기 위해 관련 코드를 전부 넣어 작성해야 한다.
메시지 체인(Message Chains)
- 연쇄적인 요청이 발생하면서 생기는 문제점
과잉 중개 매서드
- 일부 매서드에 큰 기능이 없는 경우, 매서드의 내용을 직접 삽입하는 것이 좋다.
지나친 관여
- 서로 지나치게 관여하는 클래스의 경우는 이를 분리해 줄 필요가 있다.
인터페이스가 다른 대용 클래스
- 기능은 같은데 시그니처가 다른 매서드에는 매서드 이름의 변경을 실시해야 한다.
미흡한 라이브러리 클래스
- 외부 클래스에 매서드 추가 기법을 실시 후, 부가 기능이 많을 때, 국소적 상속확장 클래스 기법을 실시한다.
데이터 클래스
- 데이터 클래스
- 필드의 읽기, 쓰기 매서드만 있는 클래스
- public으로 선언되어 있다면 캡슐화를 진행하자
- 데이터 클래스
방치된 상속물
상속받은 매서드나 데이터가 하위클래스에서 더 이상 쓰이지 않거나 필요로 하지 않는 경우,
사용되지 않는 모든 메서드를 형제 클래스에 몰아넣어야 한다.
불필요한 주석
참고자료
- 리팩토링_코드 품질을 개선하는 객체지향 사고법 _마틴파울러 저