처음 고민해본 프론트엔드 아키텍처와 디자인패턴

https://pungwa.tistory.com/183

프로젝트 실패 회고

위 글에서 이어지는 내용이다.

이번에 진행한 프로젝트에서 제대로 작성되지 않은 코드가 어떻게 회사의 비즈니스에 악영향을 미치는지 경험하게 되었다.

그래서 진지하게 '좋은 코드'에 대한 욕심이 생겼고 아키텍처든 패턴이든 코드컨벤션이든 그런 게 왜 필요한지 느끼게 되었다.

자연스럽게 아키텍처까지 생각하게 되었다.

아니 아키텍처를 고민해 봤다기보다 User Interface를 만드는데 왜 이렇게 느리고 어렵지? 왜 이렇게 예측하기 어렵지?

라는 고민을 하다 보니 현재 구현되어 있는 방식의 문제점이 느껴졌고 개선하게 되었다.

그래서 아키텍처 라기엔 너무 거창하다.

그냥 디자인패턴을 어떻게 만들고, 함수들은 어떻게 만들고, 이것들을 어떤 규칙을 가지고 가독성을 유지하고

유지보수가 쉽게 하며 다른 개발자들도 쉽게 사용할 수 있도록 만들지! 그 정도의 고민이라고 생각한다.

ㅇBefore, After(future)

왼쪽은 현재의 구조이다. 가장 상위의 컴포넌트에서 data get 도 하고 dispatch도 하고 event 함수도 만들고 로직만 들어있는 함수도 만들어서 하위 컴포넌트로 내려주는데, 또 모든 하위 컴포넌트가 재사용을 위한 컴포넌트는 아니다. 이벤트함수나 로직만 들어있는 함수들은 props로 내려주고 data는 전역상태에서 가져오고 어떤 로직은 redux에서 직접 구현이 되어있기도 하다. 전역상태는 contextAPI, redux를 둘 다 사용해서 구현되어 있다. 

이런 구조로 작성된 코드에 추가작업을 하니 계속 지연되고 안 좋은 코드가 덧칠될 수밖에 없었다.

예를 들어 기존 코드에 덧붙이기에 애매한 기능들은 useEffect를 하나씩 추가해서 만든다던지..

스타일을 변경해야 할 때는 css, scss, styled-components, 인라인스타일, !important가 마구잡이로 덧칠되어 있어서

!important를 쓰고 싶은 유혹이 들게끔 만든다던지..

그래서 이전 프로젝트에서 잘됐던 점, 내가 실수한 점을 돌이켜 배워서 오른쪽과 같은 구조로 개선할 계획을 세웠다.

계획을 세우기 위해 많은 글을 읽었는데 teo님이 작성하신 글 중에(https://velog.io/@teo/MVI-Architecture)

어렴풋이 내가 원했던 모양을 제대로 정리해 주신 글이 있어서 많이 보고 배웠다.

MVC, MVVM 등 많이 들어본 아키텍처인데 결국 프런트엔드는 Model로 View를 어떻게 잘 보여줄지,

UI에서 일어난 데이터의 변화를 어떻게 Model에 잘 반영하고 그것을 어떻게 다시 View로 잘 보여줄지,

이 목적을 위한 고민의 흔적들 같이 느껴졌다. 위에서도 말했듯이 아키텍처에 대한 고민을 한다기보다는 

어떻게 해야 일관되고 가독성이 좋은 프런트엔드 코드를 만들 수 있을지에 대한 생각이다.

Model(data)를 View로 잘 보여주기 위해서 atomic design pattern을 사용하기로 했다.

가장 대중적이고 이해하기 쉬웠고, 나도 모르게 이렇게 개발을 해오고 있었기 때문에 최신의 프론트엔드 스타일에 잘 맞는다고 생각했다.

대신 나는 과거의 실패를 교훈 삼아 몇 가지 규칙을 덧붙였다.

atoms은 재사용한다. 더 이상 쪼갤 수 없는 디자인의 최소단위이다(버튼, 텍스트, 박스 등). 로직과의 종속성이 없도록 만든다.

molecules는 재사용한다. 두 개 이상의 atoms가 모여서 이루어진다. 로직과의 종속성이 없도록 만든다.

organisms는 재사용하지 않을 수 있다. 두개 이상의 molecules, atoms가 모여서 이루어진다. 기능이 있는 단위이다.

이벤트, 로직이 작성된다. 

templates는 재사용하지 않는다. 데이터가 결합된다. Model과 관련된 get, mutate는 이곳에서 가져온다.

각 Page는 이 templates를 렌더하고 page에서는 각 페이지별 옵션을 설정하는 역할만 한다. 

예를 들면 특정 페이지만 title을 설정한다거나, seo최적화를 한다거나, 특별한 훅을 가져다 적용한다거나..

View와 관련된 컴포넌트요소는 atomic pattern을 활용해서 재사용성 있게 만든다.

로직과 관련된 함수는 custom hooks pattern으로 재사용하고 코드를 단순하게 하고 추상화한다.

 

이번에 우리 회사 서비스에서 가장 뷰가 많은 페이지를 수정하는데, 위와 같은 규칙으로 한번 개발을 해보고

현실적이지 않거나 더 좋은 방법이 떠오르면 수시로 업데이트하고 새로 적용해 볼 예정이다.

프런트엔드가 워낙 변화가 빠른 곳이라 내가 정성껏 만든 코드도 언젠가 레거시가 되겠지만

그래도 다른 개발자가 읽기 쉽고 수정하기 쉬운, 마치 개발 문서 같은 코드를 만들어서 자산으로 남기고 싶다.

 

https://velog.io/@teo/MVI-Architecture

프론트엔드에서 비즈니스 로직과 뷰 로직 분리하기 (feat. MVI 아키텍쳐)