2. 리팩터링 원칙

이 포스팅은 리팩터링 2판으로 학습한 내용을 토대로 정리한 포스팅입니다.

 

리팩터링이라는 용어는 명사로도 쓸 수 있고, 동사로도 쓸 수 있고 그에 따라 의미가 달라집니다.

 

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

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

 

위의 의미를 통해 리팩터링이란 특정한 방식에 따라 코드를 정리하는 것만이 리팩터링이라고 할 수 있습니다.

 

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

 

리팩터링은 전과 후의 코드가 똑같이 동작해야 하며,

리팩터링의 목적은 코드를 이해하고 수정하기 쉽게 만드는 것이기 때문에 성능은 좋아질 수도, 나빠질 수도 있습니다.

 

2.2 두 개의 모자

켄트 벡은 두개의 모자로 '기능추가', '리팩터링'을 비유했습니다.

기능을 추가할 때는 '기능추가' 모자를 쓴 다음 기존 코드는 수정하지 않고 오로지 새 기능을 추가하기만 합니다.

반면 리팩터링의 경우 '리팩터링' 모자를 쓴 다음 기능 추가는 절대 하지 않고 오로지 코드 재구성만 합니다.

이는 개발자가 스스로 무엇을 하고 있는지 알고 작업을 해야 하는 것과 같은 말이라고 생각합니다.

지금 내가 기능을 추가하는 것인지 코드를 리팩토링 하는 것인지 자각하고 있어야 한다는 것입니다.

기능을 추가하다 코드가 이상해서 리팩터링 하고, 리팩터링하다가 추가하고 있던 기능과 오류가 나서 다시 수정하고...하다 보면 뒤돌아봤을 때 나는 지금 무엇을 하고 있는지 헷갈릴 수 있기 때문에 내가 하고 있는 작업을 명확하게 구분해야 합니다.

 

2.3 리팩터링하는 이유

• 리팩터링하면 소프트웨어 설계가 좋아집니다.
• 리팩터링하면 소프트웨어를 이해하기 쉬워집니다.
• 리팩터링하면 버그를 쉽게 찾을 수 있습니다.
• 리팩터링하면 프로그래밍 속도를 높일 수 있습니다.

https://origogi.github.io/refactoring/chapter-2/

처음부터 좋은 설계를 마련하기란 매우 어렵다. 그래서 빠른 개발이라는 숭고한 목표를 달성하려면 리팩터링이 반드시 필요하다.
(p.85)

 

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

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

 

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

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

 

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

코드를 수정하려면 먼저 그 코드가 하는 일을 파악해야 합니다.

워드 커닝햄이 말하길, 리팩터링하면 머리로 이해한 것을 코드에 옮겨 담을 수 있습니다.

 

쓰레기 줍기 리팩터링

간단히 수정할 수 있는 것은 즉시 고치고, 시간이 좀 걸리는 일은 짧은 메모만 남긴 다음, 하던 일을 끝내고 나서 처리합니다. 이것이 이해를 위한 리팩터링의 변형인 쓰레기 줍기 리팩터링입니다.

 

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

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

나(마틴 파울러)는 리팩터링 시간을 일정에 따로 잡아두지 않고, 대부분의 리팩터링을 다른 일을 하는 중에 처리합니다.

 

무언가 수정하려 할 때는 먼저 수정하기 쉽게 정돈하고, 그런 다음 쉽게 수정하자.
(p.88)

 

오래 걸리는 리팩터링

리팩터링은 대부분 몇 분 안에 끝나며 길어야 몇 시간 정도이지만, 가끔 팀 전체가 달려들어도 몇 주는 걸리는 대규모 리팩터링도 있습니다.

저자인 마틴 파울러님은 팀 전체가 리팩터링에 매달리는 데는 회의적이며, 그보다 몇 주에 걸쳐 조금씩 해결해나가는 편이 효과적일 때가 많다고 합니다.

 

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

코드 리뷰는 개발팀 전체에 지식을 전파하는 데 좋습니다.

