Refactoring 리팩토링

리팩토링

외부 동작은 변경하지 않고, 내부 구조를 변경하는 작업이다. 

따라서, 버그 수정/기능 추가는 리팩토링에 포함되지 않는다. 왜냐? 결과가 바뀌니깐!

그리고 기능을 추가하기 전에, 리팩토링을 먼저 하자.

가독성 향상과 유지보수가 용이해지기 때문에 기능 추가가 훨씬 수월하다. 

프로젝트 초기 아키텍트 설계가 완벽하더라도, 기능 추가와 버그 수정들이 있다면 설계는 점차 무너지게 된다. 따라서 리팩토링은 지속적으로 필요하다. 

리팩토링은 개발자의 관점에 따라 주관적이다. 자신의 논리적 판단을 근거로 코드를 수정하는 작업이기 때문이다. 

 

리팩토링의 목적

소프트웨어를 더 이해하기 쉽고 수정하기 쉽게 만드는 것(→ 가독성이 좋은 클린한 코드 짜기)이다. 이는 개발 속도를 빠르게 해준다.

리팩토링은 성능을 최적화시키는 것이 아니다.코드를 신속하게 개발할 수 있게 만들어주고, 코드 품질을 좋게 만들어주는 활동이다. 또한 리팩토링을 하기 전에 명심해야할 것은 정상 동작하는 코드가 선행되어야 한다는 것이다.

 

리팩토링이 필요한 코드

• 중복 코드
• 긴 메서드
• 거대한 클래스
• switch 문
• 절차지향으로 구현한 코드

 

리팩토링 훈련 규칙

• 들여쓰기 최소화
• 파라미터 최소화
• else 최소화
• 전역변수 사용 금지
• 작은 수정마다 테스트 수행
• 메서드 추상화
• 직접 구현보다는 라이브러리 사용 권장
• false 에 해당하는 코드는 위로 빼서 먼저 처리(Guard Clauses) 
• Test Coverage 100% 에서 시작
• 의존성이 낮은 것부터 분석

 

리팩토링 시 고려할 점

• 리팩토링 하는 이유를 정확히 구분하자
  오버엔지니어링(Over engineering)인가? 팀에 필요한 활동인가?
• 팀원들의 감정
  내 코드가 아닌 우리 팀원 전체의 코드라고 생각하는 마인드셋
• Legacy Code 에는 의도가 있다
  코드만 보고 소스코드의 모든 의도를 파악하는 것은 어렵다. 의도가 불분명한 코드는 코드 개발자와 대화가 필요하다.
• 버전관리 도구와 Test 환경이 충분히 갖춰져야 한다.
• 개발중이 아닌, 개발이 완료되어 동작되는 모듈 대상으로 리팩토링 한다.
  버그가 너무 많은 프로그램은 리팩토링 작업이 힘들다. 버그 수정부터 진행해야 한다.

 

Code Readability(코드 가독성) 

코드 가독성이란 소스코드를 보고, 코드의 의도하는 동작/알고리즘을 얼마나 쉽게 이해할 수 있는지를 나타낸다.

 

마틴 파울러 리팩토링 기법

1. Rename Variable, 이름을 짓는데 공들여야한다.
2. Replace Magic Literal, 매직넘버는 치환해서 예측할 수 있는 코드여야 한다.
3. 상수 의존관계, 상수끼리 관계가 있는 경우 관계를 표시해주는 것이 좋다.
4. Change Function Declaration, 명확한 함수명을 사용한다. 
5. Extract Function 
6. Inline Function, 1회성 함수는 inline 시키자.  
7. Extract Variable, 복잡한 수식의 코드는 이해하기 쉽게 쪼개서 이름을 붙이자.
8. Inline Variable, 의미가 충분하여 필요없는 경우도 있다. ex) int boxSize = box.size;
9. Encapsulate Variable, 캡슐화를 할 것/ 최대한 객체의 필드는 private 으로 유지하고, 필드값을 직접 제어하는 통로를 줄인다. setter 사용→ 유효값 검사 가능
10. Introduce Parameter Object, 파라미터 객체를 만들어 사용하자
11. Replace Control Flag with Break, Control Flag 는 제거하자

참고:  마틴 파울러 refactoring 사이트 :  https://refactoring.com/catalog/ 

 

 

유투브에 마틴 파울러의 리팩토링에 대한 키노트 발표가 있으니 한번 쯤 봐볼 것!

마틴파울러 - 리팩토링의 중요성