# 리팩터링

## 리팩터링

> 소프트웨어 품질을 보증하기 위해 반드시 리팩터링이 필요
>
> 즉, 리팩터링을 하지 않으면 조기/애자일 품질을 보증할 수 없다.

* **코드에 관한 본질론에서 리팩터링을 권장** - 마틴 파울러 관점
  * 리팩터링을 **코드 품질을 지속적으로 유지하고 개선하는 과정**을 위한 것
  * **기술 부채를 관리하고, 코드 구조를 개선**하는 데 중점
* **익스트림 프로그래밍의 실천방안으로서의 리팩터링** - 켄트 백 관점 (TDD)
  * 코드 구조를 바꾸기보다는 코드 작성의 흐름을 정비하기 위한 것
  * 리팩터링을 TDD의 중요한 부분으로 보고, **빠른 피드백과 반복적인 개발** 속에서 **기능을 안전하게 유지**하면서 **코드를 점진적으로 개선하는 방식**

{% hint style="success" %}

* 품질이 좋지 않은 코드는 두려워하지 말고 리팩터링해야 한다.
* 최악의 경우 리팩터링에 실패하더라도 버그가 발생할 뿐이다.&#x20;
* 리팩터링하지 않으면, 언젠가 해당 코드를 수정할 때 버그가 발생한다.
  {% endhint %}

### 단위 테스트가 어려운 복잡한 코드

1. 파일의 전체 복잡도가 높다면, 파일을 먼저 2\~3개로 분리 (간단해진다면 단위 테스트는 필요없다?)
2. 그래도 복잡도가 내려가지 않는다면, 기존의 복잡한 함수 코드에 대한 단위 테스트 작성
3. 모킹
4. 커버리지 비율 측정 후 75% 가 될 때 까지 단위 테스트 추가
5. 리팩터링
6. 단위 테스트 실행 후 결과가 같은지 확인

### 파일 코드 리팩터링

> 파일의 코드가 길어지는 이유는 **책임과 의무가 적절하게 구분되지 않기 때문**

* 일단, 어떤 파일에도 포함할 수 없으니 어딘가(여기)에 넣어둠
* 매우 많은 중복 코드
* 규모가 큰 모듈에 의한 파일의 비대화
