02 - 리팩터링 원칙 - 01

리팩터링 | 마틴 파울러 | 한빛미디어- 교보ebook

2.1 리팩터링 정의

소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법

 

올바른 리팩터링은 리팩터링이 중간에 멈춰도 항상 동작 보장한다.

 

한 번에 바꿀 수 있는 작업을 수많은 단계로 잘게 나눠서 작업하는 모습이 비효율적이라고 생각할 수 있다.

하지만 이렇게 잘게 나눔으로써, 각 단계들이 체계적으로 구성되며

무엇보다 디버깅하는 시간이 줄어든다.

 

리팩터링 전 후 코드는 똑같이 동작해야 한다.

 

리팩터링과 성능 최적화 차이

둘 다 코드를 변경하지만 프로그램 전반적인 기능은 유지한다.

목적이 다르다.

 

리팩터링은 코드를 이해하고 수정하기 쉽게 만드는 것이다.

프로그램 성능은 좋아질 수도 아빠질 수도 있다.

 

성능 최적화는 속도 개선에만 신경 쓴다.

코드는 다루기 어렵게 바뀔 수도 있다.

 

 

2.2 두 개의 모자

소프트웨어 개발 목적이 "기능 추가"인지 "리팩터링"인지 명확히 해야한다.

 

"기능 추가"모자를 썼다면, 절대 기존 코드를 건들지 않고, 기능 추가만한다.

진척도는 새 테스트를 추가해 통과하는지

"리팩터링"모자를 썼다면, 기존 코드만 재구성하고, 절대 기능 추가는 하지 않는다.

기능 추가 모자를 썼을 때 테스트를 누락한게 아니라면, 테스트도 추가하지 않는다.

 

물론 소프트웨어 개발 중 두 모자를 번갈아가며 쓸 수 있다.

 

 

2.3 리팩터링하는 이유

리팩터링하면 소프트웨어 설계가 좋아진다

리팩터링하지 않으면 소프트웨어 설계(아키텍처)가 썩기 쉽다.

 

어키렉터가 무너짐 => 코드만 봐서 설계 파악 어려움

설계 유지보수가 어려워짐

 

설계가 나쁘면 코드가 길어진다.

같은 코드가 여러 곳에 나타날 수 있기 때문이다.

그래서 중복 코드 제거는 설계 개선 작업의 중요한 축을 차지한다.

 

코드량이 준다고 성능이 좋아지진 않는다. 하지만 코드량이 줄면 수정에 드는 노력이 감소한다.

코드가 길 수록 실수 없이 수정하기 힘들어 진다.

 

코드 중복은 코드 한 부분만 살짝 바꿔서는 시스템이 예상대로 작동하지 않을 수 있다.

 

 

리팩터링하면 소프트웨어를 이해하기 쉬워진다

컴퓨터에게 시키려는 일과 이를 표현한 코드의 차이를 최대한 줄여야 한다.

 

내 소스 코드를 컴퓨터만 사용하는게 아니다, 나중에 누군가 내 코드를 수정하고자 일게 될 수 있다.

 

프로그래밍에서는 사람이 가장 중요하지만 이를 소홀하기 쉽다.

컴파일 시간이 몇초 더 걸리는 것 보다. 다른 프로그래머가 내 코드를 제대로 이해하도록 해 코드 수정 시간을 줄이는 것이 더 유익하다.

 

리팩터링은 코드를 더 잘 읽히게 한다.

 

리팩터링은 다른 사람은 배려하기 위해서가 아니다. 사실 그 다른 사람이 바로 나 자신일 때가 많다.

 

 

 

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

코드를 이해하기 쉬우면 버그를 찾기 쉽다.

리팩터링하면 코드가 하는 일을 깊이 파악하게 되면서, 버그를 찾기 수월해진다.

 

 

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

보통 리팩터링에 대해 설명하면 품질을 높인다는 것엔 이견이 없다.

내부 설계와 가독성 개선이 버그를 주어들게 하고 이는 모두 품질 향상에 직결된다.

하지만 리팩터링하는 데 시간이 드니 전체 개발 속도는 떨어질까봐 걱정할 수도 있다.

 

보통 한 시스템을 오래 개발 중인 개발자들과 얘기하다 보면 초기에는 진척이 빨랐지만 현재는 새기능을 하나 추가하는 데 훨씬 오래 걸린다는 말을 많이 한다.

기존 코드에 새 코드를 추가하기도 어렵고, 이 과정에서 버그는 덤이다.

기존 코드에 패치에 패치를 거듭하면서 프로그램 동작을 파악하기 더 어려워진다.

종국엔 새로 개발하는게 더 빠르겠다는 생각을 하게 된다.

 

내부 설계가 잘 된 소프트웨어는 새로운 기능을 추가할 지점과 어떻게 고칠지를 쉽게 찾을 수 있다.

 

모듈화가 잘 되어 있으면 전체 코드 베이스 중 작은 일부만 이해하면 된다.

 

 

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

프로그래밍을 하는 도중에 주기적으로 하는 것이 좋다. 

