[Refactoring] 리팩터링 2판 Chapter.02 (리펙터링 원칙)

이번 챕터는 리펙터링의 원칙입니다. 챕터 2는 리팩터링을 정의하고, 원칙에 대해서 생각해보는 챕터 입니다.

이번 챕터는 리팩터링이 왜 필요한가? 또는 언제 해야하는가?에 대해서 설명하여 인상깊었던 부분만 정리하였습니다.

2.1 리팩터링 정의

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

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

동사적 의미에 더해서 생각해보면, 리팩터링 한 후에 소프트웨어의 동작이 달라졌다면, 리팩터링 한 것이 아니라고 생각할 수 있습니다. 자신은 리팩터링이라고 생각하고 했지만, 그 코드를 이해하지 못하고 다른 로직을 짜고 있었을 가능성이 큽니다. 그리고 리팩터링 하다가 갑자기 급한 일이 생기면 리팩터링을 바로 그만둘 수 있어야 합니다. 이것 또한 중간에 리팩터링을 하다가 그만둘 수 없으면, 리팩터링한 것이 아니라고 할 수 있습니다.

그리고 저자는 리팩터링을 ‘재구성’이라고 표현했는데, 이는 다음과 같은 의미를 내포하고 있습니다.

리팩터링의 목적은 코드를 사람이 이해하기 쉽게 만듦으로서 코드를 예쁘게 만드는 ‘클린코드’를 만드는것이 아니라, 오로지 생상성을 증대하기 위해서 하는 것이 목적이다.

이 말을 보고, 지금까지의 제 생각이 맞았음을 확인하였습니다. 제가 디자인 패턴이나 리팩터링을 가장 먼저 찾아 공부한 것은 구조를 잘 짜고, 코드를 잘 짜면 생산성이 증대된다는 기대가 있었기 때문입니다.

매 프로젝트를 하면서 느끼는것이 하나의 기능을 수정하는데 너무 많은 비용이 든다는 것입니다. 그렇게되면서 코드를 짜기 싫어지고, 제가 짠 코드를 보기 싫어지고, 버그가 나도 고치기 싫어졌습니다. 그래서 그것을 해결하고자 이 책들을 골라서 읽었는데, 도움이 많이 되는것 같습니다.

2.2 두개의 모자

그렇다면 리팩터링을 해야할 시기가 고민이었습니다. 언제 해야할까? 코드를 짜면서 즉시 바로 해야할까? 아니면 일단 기능을 완성하고 리팩터링을 해야할까?

위 질문에 저자는 다음과 같이 답합니다.

기능추가와 리팩터링을 분리해서 생각해라. 기능을 추가할 때는 기능만을 추가하는 모자를 쓴다고 생각하고, 리팩터링 할떄는 리팩터링만을 하는 모자를 쓴다고 생각해라. 그리고 이걸 자주 바꿔써라.

결국 하나에 집중해라 라는 말인 것 같습니다. 또, 리팩터링을 위해 기능추가를 하는 것을 미루지 말라 라고 이해가 되었습니다.

2.3 리팩터링 하는 이유

그렇다면, 리팩터링을 왜 하는걸까요?

리팩터링은 다음과 같은 효과가 있습니다.

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

결국 이 모든것이 생산성 증대에 영향을 미치고 있다고 볼 수 있습니다.

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

그렇다면 리팩터링은 언제 해야할까요?

저자가 소개하는 3의 법칙 이라는것이 있습니다.

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

리팩터링이 필요할 때 해라 라고 이해를 했습니다.

반대로, 리팩터링을 하지 말아야 할 때도 소개를 하고 있습니다. 무조건 지저분한 코드를 만났을 때 하는것이 아닌, 내부 동작을 이해해야 할 시점에 리팩터링해야 효과를 제대로 볼 수 있습니다.

앞으로 변할 가능성이 거의 없는 코드를 시간 들여서 리팩터링 한다는 것은 생산성을 높이자 라는 리팩터링의 의미에서 벗어나기 때문입니다.

또한, 새로 작성하는것이 빠를때도 리팩터링 하지 않습니다. 이거는 경험으로 판단해야 할 것 같습니다.

결국, 양팔저울에 리팩터링 함으로써 얻는 이점 vs 리팩터링 하는데 걸리는 시간 을 달아보고 결정해라 라는 말인것 같습니다. 생산성의 관점에서 아주 합리적인 계산 입니다.

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

이 장은 특히 깨달음이 많았습니다.

보통 소프트웨어를 만든다 라고 하면, 설계부터 완벽하게 하고 시작해야 한다고 알려져 있습니다. 저도 그렇게 생각했구요. 하지만 리팩터링개념을 도입하고 저자는 아키텍쳐를 수정/확장 하면서 소프트웨어를 만들 수 있게 되었다고 합니다.(물론 레거시 코드는 바꾸기 힘든게 맞습니다.)

또한, YAGNI 라는 원칙이 있습니다. (You Aren’t Gonna Need it!)

이 원칙은, 직역하면 너는 지금 그거 필요 없어! 입니다. 풀어서 설명하면 다음과 같습니다.

앞으로 어느 부분에 유연성이 필요하고 어떻게 해야 그 변화에 가장 잘 대응할 수 있을지 추측하지 않고, 그저 현재까지 파악한 요구사항만을 해결하는 소프트웨어를 구축한다. 단 이 요구를 멋지게 해결하도록 설계한다.

물론, 실무에서는 초단위로 바뀌는 기획자의 요구사항에 대비하기 위해 어느정도의 유연성은 확보해야겠지만, YAGNI 가 전달하고자 하는 말은, 이것에 매몰되어서 구현하는데 너무 오랜 시간이 걸리거나, 구조가 복잡해지도록 하지 마라! 라는 뜻이라고 생각합니다.

2.8 리팩터링과 성능

1장에서 다루었던 내용입니다. 반복문 쪼개기 등을 통해서 소프트웨어가 느려지지 않을까? 하는 걱정을 없애주는 단락 입니다.

저자는 오히려, 소프트웨어를 이해하기 쉽게 만들기 위해서 속도가 느려지는 방향으로 수정하는 경우가 많다고 합니다.

리팩터링하면 소프트웨어가 느려질 수도 있는 건 사실입니다. 하지만 그와 동시에 성능을 튜닝하기는 더 쉬워집니다. 튜닝하고 나서 그 뒤에, 성능 최적화가 필요한 곳에서 성능 최적화를 하면 됩니다.

또한, 성능에 대한 흥미로운 사실은, 대부분 프로그램은 전체 코드 중 극히 일부에서 대부분의 시간을 소비한다는 것입니다. 그래서 사실 최적화의 90%는 효과가 거의 없기 때문에 시간낭비인 셈입니다. 즉, 의도적으로 성능 최적화에 돌입하기 전까지는 성능에 신경쓰지 않고, 코드를 다루기 쉽게 만드는데 집중합니다.

Refactoring 카테고리 내 다른 글 보러가기