리팩토링 정리(1)

1장 맛보기 예제

코드를 복사해서 붙이게 되면 나중에 그 코드를 수정할 때마다 계속 같은 여러 부분을 복사해서 붙여야 하기 때문에 아주 번거롭고 에러가 생길 수 있다.

리팩토링의 첫 단계는 리팩토링할 코드 부분에 대한 신뢰도 높은 각종 테스트를 작성하는 것이다.

(호출을 통해 위임 받는 메소드 내에서) 변경되지 않는 변수는 매개변수로 전달할 수 있다. 변경되는 변수는 (매개변수로 넘길 시) 더 주의해야한다.

리팩토링 단계의 또 한가지 문제점은 성능이다. (수정 전 코드는 루프가 1회이지만 리팩토링 후에는 3회…) 하지만 최적화 단계에서 걱정해도 늦지 않다. 최적화 단계가 성능 해결의 적기이며 효과적인 최적화를 위한 더 많은 선택의 여지가 있다.

타 객체의 속성을 switch문의 인자로 하는 것은 나쁜 방법이다. switch문의 인자로는 타 객체의 속성이 아닌 자신의 속성을 사용해야한다. -> 조건문을 재정의로 변환 기법을 사용하자.

‘간단한 수정 -> 테스트’를 리듬처럼 반복해야한다. like TDD

2장 리팩토링 개론

리팩토링의 목적

1. 소프트웨어를 더 이해하기 쉽고 수정하기 쉽게 만드는 것
2. 겉으로 드러나는 소프트웨어 기능에 영향을 주지 않고 개선하는 것

Why 리팩토링?

1. 소프트웨어 설계 개선
2. 소프트웨어 이해가 쉬워짐
3. 버그 찾기가 쉬워짐
4. 프로그래밍 속도가 빨라짐(장기적으로)

When 리팩토링?

1. 같은 중복 작업이 3번째 일 시
2. 기능을 추가할 시
3. 버그를 수정할 시 (with 실패하는 테스트)
4. 코드를 검수할 시

일정이 빠듯할 땐 리팩토링 얘길 꺼내질 말고 몰래 실시하자 ㅋㅋㅋㅋㅋㅋ

리팩토링의 장애물

1. 데이터베이스!!
2. Published 인터페이스 변경 (모듈 외부로 노출된 인터페이스)
3. 설계 수정
4. 리팩토링을 하면 안되는 상황

리팩토링과 설계

여전히 사전 설계는 해야 하지만, 사전 설계 과정에서는 완벽한 솔루션을 찾을 필요 없이 적당한 솔루션만 생각하면 된다. like Agile

리팩토링과 성능

리팩토링을 통해 코드르 잘게 분리하면 추후 성능 개선 시 편하게 할 수 있다.

3장 코드의 구린내

1. 중복 코드(Duplicated Code)
2. 긴 메서드(Long Method)
3. 큰 클래스(Large Class)
4. 긴 매개변수들(Long Parameter List)
5. 수정의 산발(Divergent Change) : 한 클래스가 다양한 원인으로 때문에 자주 수정될 경우 > SRP 위배
6. 산탄총 수술(Shotgun Surgery) : 한 기능을 수정하는데 여러가지 클래스가 변경되는 경우
7. 잘못된 소속(Feature Envy) : 속성과 행위의 분리 > 응집력 없음
8. 데이터 뭉치(Data Clumps) : 비슷한 속성들 끼리 몰려다님 > 값객체로 전환
9. 강박적 기본타입 사용(Primitive Obsession) > 값객체로 전환
10. switch 문(Switch Statements)
11. 평행 상속 계층(Parallel Inheritance Hierarchies) : 상속 시 다른 상속도 같이 해야함
12. 게으른 클래스(Lazy Class) : 비효율적으로 클래스로 분리된 것 > 적절한 클래스로 병합
13. 막연한 범용 코드(Speculative Generality) : 미래에 사용될 거 같은 기능 선구현
14. 임시 필드(Temporary Field)
15. 메시지 체인(Message Chains) : obj1.do().other().something()
16. 과잉 중개 메서드(Middle Man) : 과한 위임 > 이게 과연 나쁜냄세일 수도 있는가?
17. 지나친 관여(Inappropriate Intimacy) : 강결합을 약결합으로
18. 인터페이스가 다른 대용 클래스(Alternative Classes with Different Interfaces) : 같은 기능 다른 인터페이스 > 합쳐라
19. 미흡한 라이브러리 클래스(Incomplete Library Class)
20. 데이터 클래스(Data Class) : DTO > getter & 선택적 setter를 통한 필드 캡슐화
21. 방치된 상속물(Refused Bequest) : 사용하지 않는 부모의 유산
22. 불필요한 주석(Comments) : 주석을 넣어야겠다는 생각이 들 땐 먼저 코드를 리팩토링해서 주석을 없앨 수 있게 만들어보자.

4장 테스트 작성

모든 테스트를 완전히 자동화하고 결과를 자체적으로 검사하게 하자

완벽한 테스트를 작성하려다 아예 테스트를 포기하느니, 차라리 불완전한 테스트를 작성해 실행하는 편이 낫다.

5장 리팩토링 기법 카탈로그에 대해

디자인 패턴은 목표 지향점이고, 리팩토링은 다른 상태에서 그 지향점까지 도달하는 방법이다.