자바로 배우는 리팩토리 입문 0장

1번 그림은 상위 클래스를 가리키는 화살표 

2번 그림은 인터페이스를 가리키는 화살표 

3번 그림은 집합을 나타내는 화살표 필드 등으로 객체를 포함하는 경우 사용한다.

4번 알고 있다를 뜻하는 화살표 집합을 뜻하는 화살표와 같지만 포함한다를 강조하기보다는 필드에 들어 있음을 강조할 때 사용 

5번은 사용한다 필드에 들어 있지 않아도 메서드의 매겨변수나 임시 변수등으로 사용할 가능서이 있는 객체를 가리킴  

리팩토링이란?

정의

리팩토링이란 외부에서 보는 프로그램 동작은 바꾸지 않고 프로그램 내부 구조를 개선하는것 

- 리팩토링해도 외부에서 보는 프로그램 동작은 변하지 않는다.

- 리팩토링하면 프로그램의 내부 구조가 개선된다. 

예) 방대한 클래스를 추출하여 잘 분할시키는 것 

 

1. 버그 수정은 리팩토링이 아니다.

버그수정은 외부에서 보는 프로그램 동작이 변한다. 

2. 기능 추가는 리팩토링이 아니다.

- 이것 또한 외부에서 보는 프로그램 동작이 변하므로 리팩토링이 아님 

3. 소스 코드 정리는 리팩토링?

- 소스코드 정리도 프로그램 동작에 변화가 생길 가능 성 있기 때문에 리팩토링이 아님 

 

리팩토링과 유닛테스트 

유닛테스트 단위테스트라고도 부른다. 유닌테스트는 개발자가 직접 하는 부분의 테스트이며 

보통 클래스하나 또는 패키지 하나를 테스트 대상으로 삼는다 .

 

리팩토링할 때 그 전후 테스트를 실행한다. 

- 리팩토링 전에 테스트를 한다.

- 리팩토링 한다.

- 리팩토링후 다시 테스트 한다.

자바의 유닛테스트 테스트 프레임워크는 JUnit이다.

 

리팩토링의 목적

- 버그 수정과 기능 추가는 리팩토링이 아니다. 

 

리팩토링의 목적은 다음과 같다 .

1. 버그를 발견하게 쉽게 만든다.

 - 프로그램이 정리되어 숨은 버그를 찾기 쉽게 한다. 

2. 기능을 추가하기 쉽게 만든다. 

- 리팩토링하면 망가지고 더러운 코드를 다시 정비해서 깨끗하게 만들 수 있다 그러면 기능 추가가 편해진다. 

3. 리뷰하기 쉽게 만든다.

- 프로그램 품질은 높이데는 여러 기술자가 코드를 읽고 검토하는 코드 리뷰가 중요한 역할을 한다. 리팩토링으로 깔끔해진 코드는 읽기 쉽고 이해하기 좋다 .

 

리팩토링의 한계

 

프로그램이 아직 동작하지 않을 때 

- 만드는 도중이라 리팩토링하기 전에 동작하는 프로그램을 만들어야한다.

- 설계나 코딩에 문제가 많아 버그 투성이이인 프로그램도 리팩토링이 불가능하다.

 

시간이 너무 촉박할 때 

0.2 리팩토링과 악취 

악취란 

- 리팩토링이 필요한 부분을 악취가 난다고 표현 

악취란 프로그램에서 다음과 같은 부분

- 이해하기 어려움 부분

- 수정하기 어려운 부분

- 확장하기 어려운 부분

코드를 읽을 때 뭔가 이해하기 어렵다고 느낀다면 그런 악취다 바꿔말하면 리팩토링을 검토해봐야한다고 생각

코드의 악취 

1. 중복코드 : 같은 코드가 곳곳에 중복되어있다.

2. 너무 긴 메서드 : 메서드가 너무기 길다.

3. 방대한 클래스 : 클래스의 필드나 메서드가 너무 많다. 

4. 과다한 매개변수 : 메서드가 받는 매개변수 개수가 너무 많다.

5. 변경 발산 : 사양 변경이 있을 때 수정 내용이 곳곳에 흩어져 있다.

6. 변경 분산 : 어떤 클래스를 수정하면 다른 클래스도 수정해야 한다.

7. 속성,조작 끼어들기 : 언제나 다른 클래스 내용을 수정한느 클래스가 있다.

8. 데이터 뭉치 : 합쳐서 다뤄야 할 데이터가 한 클래스에 모여 있지 않다.

9. 기본 타입 집착 : 클래스를 만들지 않고 int 같은 기본 타입만 사용한다.

