Refactoring 2 - Chpt. 02 리팩터링 원칙

디오·2021년 9월 7일
0

02. 리팩터링 원칙

2.1 리팩터링 정의

많은 사람들이 그저 코드를 정리하기만 하면 리팩터링이라고 하는데 그건 아니다. 책에 나오는 것과 같은 특정한 방식에 따라 코드를 정리하는 것만이 리팩터링이다.
코드베이스를 정리하거나 구조를 바꾸는 작업은 '재구성'이라는 포괄적인 단어로 표현한다. 리팩터링은 재구성 중 특수한 한 형태이다.

2.2 두 개의 모자

'기능 추가'와 '리팩터링' 두 개의 모자가 있다. 일반적으로 모자는 한번에 하나만 쓴다. 우리가 작업할 때에도 마찬가지로 하나의 모자만 써야한다.
'기능 추가' 모자를 쓰면 기능 추가와 그 기능의 테스트만 추가한다. 반면 '리팩터링' 모자를 쓰면 기능 추가는 절대 하지 않기로 다짐하고 코드 재구성만 신경쓴다.
전체 작업 시간이 10분 이내로 짧아도, 항상 내가 쓴 모자를 신경써야 한다.

2.3 리팩터링하는 이유

리팩터링하지 않으면 개발한 소프트웨어 내부 설계가 잘 썩는다.

아키텍처를 충분히 이해하지 못한 채 기능구현만을 위해 코드를 수정하다 보면 기반 구조가 무너지기 쉽다.

리팩터링한 소프트웨어는 이해하기 쉽다.

리팩터링을 해서 코드의 목적이 더 잘 드러나고 내 의도가 더 명확해지게 할 수 있다. 이해하기 좋은 코드를 작성하는 일은 단지 다른 사람을 위해서가 아니다. 사실 그 다른 사람이 바로 나 자신일 때가 많다.

리팩터링하면 버그를 쉽게 찾을 수 있다.

켄트 벡 왈. "난 뛰어난 프로그래머가 아니에요. 단지 뛰어난 습관을 지닌 괜찮은 프로그래머일 뿐이에요."
리팩터링하면서 프로그램의 구조를 명확하게 다듬으면 그냥 '이럴 것이다'라고 가정하던 점들이 분명히 드러나고, 버그를 지나치고 싶어도 지나칠 수 없을 정도까지 파악하게 된다.

리팩터링하면 프로그래밍 속도를 높일 수 있다.

내부 설계가 잘 된 소프트웨어는 새로운 기능을 추가할 지점과 어떻게 고칠지 쉽게 찾을 수 있다. 모듈화가 잘 되어 있으면 전체 코드베이스 중 작은 일부만 이해하면 된다. 내부 품질이 뛰어난 코드베이스는 새 기능 구축을 돕는 견고한 토대가 된다.

2.4 언제 리팩터링해야 할까?

3의 법칙

Don Roberts가 제시한 가이드이다.
1. 처음에는 그냥 한다.
2. 비슷한 일을 두 번째로 하게 되면(중복이 생겼다는 사실에 당황스럽겠지만), 일단 계속 진행한다.
3. 비슷한 일을 세 번째 하게 되면 리팩터링한다.

준비를 위한 리팩터링: 기능을 쉽게 추가하게 만들기

새로운 기능을 추가하기 직전 '리팩터링' 모자를 쓴다.

이해를 위한 리팩터링: 코드를 이해하기 쉽게 만들기

profile
디오디오

0개의 댓글