다양한 모듈을 모니터링 하는 페이지를 만든 경험이 있다. 한 7~8개의 모듈이 있고 해당 모듈의 지표들을 차트와 테이블로 나타내는 페이지인데 초기 개발 할 때 기본 구조를 아래와 같이 잡았다
module-monitoring
ㄴ module1-monitoring
ㄴ module1-chart-view
ㄴ module1-table-view
ㄴ module2-monitoring
ㄴ module2-chart-view
ㄴ module2-table-view
.
.
.컴포넌트에 대한 나의 정의
이렇게 나누는 이유는 먼저 컴포넌트에 대한 기본적인 정의였다. 컴포넌트는 하나의 기능을 수행하는 재 사용 가능한 단위라고 예전에 공부를 한 적이 있다. 물론 이 정의를 절대적으로 따라야하는 것은 아니지만 이 말이 맞다고 생각했고 웹을 구성 할 때 컴포넌트를 작고 단단하게 만들고 컴포넌트간의 관계를 유기적으로 구조를 짜야한다고 학습했다. 따라서 나는 모듈 별로 컴포넌트를 1차적으로 분리하고 각 view에 따라 chart와 table 을 나눴다.
기본 구조에 대한 설계와 문제점
그리고 모듈만 다르지 내부 구현 로직은 모두 같아서 module-monitoring service를 만들고 공통적으로 사용했다. 여기까지는 뭐 나쁘지 않게 구조도 잡고 코드를 작성한 것 같았는데, 문제는 새로운 기능을 추가할 때 마다 발생했다. 어쨌든 해당 모듈에 대한 모든 기능은 동시에 업데이트가 진행되어야하기 때문에 하나의 기능을 구현하려면 최대 7~8번의 같은 코드를 작성해야하고 또 7~8번의 테스트를 진행해야하는 다소 번거로운 작업이 진행되어야 했다.
고민점
과연 이것이 좋은 구조라고 할 수 있을까? 고민점이 많다. 컴포넌트 관점에서 보았을 때 각 기능별로 컴포넌트를 구성했고 상위 컴포넌트, 상상위 컴포넌트와의 이벤트 전달 또한 정상적으로 진행되고 있다. 하지만 유지 보수의 관점에서 보았을 때 작은 기능의 추가 및 삭제, 업데이트가 발생 한다면 또 번거로운 작업을 7~8번을 진행해야한다.
푸념
이것은 트레이드 오프의 관계인 것일까 아니면 내가 구조를 잘못잡은 것일까? 아니면 내가 컴포넌트에 대한 개념을 잘못 이해 한 것일까 ? 참 어려운 고민이다
++ 추가
팀장님에게 질문을 했다. 팀장님께서는 이러한 구조는 99.9% 지양해야하는 구조라고 ..
만약 본인이 위와 같은 페이지를 만든다면 객체지향적으로 탄탄한 인터페이스를 만들고 스펙에 따라 유동적인 페이지를 만들 것이라고 ..
오늘도 리펙토링 할 부분 추가 완료 ^^! 내가 구조를 잘못잡은거였다 ,,
