좀 더 쉽게 개발하기 위한 도구나 프레임워크들을 살짝 걷어내보면 결국은 정통적인 이론과 그 이해도로 통한다.

당연한 소리다. 근데 왜 이걸 이야기하냐고 묻는다면…

요즘 내가 좀 당한 게 있어서 그렇다. ㅠㅠ

현재 개발중인 응용 프로그램에는 이전 개발자가 개발한 걸 이어받았다. 그렇다보니 들어있는 프레임워크나 기술들 중에서도 여러모로 녹아있는 기술들이 있다. 그 중에서도 제일 회사 사람들을 골썩인 것이 바로 Prism이었다. WPF 하시는 분들은 잘 아실 것이다. 모듈화를 통한 유연화와 MVVM 패턴, CompositeView, Event Aggregator들을 이용하여 독립적인 컴포넌트들 간의 느슨한 결합들… 이것들을 강조하면서 철저하게 설계 중심의 어플리케이션 제작을 도와준다는 그 유명한 녀석…

결국 이것도 MVVM 디자인 패턴을 정착시키면서 동시에 추가적으로 Prism에서 제공하는 기능들을 사용하여 좀 더 쉽게 개발하기 위한 것이다.

근데 그렇게 좋은 의도대로 해서 좋게 짜여지면 좋은데….

설계에 대한 이해를 못해서 제대로 꼬으고 꼬으다 보니깐 코드가 느슨하지 않았다. 오히려 클래스간 엄청 타이트한 건 기본적인 것에 코드 비하인드를 위한 최소 5단계 이상의 상속, 테스트 불가능한 코드들, 재사용성 제로의 컴포넌트들, 컨트롤 속성에 대한 몰이해… 거기에 Prism documentation에 없으면 못하는 거라고 우겨대던 그 깡다구….

사실 앞에 지적한 부분은 Prism을 못사용한 것이 아니라 권장받은 MVVM 패턴에서 제일 일어나선 안되는 코드 유형을 다 모아놨다. 아무리 도움되는 코드 도큐먼트를 영어로 잘 읽어내고, 그리고 나서 적용해보니 오케이! 안되면 몰라! 이런 태도도 좀 그렇지만 이해도의 핵심은 Prism에 대한 이해가 아니었다.

그래서 좀 여러모로 코드를 스파게티로 하더라도 어느 정도 걷어내고 수정하고 덮어씌우고 갈아엎으면서 여러 요령을 피우면서 이전 개발자가 못한다 못한다 노래부르고 퇴사하면서 남긴 것들을 전부 다 구현해냈다. (그리고 프로그램 출시 얼마 안남았다. 글 쓰는 시점으로는 말이지..ㅇㅅㅇ)

난 WPF를 하면서 Prism을 대충 보기만 하고 무시했던 지라 솔직히 보면 좀 알겠지 하다가 전 개발자의 잘못된 코드를 보고 아우 썅 그랬었다. 그러다가 MVVM만 일단 좀 보고 싶어서 지금 취미로 만들고 있는 머드게임에 MVVM 설계를 이용한 방식을 적용해봤다. Prism? 안쓰고도 솔직히 할 수 있다. 요즘 MVC 패턴에 대해서 다들 잘 이애하고 하다보니 프레임워크 없이도 맨땅에 다 구현할 수 있듯, 패턴이기 때문에 패턴에서 필요한 요소만 구현할 수 있다면 맨땅에도 맞춰서 구현할 수 있다. 프레임워크는 그걸 그냥 도와주는 녀석일뿐….

이렇게 해보고 나니깐 전 개발자의 코드에 대해서 여러모로 잘못된 이론정보와 이해도가 여실히 보였다. 가뜩이나 다른 곳에 디자인 패턴을 잘못 쓴 것이 보였기 때문에 프로그램 전반적인 부분에 영향이 가는 패턴이 문제가 심각하다는 걸 보고는 좀 속이 많이 끓었다만…. 그건 내가 나중에 바로잡아가면 되는 거고….

이걸 통해서도 역시 전통적인 이론과 그 이해는 어디 가지 않는구나라는 생각을 엄청 하게 되었다. 하도 프레임워크들이 넘쳐나는 세상에 살다보니 그쪽에 휩쓸리는 신입 개발자들도 좀 많이 보고 하는데… 나중에 중요하게 남거나 실력으로써 남아나는 부분에 대해서는 변함없다는 걸 여러모로 느끼게 해줬다.

p.s. 그냥 한국에서처럼 만들어서 완성만 하면 되는 것에서 좀 더 늦춰가다보니 이런 것들도 생각을 좀 해보게 되네…

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.