요즘 여유가 있어서 인지, 아님 진짜 내가 업무적으로 가장 긴급하게 수행해야 하는 작업이
"유지보수 용이성"인지 모르겠지만, 유지보수 용이성을 위한 개선 작업을 진행 중이다.
Design Pattern을 마스터했다고는 말하기 어렵겠지만 그래도 책을 서너번 봤고, 관련된 다른 책들도 봤고, 많은 기사들도 봤는데도, 요즘 작업을 하고 있는 코드를 들여다 보면 아쉬움이 넘쳐 나온다. 이런 상황에 빠지게 된 원인을 나열해 보면...
- 정말로 편한 spring framework의 사용
- up-front가 아니여도 맨땅에 헤딩을 쉽게 해주는 eclipse와 같은 IDE
- 작업자들의 OOAD, Design Pattern, Refactoring 등에 대한 이해 부족(???)
이상을 들을 수 있을 것 같다.
특히 spring framework는 자체적으로 비난 받을 이유는 없지만 이로 인해 우리가 OO스럽지 않은 코드를 작성하고 있는 것 같다.
state, strategy, factory 등은 정말 자주 사용되는 패턴인데 spring에 익숙해지려고 노력하다 보면 뭐가 중요한지 잊고 한쪽에 치우치는 것 같다.
소프트웨어 개발자로서 나는 성능(performance, efficiency) 보다는 유연성(flexibility, maintainability, open to change)가 더 중요하게 여긴다. 특히 2년여에 걸쳐 성능 안정화를 이룬 시스템을 유지하고 있는 요즘의 현실로서는 더욱 그렇다.
코드의 양이 얼마 되지 않고 빨리 구현하는 것이 목적일 때는 Transactional Script는 아무런 문제가 되지 않았다. 오히려 OOAD에 대한 지식이 부족한 요새의 개발자들에게는 보다 빨리 구현할 수 있는 잇점을 제공했다.
하지만 코드에 지속적으로 기능을 추가해야 하는 요즘은 Transactional Script는 우리의 발목을 잡는다. 또 Hibernate과 같은 ORM을 사용하지 않고 쉽고, 제어가 편하다는 이유로 사용하기 시작한 iBatis는 Aggregate를 사용하기 어렵게 만들었다.
넘 아쉽다. 첨부터 다시 할 수 있는 기회가 있었으면 좋겠다. 지금 조금씩 개선(수정)하고 있지만 너무 괴롭다. 확 바꾸기가 어려우니...
혹 이글을 보신 분들 중 Java 기반으로 새로운 어플리케이션을 구현하고자 하는 분이 있다면 아래와 같은 사항들을 권하고 싶다.
- transaction script를 사용하지 말고 domain model을 사용하라.
- integration test, functional test 없이 unit test만으로도 최대한의 test coverage가 나오도록 노력하라.
- 유지보수 용이성 외의 다른 이슈(예. 성능)는 해당 이슈가 진정으로 필요할 때 까지 결정(고민???)을 최대한 미루라.
이와 관련하여 같은 고민을 한 분들이 있다면 정보를 공유할 수 있었으면 좋겠다.
