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

리팩토링은 소프트웨어 아키텍처를 바라보는 관점을 완전히 바꾸었다.

 

마틴이 프로그래밍을 시작한 지 얼마 되지 않은 시절에는 코딩을 시작하기 전에 소프트웨어 설계와 아키텍처를 어느 정도, 심지어 거의 완료해야 한다고 배웠다. 리팩토링은 이런 관점을 크게 바꿔놓았다.

 

리팩터링이 아키텍처에 미치는 실질적인 효과는 요구사항 변화에 자연스럽게 대응하도록 코드베이스를 잘 설계해준다는 데 있다. 코딩 전에 아키텍처를 확정지으려 할 때의 대표적인 문제는 소프트웨어 요구사항을 사전에 모두 파악해야 한다는 것이다. 하지만 막상 해보면 실현할 수 없는 목표일 때가 많다.

 

우리는 소프트웨어를 실제로 사용해보고 업무에 미치는 영향을 직접 확인하고 나서야 정말 원하는 바를 알게 되는 경우가 허다하다.

 

한 가지 방법은 향후 변경에 유연하게 대처할 수 있는 유연성 메커니즘을 소프트웨어에 심어두는 것이다. 가령 함수를 정의하다 보면 범용적으로 사용할 수 있겠다는 생각이 들때가 있다. 그래서 다양한 예상 시나리오에 대응하기 위한 매개변수들을 추가한다. 이런 매개변수가 바로 유연성 메커니즘이다.

 

물론 치러야 할 비용이 있다. 당장 쓰임에 비해 함수가 너무 복잡해진다. 또한 깜빡 잊은 매개변수가 있다면 앞서 추가해둔 매개변수들 때문에 새로 추가하기가 더 어려워진다. 간혹 유연성 메커니즘을 잘못 구현할 때도 있다.

 

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

 

리팩토링을 활용하면 다르게 접근할 수 있다. 그저 현재까지 파악한 요구사항만을 해결하는 소프트웨어를 구축한다. 단, 요구를 멋지게 해결하도록 설계한다. 진행하면서 사용자의 요구사항을 더 잘 이해하게 되면 아키텍처도 그에 맞게 리팩터링해서 바꾼다. 그 과정에서 작고 멋진 이름의 함수처럼 소프트웨어의 복잡도에 지장을 주지 않는 메커니즘은 마음껏 추가하지만, 복잡도를 높일 수 있는 유연성 메커니즘은 반드시 검증을 거친 후에 추가한다.

 

호출하는 측에서 항상 같은 값을 넘기는 매개변수는 매개변수 목록에 넣지 않는다. 그러다 매개변수를 추가해야 할 시점이 오면 간단한 리팩터링 기법인 함수 매개변수화하기로 해결한다.

 

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

 

이런 설계 방식을 간결한 설계, 점진전 설계, YAGNI(you aren't going to need it) 등으로 부른다.

 

YAGNI는 아키텍처를 전혀 고려하지 말라는 뜻이 아니다. 마틴이 바라보는 YAGNI는 아키텍처와 설계를 개발 프로세스에 녹이는 또 다른 방식이며, 리팩토링의 뒷받침 없이는 효과를 볼 수 없다.

 

YAGNI를 받아들인다고 해서 선제적인 아키텍처에 완전히 소홀해도 된다는 뜻이 아니다. 리팩터링으로는 변경하기 어려워서 미리 생각해두면 시간이 절약되는 경우도 얼마든지 있다.

 

다만, 이 둘 사이의 균형은 크게 달라졌다. 나중에 문제를 더 깊이 이해하게 됐을 때 처리하는 쪽이 훨씬 낫다고 생각한다.

 

---

 

리팩토링 - 마틴 파울러