[리팩토링] Chapter 2. 리팩터링 원칙

사전적 의미

리팩터링 : [명사] 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이래하고 수정하기 쉽도록 내부 구조를 변경하는 기법

리팩터링 : [동사] 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러자기 리팩터링 기법을 적용해서 소프트웨어를 재구성한다.

리팩터링 정의

• 커드를 정리하는 작업을 모조리 리팩터링 이라고 표현하는데 특정한 방식 에 따라 코드를 정리하는 것만이 리팩터링이다.

“누군가가 리팩터링하다가 코드가 깨져서 며칠이나 고생했다.” 라고 한다면, 십중팔구 리팩터링한 것이 아니다.

• 리팩터링 과정에서 발견된 버그는 리팩터링 후에도 그대로 남아 있어야 한다.

• 리팩터링은 성능 최적화와 비슷하며 리팩터링의 목적은 코드를 이해하고 수정하기 쉽게 만드는 것이다.

두 개의 모자

기능을 추가할 때는 기능 추가 모자를 쓴 다음 기존 코드를 절대 건드리지 않고 새 기능을 추가하기만 한다. 리팩터링 모자를 쓴 다음 기능 추가는 절대로 하지 않고 오로지 코드 재구성에만 전념한다.

리팩터링하는 이유

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

리팩터링하지 않으면 소프트웨어의 내부 설계가 썩기 쉽다. 시간이 지나면 코드 구조가 무너지기 시작하면 악효과가 누적된다. 같은 일을 하더라고 설계가 나쁘면 코드가 길어지기 십상이다. 그래서 중복 코드 제거는 설계 개선 작업의 중요한 축을 차지한다.

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

프로그래밍은 여러 면에서 마치 컴퓨터와 대화하는 것과 같다. 그래서 컴퓨토에게 시키려는 일과 이를 표현한 코드의 차이를 최대한 줄여야한다.

리팩터링은 코드를 잘 읽히게 도와준다. 그리고 코드의 목적이 더 잘 드러나게 내의도를 더 명확하게 전달하도록 개선할 수 있다.

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

코드를 이해하기 쉽다는 말은 버그를 찾기 쉽다는 말이다.

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

내부 설계가 잘 된 소프트웨어는 새로운 기능을 추가할 지점과 어떻게 고칠지를 쉽게 찾을 수 있다. 모듈화 가 잘 되어 있으면 전체 코드베이스 중 작은 일부만 이해하면 된다. 코드가 명확하면 버그를 만들 가능성도 줄고 디버깅하기가 훨씬 쉽다. 설령 프로그램의 요구사항이 바뀌더라도 설계를 지속해서 개선할 수 있다.

언제 리팩터링해야 할까?

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

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

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

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

코드를 수정하려면 먼저 그 코드가 하는 일을 파악해야 한다. 리팩터링을 하면 머리로 이해한 것을 코드에 옮겨 담을 수 있다.

랄프 존슨은 이런 초기 단계의 리팩터링을 밖을 잘 내다보기 위한 창문 닦기에 비유한다. 코드를 분석할 때 리팩터링을 해보면 깊은 수준까지 이해하게 된다.

쓰레기 줍기 리팩터링

간단히 수정할 수 있는 것은 즉시 고치고, 시간이 좀 걸리는 일은 짧은 메모만 남긴 다음, 하던 일을 끝내고 처리한다.
캠핑 규칙이 제안하듯, 항상 처음 봤을 때 보다 깔끔하게 정리하고 떠나자

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

리팩터링 일정을 따로 잡아두지 않고, 기능을 추가하거나 버그를 잡는 동안 리팩터링도 함께한다.

오래 걸리는 리팩터링

팀 전체가 리팩터링에 매달리기 보다는 주어진 문제를 몇 주에 걸쳐 조금씩 해결해가는 편이 효과적일 때가 많다.

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

