리팩토링 - 2

 

[리팩토링이 필요한 코드]

1. 중복된 코드

2. 긴 메소드

- 한 메소드의 여러 가지 내용이 들어 있다면 다fms 메소드로 빼는 것이 좋다.

3. 거대한 클래스

- 지나치게 많은 인스턴스 변수 와 코드

4. 긴 파라미터 리스트

- 긴 파라미터 리스트는 이해와 사용이 어렵기 때문에 필요한 객체는 메소드 호출로 얻는 것이 좋다.

5. 확산적 변경

- 한 클래스가 다른 이유로 인해 다른 방법으로 자주 변경 되는 경우

6. 산탄총 수술

- 변경을 할 때마다 많은 클래스를 조금씩 수정 해야 하는 경우

7. 기능에대한 욕심

- 메소드가 자신의 클래스 보다 다른 클래스의 데이터를 더 많이 사용하고 있는 경우

8. 데이터 덩어리

- 함께 사용 되는 데이터의 무리(ex: 두세개 클래스의 필드, 여러 메소드의 파라미터 등)

9. 기본 타입에 대한 강박관념

10. Switch 문

- 객체 지향의 코드에서 switch 문이 많 다면 다형성을 활용 하는 것이 좋다.

11. 평행 상속 구조

- 한쪽 상속 구조에서 클래스 이름의 접두어가 다른 쪽 상속 구조의 클래스 이름의 접두어와 같은 경우

12. 게으른 클래스

- 하는 일이 별로 없는 클래스는 삭제 한다.

13. 추측성 일반화

사용 되지 않는 데이터는 제거 한다. (불필요한 추상 클래스, 파라미터 ..)

14. 임시 필드

특정 상황에서만 세팅되는 변수 들을 넣는 클래스를 만든다.

15. 메시지 체인

메소드 간에 지나치게 많이 연결 되어 있는 경우

16. 미들맨

메소드가 다른 클래스로 위임을 하고 있는 경우

17. 부적절한 친밀

지나치게 친밀한 클래스 들

18. 다른 인터페이스를 가진 대체 클래스

같은 작업을 하지만 다른 시그너처를 가지는 메소드

19. 불완전한 라이브러리 클래스

-완전하지 않은 라이브러리 사용은 피해야 한다.

20. 데이터 클래스

데이터만 저장 하는 클래스는 캡슐화 한다.

21. 거부된 유산

상속 구조에서 상속 받은 내용들이 서브 클래스에서 필요 없는 경우

22. 주석

주석을 사용하는 것은 좋지만, 리팩토링을 한 후에 불필요한 주석이 있을 수 있다.

[테스트 만들기]

# 테스트를 하면 프로그래밍을 빠르게 할 수 있다.

1. 자체 테스트 코드의 가치

각각의 클래스에 테스트 메소드를 추가 하여 컴파일 시 마다 테스트를 하면 디버깅 시간을 단축 시킬 수 있다. (리팩토링을 하기 위해서는 테스트가 필요하다.)

2. 단위 테스트와 기능 테스트

단위 테스트는 한정된 범위의 패키지 내에서만 테스트를 하는 것이고 기능 테스트는 소프트웨어 전체가 제대로 작동 하는지를 확인하기 위한 것이다.

기능 테스트에서 버그를 발견하면 버그를 밖으로 드러낼 수 있는 단위 테스트를 수행 하는 것이 좋다.

3. 테스트 추가하기

테스트는 문제가 생길 만한 곳에 집중 되어야 한다. 지나친 테스트는 프로그래밍 시간을 더 오래 걸리게 할 수 있다.