왜 고민하게 되었는가
프로젝트를 진행하다보면 많아지는 컴포넌트가 많아지고
이를 해결하기위해 컴포넌트의 추상화를 진행하고
또 현업에서는 재사용성을 더 높이기 위해 atomic 디자인 패턴이라는 것을 사용한다던데 하고 따라 했다가
복잡하고 모호해진 폴더구조와 제대로 진행하고있는지에 대한 의문이 생겨 작성하게 되었습니다.
디자인 패턴이란
디자인 패턴은 프로그래밍에서 반복적인 문제를 해결하고 유지보수성을 향상시키기 위해
많은 시간 시도한 방법들중 모범사례입니다.
생각해보기 전에는 엄청 획기적인 무언가 라고 생각을 하고 있었습니다.
비슷하게 했다는 것으로 뿌듯하고 ...
간단한 설명 : https://ittrue.tistory.com/550
[OOP] 디자인 패턴(Design Pattern)이란? - 장점 및 종류
디자인 패턴(Design Pattern)이란? 디자인 패턴은 개발하면서 발생하는 반복적인 문제들을 어떻게 해결할 것인지에 대한 해결 방안으로 실제 현업에서 비즈니스 요구 사항을 프로그래밍으로 처리하
ittrue.tistory.com
문제점
이제 문제는 프로젝트의 설계를 고려하지 않고 많이 쓰는 패턴이다 하고 적용할때 발생합니다.
문제를 설명하기에 가장 좋은 예시가 제 outfit-weather(기온에 따른 옷차림 추천 서비스)의 폴더구조입니다. ㅎㅎ....
Next.JS로 작성되었습니다.
폴더의 기준은 아래와 같습니다.
- atom: 가장 작은 구조
- molecules: 하나의 목적을 가지는 컴포넌트
- organism: 여러 molecules를 통해 여러 동작이있는 section
- Template: 여러 molecules를 통해 전체구조를 지니는 article
- page: provider나 Layout(Header, foorer)를 적용하는 곳
아래사진을 보면 드는 생각은 어디에 뭐가있지?, ~컴포넌트가 어디있더라 입니다.
closet 페이지를 수정하는데 ~컴포넌트가 어디있더라하고 page->Template 부터 내려가게 되는 것이죠
또한 잦은 중복 컴포넌트가 발생하며 확장성이 필요한 상황도 아니였습니다.
오히려 폴더구조를 유지하기위해 코드의 복잡도가 올라가게 됩니다.
제가 고민한 결과는 해당 패턴을 사용할 규모/상황이 아니다 입니다.
여러 서비스에서 잦은 중복 컴포넌트가 발생하며 확장성이 필요한 상황에 좋은 방식인 것 같습니다.
예를들어 여러 서비스가 하나의 도메인에서 서브도메인으로 각각 배포되는 상황일 때
각 서비스의 관리를 서로 다른 인원이 관리한다면 같은 디자인(버튼, 캐러셸), 코드는 공유컴포넌트로
깃허브의 서브모듈을 사용하건 webpack의 module federation을 사용하던 해서 공유해서 사용하게 될 것입니다.
각각 따로 제작하면 의도하지않은 차이로 인한 문제가 발생할 수 있고 유지보수에 영향을 줄 수 있으니까요
이렇게 사용하게 되면 공유된 코드는 많은 서비스에서의 요구를 커버해야합니다.
완전 똑같이 사용한다면 문제되지 않겠지만 UI/UX를 고려했을때 캐러셸의 버튼이 달라야한다는 등의 상황을 위해 매번 새로 만들수는 없으니 캐러셸 버튼, 캐러셸 몸통 등으로 분리해 합칠 수 있도록 쪼개고 단위별로 일부 합쳐 놓은 것을 선언해 동일하다면 상위 폴더(molecules 등)에서 가져다 쓰고 아니라면 다른 부분을 가져와 새로 조립하게 됩니다.
간단하게 많은 요구를 정형화된 코드로 만족시킬 수 있습니다.
하지만 공유코드가 아닌 서비스까지 아토믹패턴으로 가져간다면 혼란이 올 수 있습니다.
폴더가 복잡해서 위에서 말했듯이 closet 페이지를 수정하는데 ~컴포넌트가 어디있더라하고 page->Template 부터 내려가게 되는 문제가 발생할 수 있습니다.
또한 폴더구조를 지키기위해 재사용이 되지않는 코드도 과한 컴포넌트 분리가 발생할 수 있습니다
이를 통해 코드의 복잡도가 올라가고 오히려 유지보수성이 낮아질 수 있다고 생각했습니다.
결론적으로 프로젝트 상황이 해당 디자인 패턴의 장점을 살릴 수 없었습니다.
해당 디자인 패턴의 장점을 살릴수있는 방식으로 변경을 기획해볼까 합니다.
outift-weather프로젝트에 게시글같은 post 관련 서비스, 공지를 띄우기 위한 팝업 서비스등을 추가하고 서브도메인으로 배포
프로젝트/브랜치를 생성해서 캐러셸, 버튼, 모달, 등을 atomic 디자인으로 정형화 한 후 각 서비스에서 사용하도록 해보겠습니다.