코드 리뷰는 개발팀 전체에 지식을 전파하는데 좋다. 리팩터링은 코드 리뷰의 결과를 더 구체적으로 도출하는데 도움이 된다.

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

“리팩터링은 누적된 오류를 잡는 일이거나, 혹은 가치 있는 기능을 만들어내지 못하는 작업” 이라고 오해하여 리팩터링이 금기어가 돼버린 조직도 있다. 리팩터링을 위한 일정을 몇 주씩 잡는 개발팀을 보면 오해는 더욱 커진다.
하지만 리팩터링을 하면 소프트웨어를 빠르게 만드는 데 아주 효과적이다. 프로개발자에게 주어진 임무는 새로운 기능을 빠르게 구현하는 것이고, 가장 빠른 방법은 리팩터링이다. 그래서 리팩터링 부터 한다.

리팩터링하지 말아야 할 때

지저분한 코드를 발견해도 굳이 수정할 필요가 없다면 리팩터링을 하지 않는다. 리팩터링하는 것보다 처음부터 새로 작성하는 게 쉬울 때도 리팩터링하지 않는다.

리팩터링, 아키텍처, 야그니(YAGNI)

소프트웨어 설계와 아키텍쳐는 코드로 작성된 뒤로는 변경할수 없고 부주의로 부패할 밀만 남았다고 여기곤 했다.

리팩터링은 이런 관점을 크기 바꿔놓았다. 리팩터링을 통해 수년 동안 운영되던 소프트웨어라도 아키텍쳐를 대폭 변경할 수 있었다.
리팩터링이 아키텍처에 미치는 실질적 효과는 요구사항 변화에 자연스럽게 대응하도록 코드 베이스를 잘 설계해준다에 있다.

코딩 전에 아키텍쳐를 확정지으려 할 때 대표적인 문제는 소프트웨어의 요구사항을 사전에 모두 파악해야한다는 것이다. 하지만 막상 해보면 실현할 수 없는 목표일 때가 많다.
한 가지 방법은 유연성 메커니즘을 적용하는 것이다. 예를 들어 함수를 작성할 때 다양항 예상 시나리오를 대응하기 위한 매개변수들을 추가한다. 하지만 모든 사항을 고려하려다 보면 유연성 메커니즘이 오히려 변화에 대응하는 능력을 떨어뜨릴 때가 많다.

리팩터링을 활용하면 다르게 접근할 수 있다. 그저 현재까지 파악한 요구사항만을 해결하는 소프트웨어를 구축한다. 단 이 요구를 멋지게 해결하도록 설계한다. 진행하면서 사용자의 요구사항을 더 잘 이해하게 되면 그에 맞게 리팩터링해서 바꾼다.
이런 식으로 설계하는 방식을 간결한 설계, 점진적 설계, YAGNI 등으로 부른다.

리팩터링과 소트트웨어 개발 프로세스

리팩터링이 퍼지기 시작한 것은 익스트림 프로그래밍(XP) 이 도입때문이다.

XP의 특징은 지속적인 통합, 자기 테스트, 리팩터링 등의 개성이 강하면서 상호 의존하는 기법들을 하나로 묶은 프로세스라는 점이다.

자가 테스트와 리팩터링을 묶어서 테스트 주도 개발(TDD) 이라 한다.

리팩터링과 성능

리팩터링하면 프로그래 성능이 느려질까봐 걱정하는 사람이 많다.
성능에 대한 흥미로운 사실은, 대부분 프로그램은 전체 코드 중 극히 일부에서 대부분의 시간을 소비한다는 것이다.

프로그램을 잘 리팩터링해두면 이런 식의 최적화에 두 가지 면에서 도움이 된다.

1. 성능 튜닝에 투입할 시간을 벌수 있다.
2. 리팩터링이 잘 되어 있는 프로그램은 성능을 더 세밀하게 분석할 수 있다.

리팩터링은 성능 좋은 소프트웨어를 만드는 데 기여한다.

Reference

리팩터링 2판