리팩터링을 해야하는 이유는 무엇인가요?

리팩터링은 소프트웨어의 모든 문제점을 해결하는 만병통치약을 아니지만,

코드를 건강한 상태로 유지하는 데 도와주는 약임은 분명하다. 

 

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

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

아키텍처를 충분히 이해하지 못한 채 단기 목표만을 위해서 코드를 수정하다 보면, 기반 구조가 무너지게 된다.

 

코드 구조가 무너지기 시작하면, 악효과가 누적된다.

코드만으로 설계를 파악하기 어려워질수록 설계를 유지하기 어려워지고, 설계가 부패되는 속도는 더욱 빨라진다.

 

같은 일을 하더라도 설계가 나쁘면 코드가 길어지기 십상이다.

사실상 같은 일을 하는 코드가 여러 곳에 나타날 수 있기 때문이다.

 

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

코드량을 줄인다고 시스템이 빨라지는 것도 아니고, 프로그램의 용량이 속도에 영향을 주는 경우도 별로 없다.

하지만 코드량이 주면, 수정하는 데 드는 노력은 크게 달라진다.

 

코드가 길수록 실수 없이 수정하기 어려워진다.이해해야 할 코드량도 늘어난다. 비슷한 일을 하는 코드가 산재해 있다면, 한 부분만 살짝 바꿔서는 시스템이 예상대로 작동하지 않을 수 있다.

반면 중복 코드를 제거하면, 모든 코드가 언제나 고유한 일을 수행함을 보장할 수 있으며, 이는 바람직한 설계의 핵심이다.

 

 

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

: 프로그래밍은 여러 면에서 마치 컴퓨터와 대화하는 것과 같다.

컴퓨터에게 시킬 일을 표현하는 코드를 작성하면, 컴퓨터는 정확히 시킨대로 반응한다.

 

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

프로그램이은 결국 내가 원하는 바를 정확히 표현하는 일이다.

 

그런데 내 소스 코드를 컴퓨터만 사용하는 것이 아니다.

예컨데 몇 달이 지나 누군가 내 코드를 수정하고자 읽게 될 수 있다.

 

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

코드를 컴파일 하는 데 시간이 살짝 더 걸린다고 누가 뭐라 하겠는가?

 

하지만 다른 프로그래머가 내 코드를 제대로 이해했다면 한 시간에 끝낼 수정을 일주일이나 거린다면 사정이 달라진다.

 

문제는 프로그램을 동작시키는 데만 신경 쓰다 보면 나중에 그 코드를 다룰 개발자를 배려하지 못한다는 데 있다.

코드를 이해하기 쉽게 만들려면 일하는 리듬에 변화를 줘야 한다.

 

리팩터링은 코드가 더 잘 읽히게 도와준다.

잘 작동하지만 이상적인 구조는 아닌 코드가 있다면, 잠깐 시간을 내서 리팩터링해보자.

 

그러면 코드의 목적이 더 잘 드러나게, 다시 말해 내 의도를 더 명확하게 전달하도록 개선할 수 있다.

 

단지 다른 사람을 배려하기 위해서가 아니다. 사실 그 다른 사람이 바로 나 자신일 때가 많다.

그래서 더더욱 리팩터링이 중요하다. 

저자 같은 경우는 코드를 보면 알 수 있는 것들은 의도적으로 기억하지 않는다.

자신의 기억 용량을 초과할까봐 두렵기 때문이다.

그래서 기억할 필요가 있는 것들은 최대한 코드에 담으려고 한다.

 

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

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

리팩터링을 하면 코드가 하는 것을 깊이 파악하게 되면서 새로 깨달은 것을 고바로 코드에 반영하게 된다.

프로그램의 구조를 명확하게 다듬으면 그냥 '이럴 것이다'라고 가정하던 점들이 분명히 드러나는데, 버그를 지나치려야 지나칠 수 없을 정도까지 명확해진다. 리팩터링은 견고한 코드를 작성하는 데 무적 효과적이다.

 

이 사실은 켄트 벡의 말을 떠올리게 한다.

"나는 뛰어난 프로그래머는 아니에요. 단지 뛰어난 습관을 지닌 괜찮은 프로그래머일 뿐이에요."

 

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

위 3가지 장점을 한 마디로 하면 다음과 같다.

"리팩터링을 하면 코드 개발 속도를 높일 수 있다."

 

얼핏 그 반대가 아닌가 생각할 수 있다. 내가 사람들에게 리팩터링에 대해 설명하면 품질을 높일 수 있다는 점에 대해서는 대부분 쉽게 수긍한다.

내부 설계와 가독성이 개선되고 버그가 줄어든다는 점은 모두 품질 향상에 기여한다.

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

 

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

 

새로운 기능을 추가할수록 기존 코드베이스에 잘 녹여낼 방법을 찾는 데 드는 시간이 늘어난다는 것이다.

게다가 기능을 추가하고 나면 버그가 발생하는 일이 잦고, 이를 해결하는 시간은 한층 더 걸린다.

 

코드베이스는 패치에 패치가 덧붙여지면서 프로그램의 동작을 파악하기가 거의 고대 유적 발굴만큼 어려워진다.

 이러한 부담이 기능 추가 속도를 계속 떨어뜨리면서, 차라리 처음부터 새로 개발하는 편이 더 낫겠다고 생각하는 지경에 이른다.

 

그런데 어떤 팀은 이와 전혀 다른 양상을 보인다.

이들은 기존에 작성한 코드를 최대한 활용할 수 있어서 새 기능을 더 빨리 추가한다.

 

이렇게 차이 나는 원인은 소프트웨어의 내부 품질에 있다.

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

 

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

코드가 명확하면 버그를 만들 가능성도 줄고, 버그를 만들더라도 디버깅하기가 훨씬 쉽다.

내부 품질이 뛰어난 코드베이스는 새 기능 구축을 돕는 견고한 토대가 된다.

 

나는 이 효과를 설계 지구력 가설이라고 부른다. (Design Stamina Hypothsis)

내부 설계에 심형를 기울이면 소프트웨어의 지구력이 높아져서 빠르게 개발할 수 있는 상태를 더 오래 지속할 수 있다.

정말 그런지는 증명할 수 없어서 '가설'이라고 표현했다.

 

하지만 나뿐만 아니라 지금까지 일하면서 알게 된 수많은 뛰어난 프로그래머들의 경험이 이를 뒷받침한다.

 

20년 전만 해도 설계를 잘하려면 코딩을 시작하기 전에 설계부터 완벽히 마쳐야 한다는 것이 정설이었다.

코딩 단계에 한번 들어서면 코드가 부패할 일만 남기 때문이다.

 

한편, 리팩터링을 하면 이를 바로잡을 수 있다.

앞에서 본 것처럼 리팩터링하면 기존 코드의 설계를 얼마든지 개선할 수 있으므로, 설령 프로그램 요구사항이 바뀌더라도 설계를 지속해서 개선할 수 있다.

처음부터 좋은 설게를 마련하기란 매우 어렵다.

그래서 빠른 개발이라는 숭고한 목표를 달성하려면 리팩터링이 반드시 필요하다.