10. 스위치 문 : switch문이나 if문으로 동작을 나눈다.

11. 평행 상속 : 하위 클래스를 만들면 클래스 계층의 다른 곳에도 하위 클래스를 만들어야 한다. 

12. 게으른 클래스 : 클래스가 별로 하는 게 없다 . 

13. 의심스러운 일반화 : 언젠가 이런 확장을 하겠지 라고 너무 일반화한다.

14. 임시 속성 : 임시로만 쓰는 필드가 잇다.

15. 메시지 연쇄 : 메서드 호출 연쇄가 너무 많다. 

16. 중개자 : 맡기기만 하고 자신은 일하지 않는 클래스가 있다.

17. 부적절한 관계 : 그럴필요가 없는 데되 양방향 링크를 걸거나 IS-A관계가 없는 데 상속을 사용한다.

18. 클래스 인터페이스 불일치 : 클래스 인터페이스(API)가 적절하지 않다.

19. 불완전한 라이브러리 클래스 : 기존 라이브럴리 클래스를 사용하기 어렵다.

20. 데이터 클래스 : 필드와 게터(getter) 메서드와 세터(setter) 메서드 뿐인 클래스가 있다.

21. 상속 거부 : 상속한 메서드인데 호출하면 문제가 발생한다.

22. 주석 : 코드의 모자란점을 설명하기 위해 자세한 주석이 붙어 있다. 

 

이 말이 나오면 리팩토링이 필요하다 

1. 겹치잖아!

2. 너무 길어!

3. 너무 많아!

4. 이름이 안 맞잖아!

5. 너무 공개적이잖아!

6. 객체 지향 답지 않아!

 

겹치잖아! -> 메서드 추출이나 클래스 추출을 검토 null확인이 많다면 널객체 도입이라는 리팩토링이 효과적 

너무 길어! -> 메서드 추출과 클래스 추출 

너무 많아! -> 중개가 제거, 클래스 인라인화 , 메서드 인라인화 

이름이 안 맞잖아! -> 메서드 추출, 메서드명 변경 ,설명용 변수 도입 , 임시 변수 분리 

너무 공개적이잖아! -> 필드 캡슐화 , 생성자를 팩토리메서드로 치환 

객체 지향답지 않아! -> 다형성을 사용하자 , 분류코드를 클래스로 치환이나 분류코드를 하위클래스로 치환 같은 리팩토링을 검토 

0.3 리팩토링 카탈로그 

리팩토링의 목적과 절차를 카탈로그 형식으로 정리한것 

www.refactorying.com 

0.4 리펙토링 에센스 

 

스텝 바이 스텝 : 두가지 수정을 한꺼번에 하지 않기 

A와 B작업이 있다면 

A작업 을 진행하고 확인

B작업을 진행하고 확인 

 

스텝 바이 스텝 : 되돌리기 쉽게 하기 

A 작업 B작업을 나눠서 했다면 소스코드를 되돌리기 쉽다.

 

스텝 바이 스텝 : 단계 마다 확인 

- 컴파일 

- 컴파일해서 테스트

스텝 바이 스텝 : 오래된 걸 새로운 걸로 바꿈 

- 모든 것을 부수고 다시 만드는 것이 아닌 , 동작하는 상태를 유지하면서 새로운 코드가 추가해서 오래된 것이 모두 새로워 지면 오래된 것을 제거한다. 

 

0.5 리팩토링 QnA

리팩토리는 만능인가? - 내부구조를 개선해서 버그 제거와 기능추가를 쉽게 하고 읽기 편한 코드를 만들 뿐이다. 

리팩토링은 배워야하는가 - 무의식중에 하는것을 의식적으로 재정리 할 수 있기 때문에 

동작하는 코드를 수정해도 되는가 - 동작하는 코드를 나중에 수정하고 기능 추가를 하기위해 하는 작업이다.

기초 설계를 제대로하는 편이 낫지 않은가 -요구사항은 빈번히 변한다  리팩토리는 설계의 개선이다.

적절한 리팩토링을 선택하려면 - 우선 악취를 맡는다.

전부 기억해야하는가 - 기본요령을 익힌다.

XP 와 관련이 깊은가? -관계가 깊다 

디자인 패턴과 관계가 있는가? - 디자인 패턴은 리팩토링의 길장이다. -> 리팩토링이 향하는 더 좋은 코드의 이상향이 디자인 패턴이다.

직장에서 리팩토링하기 어렵다 - 리팩토링을 코딩의 일부로 리팩토링을 진행한다.