리팩터링, 아키텍쳐, YAGNI

- 리팩터링 2판 중

 

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

내가 프로그래밍을 시작한지 얼마 되지 않은 시절에는

코딩을 시작하기 전에 소프트웨어 설계와 아키텍처를 어느정도, 심지어 거의 완료해야한다고 배웠다.

일단 코드로 작성된 뒤로는 아키텍처를 바꿀 수 없었고, 부주의로 인해 부패할 일만 남았다고 여기곤 했다.

 

리팩터링은 이런 관점을 크게 바꿔놓았다.

 그래서 나는 수년 동안 운영되던 소프트웨어라도 아키텍쳐를 대폭 변경할 수 있었다.

이 책의 부제처럼 리팩터링으로 기존 코드의 설계를 개선할 수 있다.

하지만 앞에서 말했듯이 레거시 코드는 변경하기 어려울 때가 많다.

 

 특히, 탄탄한 테스트가 뒷받침해주지 못하면 더더욱 어렵다.

 

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

코딩 전에 아키텍처를 확정지으려 할 때의 대표적인 문제는 소프트웨어 요구사항을 사전에 모두 파약해야 한다는 것이다.

 

하지만 막상 해보면 실현할 수 없는 목표일 때가 많다. 우리는 소프트웨어를 실제로 사용해보고 업무에 미치는 영향을 직접 확인하고 나서야 정말로 원하는 바를 알게되는 경우가 허다하다.

 

한 가지 방법은 향후 변경에 유연하게 대처할 수 있는 유연성 매커니즘을 소프트웨어에 심어두는 것이다.

가령 함수를 정의하다 보면 범용적으로 사용할 수 있겠다는 생각이 들 때가 있다.

그래서 다양한 예상 시나리오에 대응하기 위한 매개변수들을 추가한다.

 

이러한 매개변수가 바로 유연성 매커니즘이다. 물론 매커니즘들이 대게 그렇듯 치러야할 비용이 있다.

매개변수를 생각나는 대로 추가하다 보면 당장의 쓰임에 비해 함수가 너무 복잡해진다.

 

또한 깜박 잊은 매개변수가 있다면 앞서 추가해둔 매개변수들 때문에 새로 추가하기가 더 어려워진다.

 

간혹 유연성 매커니즘을 잘못 구현할 떄도 있다.

요구사항이 당초 예상과 다르게 바뀌기 때문일 때도 있고, 내가 설계한 매커니즘 자체에 결함이 있어서 일 때도 있다.

 

이 모든 상황을 고려하다 보면, 유연성 매커니즘이 오히려 변화에 대응하는 능력을 떨어뜨릴 때가 대부분이다.

 

리팩터링을 활용하면 다르게 접근할 수 있다. 앞으로 어느 부분에 유연성이 필요하고, 어떻게 해야 그 변화에 가장 잘 대응할 수 있을 지 추측하지 않고, 그저 현재까지 파악한 요구사항만을 해결하는 소프트웨어를 구축한다.

 

단, 이 요구를 멋지게 해결하도록 설계한다. 진행하면서 사용자의 요구사항을 더 잘 이해하게 되면 아키텍처도 그에 맞게 리팩터링해서 바꾼다.

 

그 과정에서 소프트웨어의 복잡도에 지장을 주지 않는 매커니즘은 마음껏 추가하지만, 복잡도를 높일 수 있는 유연성 매커니즘은 반드시 검증을 거친 후에 추가한다.

 

호출하는 측에서 항상 같은 값을 넘기는 매개변수는 매개변수 목록에 넣지 않는다.

 

그러다 매개변수를 추가해야할 시점이 오면 간단한 리팩터링 기법인 "함수 매개변수화하기" 로 해결한다.

예상되는 변경을 미리 반영하는 리팩터링을 미루면 나중에 얼마나 어려워질지를 가늠해보면 판단에 도움될 때가 많다.

리팩터링을 미루면 훨씬 힘들어진다는 확신이 들 때만 유연성 매커니즘을 미리 추가한다.

 

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

애그니를 문자 그대로 해석해서 적용할 때도 있지만, 아키텍처를 전혀 고려하지 말라는 뜻은 아니다. 내가 바라보는 애그니는 아키텍처와 설계를 개발 프로세스에 녹이는 또 다른 방식이며, 리팩터링의 뒷받침 없이는 효과를 볼 수 없다.

 

애그니를 받아들인다고 해서 선제적인 아키텍처에 완전히 소홀해도 된다는 뜻은 아니다.

리팩터링으로 변경하기 어려워서 미리 생각해두면 시간이 절약되는 경우도 얼마든지 있다.

다만 이제는 둘 사이으이 균형점이 크게 달라졌다.

 

나는 나중에 문제를 더 깊이 이해하게 됐을 때 처리하는 쪽이 훨씬 낫다고 생각하는 편이다.

이러한 경향은 진화형 아키텍처 원칙이 발전하는 계기가 됐다.