패턴을 활용한 리팩터링

49-50

발전적 설계

형편없는 설계에, 시스템은 불안정하고, 유지보수도 어려운 등의 너무도 흔한 문제가 있는 아주 오래된 시스템을 가진 회사가 있었다. 그 회사는 모든 것을 처음부터 개발하는 대신 시스템의 아키텍처를 리팩터링하기로 결정했다.

공통 코드에는 새로운 프레임워크 계층을 통해 접근하도록 했다. 애플리케이션이 공통 서비스를 사용할 때 반드시 프레임워크 계층을 통하도록 한 것이다. 프레임워크 프로그래머가 애플리케이션에 대한 충격을 최소화하면서도 프레임워크 내부 코드를 서서히 개선할 수 있게 하기 위함이었다.

그 회사는 프레임워크 팀을 만들기로 결정했다. 애플리케이션 팀은 공통 서비스에 대해서는 프레임워크 팀에 의존하게 된 것이다.

이 계획이 합당하게 들릴지는 모르겠지만, 사실 매우 위험한 발상이다. 프레임워크 팀원들이 애플리케이션의 요구사항을 놓치게 되면, 그들은 잘못된 코드를 만들어낼 것이다. 애플리케이션 팀원들은 필요한 것이 프레임워크에 없다면 마감일을 지키기 위해 프레임워크를 우회하거나 필요한 것이 완성되기를 기다리며 속도를 늦춰야 한다. 프레임워크를 우회하는 것은 레거시 아키텍처로 되돌아감을 의미하고, 코드를 기다리는 것 또한 좋은 선택이 아니다.

그보다 더 좋은 방안으로 ‘발전적 설계’라는 개념이 있다. 그 과정은 다음과 같다.

 

한 팀을 구성한다.

애플리케이션의 필요로부터 프레임워크를 이끌어낸다.

리팩터링을 통해 애플리케이션과 프레임워크를 지속적으로 개선한다.

 

한 팀이기 때문에 프레임워크와 애플리케이션은 서로 다른 방향으로 나가지 않는다. 애플리케이션의 실제 요구로부터 프레임워크를 만들기 때문에, 정말 필요한 프레임워크 코드만 생성된다. 이 과정에서 지속적인 리팩터링은 필수며, 이를 통해 프레임워크와 애플리케이션이 분리되도록 유지하는 것이다.

이 이야기에 나오는 회사는 발전적 경로를 따르기로 결정하고, 그들을 훈련시키고 안내해줄 코치를 고용했다. 프레임워크 개발에만 전념하는 팀을 따로 만들지 않은 것에 대한 초기의 우려에도 불구하고, 아키텍처는 지속적으로 개선됐으며, 고품질의 애플리케이션과 군더더기 없는 범용 프레임워크가 지속적으로 개발되었다.

여기서 리팩터링은 필수 요소다. 리팩터링이 그 팀으로 하여금 새로운 아키텍처를 효과적이고 효율적으로 발전시킬 수 있도록 한 것이다.

디자인 패턴, 리팩터링에 이어 프로그래밍 대가들의 진짜 내공을 보여준다.
프로그래밍을 때려 치워야 겠다. 
그냥 개발이나 해야지.