즉, 별도 시간을 마련하지 않고, 일상 코딩에 리팩터링을 녹여내는 것

3의 법칙

1. 처음에는 그냥 한다.
2. 비슷한 일을 두 번째로 하게 되면, 일단 계속 진행한다.
3. 비슷한 일을 세 번째 하게 되면 리팩터링한다.

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

리팩터링하기 가장 좋은 시점은 코드베이스에 기능을 새로 추가하기 직전이다.

 

현재 코드를 살펴보며, 구조를 살짝 바꾸면 다른 작업하기 쉬워질 부분을 찾는다.

예를 들어, 리터럴 값 몇 개가 방해되는 함수가 있다고 하자.

함수를 복제해서 그 값만 수정해서 써도 되지만, 이러면 나중에 변경이 생길 때 복제해서 쓴 코드 전부를 수정해야 한다. 심지어 여기저기 숨어있기까지 하다.

 

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

코드 수정을 위해선 먼저 그 코드가 하는 일 파악이 우선이다.

코드를 파악할 때마다 그 코드의 의도가 더 명확하게 드러나도록 리팩터링할 여지가 있는지 찾아보고 손본다.

조건부 로직 구조가 이상하지 않은지, 함수 이름이 이상한지 등

 

이 과정에서 코드를 어느 정도 이해하게 된다. 다만 이 기억을 그대로 코드에 반영해두지 않으면, 휘발성 기억이 되버린다.

 

리팩터링을 진행하면 코드가 깔끔하게 정리된다. 이렇게 정리되면 전에 안 보이면 설계가 눈에 들어온다.

 

리팩터링을 진행하면 코드를 보다 깊은 수준까지 이해하게 된다.

 

쓰레기 줍기 리팩터링

보이 스카우트 원칙에 기반한 내용

 

비효율적으로 처리하는 코드를 발견할 때가 있다.

 

로직이 쓸데없이 복잡하거나, 매개변수화한 함수 하나면 될 일을 거의 똑같은 함수 여러 개로 작성

 

이럴 때 간단하다면, 즉시 고치고, 시간이 걸린다면 메모를 해두고 하던 일을 마무리하고, 처리한다.

 

리팩터링의 멋진 점은 각각의 작은 단계가 코드를 깨뜨리지 않는다.

그래서 작업을 잘게 나눠 몇 달에 걸쳐 진행하더라도 문제가 되지 않는다.

계획된 리팩터링과 수시로 하는 리팩터링

준비를 위한 리팩터링, 이해를 위한 리팩터링, 쓰레기 줍기 리팩터링은 기회가 될 때만 진행한다.

 

개발에 들어가기 전에 리팩터링 일정을 따로 잡지 않고, 기능 추가나 버그를 잡는 동안 함께 진행한다.

즉, 프로그래밍 과정에 녹여 자연스럽게 한다.

 

리팩터링은 프로그래밍과 구분되는 별개의 활동이 아니다.

마치 if문 작성할 시간을 따로 잡지 않는 것과 같다.

 

계획된 리팩터링은 그동안 리팩터링에 소홀 했을 시 진행한다.

결과적으로 계획된 리팩터링을 안해도 되는 것이 좋다.(수시로 리팩터링 했다는 증거)

 

오래 걸리는 리팩터링

대부분의 리팩터링은 몇 분에서 몇 시간 사이다.

때론 팀 전체가 붙어도 몇 주 걸리는 대규모 리팩터링도 있다.

이런 상황에서도 팀 전체가 리팩터링에 매달리는 것은 효율적이지 않다.

리팩터링은 중간에 멈춰도 코드를 깨트리지 않는 다는 장점이 있기 때문에 팀원 각자가 리팩터링할 코드를 만다면, 각자 조금씩 개선하는 식이 효율적이다.

 

코드 리뷰에 리팩터링 활용하기

경험이 더 많은 개발자의 노하우를 더 적은 개발자에게 전수할 수 있다.

내 눈엔 명확한 코드가 다른 팀원에게 명확하지 않을 수 있다.

코드 리뷰를 하면 다른 사람의 아이디어를 얻을 수 있다는 장점도 있다.

관리자에게는 뭐라고 말해야 할까?

상당수의 관리자와 고객은 코드베이스 상태가 생산성에 미치는 영향을 모른다.

이런 상황에 있는 이들에게는 "리팩터링한다고 말하지 말라"고 조언한다.

 

개발자는 프로다. 프로 개발자는 소프트웨어를 최대한 빨리 만들어야 한다.

리팩터링은 결과적으로 소프트웨어 생산성을 높인다.

리팩터링하지 말아야 할 때

외부 API 다루듯 호출해서 쓰는 코드라면 지저분해도 그냥 둔다.

내부 동작을 이해해야 할 시점에 리팩터링해야 효과를 제대로 볼 수 있기 때문이다.

 

리팩터링하는 것 보다 처음부터 새로 작성하는 게 쉬울 때도 리팩터링하지 않는다. 이 판단은 노련한 개발자가 아니면 내리기 힘들다.