뉴스스탠드 설계 발자취
뉴스스탠드에서 생각해봐야할 기능은 크게 4가지입니다. tab, option, sub, nav
- 뉴스스탠드 그리드 보기 (tab)
- 전체 언론사 (option)
- 내가 구독한 언론사 (option)
- 뉴스스탠드 리스트 보기 (tab)
- 전체 언론사 (option)
- 내가 구독한 언론사 (option)
- 구독하기 버튼 (sub)
- 페이지 네이션 버튼 (nav)
처음 시도는 뉴스스탠드 그리드 보기 페이지를 만들 때 입니다.
첫 페이지를 만들었기 때문에 HTML과 이벤트, 로직등이 한 파일로 관리 되었습니다.
이에 두 번째 페이지를 개발할 시 중복된 코드가 발생했고, 유지보수가 어려웠습니다.
이를 해결하기 위해 그리도와 리스트의 화면을 분리한 후 그에 따른 각 이벤트 파일을 따로 분리하게 되었습니다. 이에 분리해야할 기준을 3가지로 잡았습니다. (이벤트 로직, 비즈니스 로직, 뷰)
이를 토대로 개발을 진행하니 각 역할이 명확해 졌지만 이벤트와 비즈니스 로직을 연결하는데 여러가지로 엮다 보니 오히려 코드가 복잡해졌고(export, import 남발) 이벤트 처리에 어려움을 겪었습니다.
새로운 기능이 계속 추가되는 상황에서 어떻게 해야 효과적으로 개발을 할 수 있을지 설계에 대한 고민을 하기 시작했습니다.
두 번째 코드를 살펴보니 MVC패턴으로 개발을 하는 중이였고, 단점이 명확하게 보였습니다. 그래서 Vuex를 생각하게 되었고 이에 Store를 추가하여 Flux패턴처럼 단방향으로 데이터 흘러가게 개발했습니다.
Flux 패턴을 적용해보니 기존 MVC패턴의 강한 의존성이 없어졌고 기능추가를 쉽게 할 수 있게 되었습니다.
하지만 데이터 관점으로 볼 때 유지보수가 편해 보였지만 Store가 커지면서 스토어의 상태 값을 바꾸는 로직들이 추가되어 관리가 어려워졌습니다. 무분별한 Store 사용 보단 꼭 변경이 필요하고 진짜 글로벌한 상태에서 사용해야 할 거 같습니다.
옵저버 패턴을 적용했습니다.
옵저버 패턴을 사용하니 model과 Store간에 느슨한 의존성이 형성되었습니다. 단순히 Model은 Store를 구독하기 때문에 Model과 Store간에 관계가 명확해 졌고 코드 가독성 측면에서도 더 좋아진거 같습니다.
스토어가 커지면서 스토어의 역할이 불분명해 졌지만, 옵저버 패턴추가로 Model부분에서 구독해야할 데이터를 파악할 수 있어 스토어의 역할 파악과 이벤트의 흐름 예측 가능해졌습니다.
Flux패턴과 마찬가지로 데이터의 흐름은 단방향으로 흐르나 옵저버 패턴은 객체의 관계에 집중한 느낌이고 Flux패턴은 데이터 흐름에 집중한 느낌이었습니다.
상황에 따라 적절하게 두 패턴을 활용하면 될거 같습니다.