리팩터링

리팩터링

소프트웨어 품질을 보증하기 위해 반드시 리팩터링이 필요

즉, 리팩터링을 하지 않으면 조기/애자일 품질을 보증할 수 없다.

• 코드에 관한 본질론에서 리팩터링을 권장 - 마틴 파울러 관점

  • 리팩터링을 코드 품질을 지속적으로 유지하고 개선하는 과정을 위한 것

  • 기술 부채를 관리하고, 코드 구조를 개선하는 데 중점

• 익스트림 프로그래밍의 실천방안으로서의 리팩터링 - 켄트 백 관점 (TDD)

  • 코드 구조를 바꾸기보다는 코드 작성의 흐름을 정비하기 위한 것

  • 리팩터링을 TDD의 중요한 부분으로 보고, 빠른 피드백과 반복적인 개발 속에서 기능을 안전하게 유지하면서 코드를 점진적으로 개선하는 방식

• 품질이 좋지 않은 코드는 두려워하지 말고 리팩터링해야 한다.

• 최악의 경우 리팩터링에 실패하더라도 버그가 발생할 뿐이다.

• 리팩터링하지 않으면, 언젠가 해당 코드를 수정할 때 버그가 발생한다.

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

1. 파일의 전체 복잡도가 높다면, 파일을 먼저 2~3개로 분리 (간단해진다면 단위 테스트는 필요없다?)

2. 그래도 복잡도가 내려가지 않는다면, 기존의 복잡한 함수 코드에 대한 단위 테스트 작성

3. 모킹

4. 커버리지 비율 측정 후 75% 가 될 때 까지 단위 테스트 추가

5. 리팩터링

6. 단위 테스트 실행 후 결과가 같은지 확인

파일 코드 리팩터링

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

• 일단, 어떤 파일에도 포함할 수 없으니 어딘가(여기)에 넣어둠

• 매우 많은 중복 코드

• 규모가 큰 모듈에 의한 파일의 비대화