코드 리뷰를 통해 경험이 더 많은 개발자의 노하우를 더 적은 개발자에게 전수할 수 있습니다.

 

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

`리팩터링은 누적된 오류를 잡는 일이거나, 혹은 가치 있는 기능을 만들어내지 못하는 작업` 이라고 오해하여 리팩터링이 금기어가 돼버린 조직도 있습니다. 리팩터링을 위한 일정을 몇 주씩 잡는 개발팀을 보면 오해는 더욱 커집니다.

기술을 모르는 상당수의 관리자와 고객이 있는 상황이라면 `리팩터링한다고 말하지 말라`고 조언합니다.

프로 개발자의 역할은 효과적인 소프트웨어를 빨리 만드는 것이며, 소프트웨어를 빠르게 만드는 데에 있어 리팩터링은 매우 효과적입니다.

프로 개발자에게 주어진 임무는 새로운 기능을 빠르게 구현하는 것이고, 가장 빠른 방법은 리팩터링입니다.

 

리팩터링 하지 말아야 할 때

지저분한 코드를 발견해도 굳이 수정할 필요가 없다면 리팩터링 하지 않습니다.

리팩터링하는 것보다 처음부터 새로 작성하는 게 쉬울 때도 리팩터링 하지 않습니다.

 

사람들이 빠지기 쉬운 가장 위험한 오류는 리팩터링을 `클린 코드`나 `바람직한 엔지니어링 습관`처럼 도덕적인 이유로 정당화하는 것입니다.
리팩터링의 본질은 코드 베이스를 예쁘게 꾸미는 데 있지 않습니다.
오로지 경제적인 이유로 하는 것입니다.
리팩터링은 개발 기간을 단축하고자 하는 것입니다.
기능 추가 시간을 줄이고, 버그 수정 시간을 줄여줍니다.
...
리팩터링하도록 이끄는 동력은 어디까지나 경제적인 효과에 있습니다.
(p.93)

 

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

리팩터링은 소프트웨어 아키텍처를 바라보는 관점을 완전히 바꿔놓았습니다.

리팩터링이 아키텍처에 미치는 실질적인 효과는 요구사항 변화에 자연스럽게 대응하도록 코드 베이스를 잘 설계해준다는 데 있습니다.

 

리팩터링을 활용하면 먼 미래까지 추측하지 않고 현재까지 파악한 요구사항만을 해결하는 소프트웨어를 구축합니다.

이런 식으로 설계하는 방식을 간결한 설계, 점진적 설계, YAGNI 등으로 부릅니다.

 

YAGNI: 'you aren't going to need it'

 

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

팀으로 개발하면서 리팩터링을 하려면 각 팀원이 다른 사람의 작업을 방해하지 않으면서 언제든지 리팩터링할 수 있어야 합니다.

 

2.8 리팩터링과 성능

리팩터링을 하면 소프트웨어가 느려질 수도 있는 건 사실이지만, 그와 동시에 성능을 튜닝하기는 더 쉬워집니다.

성능에 대한 흥미로운 사실은, 대부분 프로그램은 전체 코드 중 극히 일부에서 대부분의 시간을 소비한다는 것입니다.그래서 코드 전체를 고르게 최적화한다면 그중 90%는 효과가 거의 없기 때문에 시간 낭비인 셈입니다.

그래서 프로파일러로 프로그램을 분석하여 시간과 공간을 많이 잡아먹는 지점을 알아냅니다. 그리고 그 부분들을 개선하는 식으로 리팩터링합니다.

프로그램을 잘 리팩터링해두면 두 가지 면에서 도움이 됩니다.

• 성능 튜닝에 투입할 시간을 벌 수 있습니다.
• 선응을 더 세밀하게 분석할 수 있습니다.

리팩터링은 성능 좋은 소프트웨어를 만드는데 기여합니다. 단기적으로 보면 리팩터링 단계에서 성능은 느려질 수도 있지만, 최적화 단계에서 코드를 튜닝하기 훨씬 쉬워지기 때문에 결국 더 빠른 소프트웨어를 얻게 됩니다.