자바로 배우는 리팩토링 입문 1

※자바로 배우는 리팩토링 입문 책을 보고 작성하였습니다.

단순히 돌아가는 코드를 넘어, 우아한 코드를 작성하고 싶은 마음에 이 책을 읽기 시작했다.

 

리팩토링이란

외부에서 보는 프로그램 동작은 바꾸지 않고 프로그램의 내부구조를 개선하는 것

단순히 소스코드를 정리하는 것이 아닌, 반드시 '외부에서 부는 프로그램 동작에 변화가 없음'을 확인해야 한다.

• 리팩토링해도 외부에서 보는 프로그램 동작은 변하지 않는다.
• 리팩토링 하면 프로그램의 내부 구조가 개선된다.

리팩토링과 유닛테스트

리팩토링 후 동작이 변하지 않았다는것을 확인하기 위해 최소한 유닛테스트(단위테스트)를 진행한다.

유닛테스트는 개발자가 직접 하는 부분테스트이며 보통은 클래스 하나 또는 패키지 하나를 테스트 대상으로 삼는다.

테스트 시점

• 리팩토링 전에 테스트한다
• 리팩토링
• 리팩토링 후에 다시 테스트한다.

JAVA에서 가장 많이 쓰는 유닛테스트용 테스트 프레임워크는 JUnit이다.

리팩토링의 목적

• 버그를 발견하기 쉽게 만든다. - 프로그램이 정리되어 숨은 버그를 찾기 쉬워진다.
• 기능 추가를 쉽게 만든다 - 시간에 쫓겨 급하게 코드를 추가하게되면, 덕지덕지 발라진 누더기 코드가 된다. -> 기능을 추가하기가 더욱 힘들어지고 코드를 유지보수하기 힘들다. 리팩토링을 통해 깨끗하게 만들면 기능추가가 편해진다.
• 리뷰하기 쉽게 만든다. -> 읽기 쉽고 이해하기 좋아진다.

리팩토링이 불가능 할 때

• 프로그램이 아직 동작하지 않을때, 설계나 코딩이 많아 버그투성이인 프로그램은 리팩토링이 불가하다.
• 시간이 너무 촉박할때, 릴리즈 직전

리팩토링과악취

악취가 나는 프로그램이란

• 이해하기 어려운 부분 - 코드를 읽을때 뭔가 이해하기 어렵다고 느낀다면 그건 악취일지도 모른다. 리팩토링을 검토해 봐야 한다.
• 수정하기 어려운 부분
• 확장하기 어려운 부분

악취를 나타내는 말

• 겹치잖아! - 중복코드가 내는 악취의 특징. ->
  • 합칠 수 있는걸 찾아서 메서드 추출이나 클래스 추출 리팩토링 검토 필요.
  • null체크가 이곳저곳에 존재한다면 NULL객체 도입이라는 리팩토링이 효과적.
  • 에러 확인이 많다면 에러 코드를 예외로 치환 리팩토링을 검토
• 너무 길어! -> 너무 긴 메서드 에서는 메서드 추출필요. 메서드 추출은 코드모음을 정리해서 새 메서드로 만드는 리팩토링.메서드가 너무 많으면 책임별로 클래스를 나눠서 클래스 추출이라는 리팩토링 필요.
• 너무 많아! -> 패키지에 클래스가 너무 많은경우. 중개자 제거 리팩토링이나, 클래스 인라인화, 메서드 인라인화 같은 리팩토링 필요.
• 이름이 안 맞잖아! 
• 너무 공개적이잖아!(정보은폐) -> 예를들어 public메서드는 외부에서 호출할 수있기 때문에 프로그램 수정시 '누군가 쓰고 있을지도 몰라. 삭제하면 안되겠는데..'라고 고민 할 수가 있다.
  
  • 또한 필드도 필드캡슐화가 필요하다.
  • 클래스명도 과도한 공개를 피해야 한다. 생성자를 팩토리메서드로 치환하는 리팩토링을 도입하면 클래스명을 숨길 수 있다.
  • 클래스 사이의 관계도 숨길 수 있다.
  • 매직넘보를 기호 상수로 치환한다.
• 객체 지향답지 않아!
  • switch문이나 if문으로 처리를 분기 -> 대신 다형성을 사용하자.
  • instanceof로 객체가 속한 클래스를 조사 -> 객체지향이라면 객체 자체가 자신의 동작을 잘 안다. 따라서 이 객체는 어떤 클래스의 인스턴스인가 조사하지 않아도 된다.
  • int만 쓰고 전용 클래스를 만들지 않음
  • 위와 같은 경우에는 분류코드를 클래스로 치환이나 분류코드를 하위 클래스로 치환 같은 리팩토링을 도임 할 수 있다.
  • 이때 중요한건 객체지향 답지 않은 코드가 있다면 반드시 리팩토링 해야하는것은 아니다. 뭐든지 리팩토링 하려고 하는것은 쉽게 빠질 수 있는 함정이므로 주의하자.

리팩토링 카탈로그

<리팩토링: 코드 품질을 개선하는 객체지향 사고법> www.refactoring.com 에서는 각 리팩토링의 목적과 절차를 카탈로그 형식으로 정리했다. 이 카탈로그를 리팩토링 카탈로그라고 부른다.

• 체계적 수정 - 리팩토링 할때에는 카탈로그에 따라 체계적으로 코드를 변경해야 한다.

리팩토링에센스

리팩토링 시 주의할점

• 두가지 수정을 한꺼번에 하지 않기 - 반드시 단계별로 진행한다. 예를들어 클래스를 옮기는 리팩토리중에 이름을 변경하지 않는다.
• 되돌리기 쉽게 하기 단계별로 진행하는 가장 큰 목적은 '마지막'단계 되돌리기이다. 문제가 생겨서 수정을 되돌려야 할 수 있기 때문이다.
• 단계마다 확인 - 각 단계마다 확인해야 한다. 컴파일해서 문법오류확인, 컴파일해서 테스트 결과 확인이 필요하다.
• 오래된 코드를 새로운 것으로 바꾼다.
  • '모든것을 부수고 모두 다시 만든다'가 아닌, 동작하는 상태를 유지하면서 새로운 코드를 추가해서 오래된것이 새로워지면 오래된것을 제거한다.
• 지금 직장에서 리팩토링을 적용하기 어렵다면 작은것부터 시작해보자. 자신이 작성한 범위에서 악취가 나기 시작하면 바로 리팩토링을 시작하는것이다. 따로 리팩토링 공정을 준비하는것이 아닌, 코딩의 일부로 하는게 포인트이다.