회고를 작성 하는 이유
만들었지만, 서비스를 릴리즈 하기전에 폐기 하기로 결정 하였다
달다 MVP 를 만들면서, 실제 달다 프로젝트의 기능, DB 구조 및 디자인등을 회의하고 계속해서 기획을 하면서 몇가지 생각이 들었다.
해당 페이지 View 들을 2달 안에 만들 수는 있을까?
해당 기능 등을 모두 구현은 제대로 할 수 있을까?
이러한 기능들이 서비스에 필요한 기능일까?
나는 디자인 외주를 맡길 View에 대한 와이어 프레임을 디자인 하고 있었는데,
기획한 것의 반정도 했을때 내가 만든 와이어프레임만 20개가 넘어가게 되었다.
이렇게 되면서, 진짜 제대로 우리 서비스에 필요한 기능 만 남기고, 다른 기능은 버리는게 어떤지 계속해서 고민하게 되었고 우리 팀 몰래(죄송합니다 ㅎㅎ;) 넌지시 진짜 필요한 기능이 무엇인지 계속해서 물어보았다.
기획의 의도 방향 변경과 그 이유에 대한 것을 노션에 작성해서 이야기 하였고, 그 후에 피그마로 만든 와이어 프레임을 통해서 어떤식으로 기획의도가 변경 되었는지 이야기를 진행 하였다.
실제로 필요한 주문 제작 폼 작성 및 제출 의 편리함 만 남기는 것이 어떤지 해당 자료를 통해서 이야기를 나누었고 팀원들의 동의 끝에 이전에 하였던 기획, DB 구조 그리고 디자인을 다 엎었다.
이 과정에서 이전에 먼저 만들어 놓았던 달다 MVP 를 폐기하기로 하였다.
달다 MVP 를 만들면서 성장 한 것들을 기록 하고 싶어서
달다 MVP의 프론트엔드 를 담당하면서 많은 것들을 하려고 노력하였다
1. [자체적으로 변경된] Gitflow
1.0 Gitmoji Commit
1.1 할일 이슈 등록, 해당 이슈에 대한 한일을 PR 등록
1.2 PR을 통해서 한일 및 나중에 처리해야 할일 들을 작성
1.3 셀프 코드 리뷰를 통해서 코드부분 에서의 리뷰
------------------------------------------------------------------
2. React 파일 구조
2.1 Page, Component 구조뿐 아니라 Feature 파일을 만들어서 Feature 단위 개발
------------------------------------------------------------------
3. 관심사 분리를 위한 코드를 짜기 위한 노력
------------------------------------------------------------------
4. MSW 사용
------------------------------------------------------------------
5. Github Actions 사용
5.1 AWS S3, AWS CloudFront, 도메인 연결달다 MVP를 만들면서 성장하였고, 또한 나름대로 하려고 했지만 잘 안되어서 아쉬웠던 부분을 한번더 기록하기 위해서 회고를 작성하게 되었다.
MVP를 만들면서, 나는 어떻게 성장 했는지
Git/Github
혼자 개발을 하더라도 며칠전의 개발하던 나 와 현재의 나 는 다른 부분이 조금이라도 있을 것이다. 나의 경우 며칠전의 개발하던 나 가 보통 더 똑똑하고 더 개발을 잘하는 것 같다.
따라서 이전에 내가 어떻게 개발을 하였는지 버전 및 기록을 남기기 위해서 브런치 관리를 해야 할 필요성을 느꼇고, 또한 셀프 코드리뷰, 셀프 기록 등을 하기 위해 PR 을 등록 해야할 필요가 있었다.
따라서 Git Flow 전략을 통해서 브런치 관리를 하려고 노력하였고, 거기에 Commit 은 GitMoji 를 통해 날렸다
Gitmoji 를 사용하는 이유는 나의 경우 글자가 전혀 읽히지 않기 때문에 이모지로 이게 무엇을 뜻하는지 한 눈에 알아보기 위함이다. (이모티콘이 어떤 의미를 갖는지 공부를 해야 했지만 ...)
또한 feature 단위로 branch 를 나눈 이유는 개발 초기에 이슈를 통해서 할 일들을 미리 나눴었는데, 하나에 branch에서 개발 하는 것보다 하나의 feautre를 더욱 더 집중도 있게 개발을 하기 위해서 brnach를 나누었다
또한, PR을 작성하여 셀프리뷰를 할때 내가 무엇을 개발하엿는지 더욱 쉽게 확인 하기 위해서 해당 feature 하나에 branch 를 만들어서 개발을 하였다.
+)
물론 모든 PR, 이슈 등에 대해서 셀프 리뷰를 하지 못하였다.
또한 셀프 리뷰를 어떠한 식으로 해야하는지 감이 안잡혀, 코드 리뷰를 하는식으로 진행 하였다.
나중에는 웬만하면 모든 PR에 대해서 셀프 리뷰를 하고, PR 템플릿 처럼 셀프 리뷰 템플릿을 지정해서
작성 하도록 해야겠다. React 파일 구조
프론트 엔드 개발 하면서 React 파일 구조를 어떻게 하는 것이 좋을지 프로젝트를 생성할 때 마다 고민한다.
이런 고민을 하던 와중, 동아리 팀원분 께서 좋은 참고 영상을 주셨고 이번 프로젝트에서 해당 폴더 구조를 사용 하였다
기본적 으로 실제로 보여지는 큰 페이지를 담는 pages 폴더 와 각 컴포넌트들을 담는 components 폴더를 가지고 있는 폴더 구조에 feature 단위의 components, hooks, styles 등을 담는 features 폴더를 추가하는 폴더 구조를 갖는다
WHY?
Feature 단위로 개발을 하면 해당 기능에만 집중해서 컴포넌트 코드 작성, 로직 코드 작성등을 할 수 있게 되어서 좋을 것 같다고 생각하였다
확실히, 해당 기능에만 집중을 해 빠르게 개발 한것 같다. 또한, 해당 기능에 맞는 네이밍을 작성 하려고 노력하게 되어 조금더 괜찮은 코드를 작성하게 된 ...? 것 같...다?
그럼 단점은 없엇는지
해당 Feature 에 작성한 코드가 다른 Feature 에도 사용 될 때가 있는데, 1,2개 정도 어울리지 않는 로직이 작성 되어있어서 아래의 고민들을 하였다.
MVP를 파기한 현 시점에 서도 저 2가지의 고민을 계속하였다.
추상화를 할 수 있으면 1번째 처럼 추상화를 하여 코드를 리팩토링 하였지만, 2번째 처럼 중복되는 코드가 있지만 다른 로직 1~2개가 추가되어 있어 이에 대해 새롭게 다시 작성 하였다.
1. 이를 조금더 추상화 해서 나눌 것
2. 다른 Feature 에 맞는 비슷한 로직을 작성 할내가 어떻게 코드 설계를 할 것인지 또는 내가 어떠한 원칙을 가지고 코드를 작성하고 리팩토링 할 것인지 고민을 하지 않고 생긴 단점 인것 같다.
그럼 나중에는 어떻게 할 것 인지
- Feature 단위로 개발 하되 로직 및 컴포넌트는 추상화를 하여 다른 Feature 에서도 사용 할 수 있도록 하자
- 해당 추상화한 로직을 사용하고, 하나의 Feature 에서 역할을 하는 로직을 작성하자
Feature 단위의 개발이 나에게는 정말 잘 맞았고,
다른 것들을 고민 하지 않고 먼저 해당 Feature 를 위한 로직을 개발 하는 것이 생산성을 크게 높여준다고 생각하였다.
이러한 Feature 단위 개발을 하기 위해 해당 폴더 구조를 그대로 가져 가되 MVP 개발 하면서 후회 하였던 것들을 보완해서 Feature 단위 개발을 할 것이다.
각 Feature간 로직이 중복되는 경우가 많고, 추상화 정도가 낮았는데, 추상화를 하여서 중복 코드를 줄여야 한다.- 일단
Features폴더에서 로직 개발을 하고 다른 폴더는 되도록 사용만 할 수 있도록 하자.
관심사 분리를 위한 코드를 짜기 위한 노력
여기서의 관심사 분리란, Component 로직과 State 로직의 분리 이다.
로직 분리
컴포넌트 로직이란, 실제로 보여지는 View 에 대한 로직을 의미한다.
해당 컴포넌트에서 실제로 작성 되는 코드는 View 만 작성 되도록 하고,
하나의 컴포넌트가 하나의 역할을 할 수 있도록 설계 하려고 노력했다.
해당 코드에서 아래에 해당 하는 부분이 View 에 대한 로직이며 로그인 버튼의 View만 해당 하게 된다.
이 외의 로그인 처리 등은 따로 커스텀 훅 으로 만들어서 컴포넌트에서는 커스텀 훅만 불러와 사용 할 수 있도록 하였다.
Toast 를 보여주는 useToast 훅 또한 useOAuthLogin 훅에서 불러와 사용 할 수 있지만, 해당 컴포넌트가 아닌 다른 컴포넌트에서는 useToast 를 사용 하지 않을 수 있기 때문에, 컴포넌트에서 2개의 로직을 커스텀 훅으로 불러와 사용 할 수 있도록 하였다.
어떠한 생각으로 분리를 하였는지
일단, 해당 컴포넌트에서 사용하는 API, State 가 길어 지거나 다른 컴포넌트에서 사용하게 된다면 커스텀 훅으로 따로 빼서 사용 하였다
이렇게 커스텀 훅으로 따로 빼서 로직을 만들게 되면서 1.[코드의 재활용] 코드를 추상적으로 작성하게 된다 2.[코드의 재활용] 추상적으로 작성하게 되면서 재활용 할 수 있게 되었다 3. [유지 보수 장점]로직을 변경하게 되면 컴포넌트의 View를 보지 않고 Hook 부분만 보고 변경 하면 되기 때문에 수정하기 쉬웠다 의 장점을 얻게 되었다.
아쉬운 점
내가 분리한 것이 컴포넌트 뷰 로직과 상태 로직을 분리한것이 진정 맞는지 정확히 판단하며 개발하기 어려웠다.
또한, 분리를 위한 분리를 한것이 아닌지 계속 갈등을 한것이 정말 아쉬웠다
앞으로 어떻게 할 것인지
앞으로 최대한 원칙을 가지고 분리를 할 것이다.
- 컴포넌트 개발할 땐
MUI,ANTDChakra UI를 보고 재활용 할 수 있는 컴포넌트 만들기 - 상태 로직 개발 하고 고민이 될 때는,
SOLID원칙을 보고 최대한 맞춰 개발하기
- 그냥 개발 하지 말고 React custom hooks 구글에 검색하면 많은 코드가 있는데 이를 보고 개발하기
MSW 사용 하기
비교적 시간이 많이 남아 프론트 엔드 개발을 빨리 시작하였고, UI 작업을 끝냈을 때 백엔드 개발이 시작 되었다.
따라서 나는 데이터 통신에 따른 프론트엔드 개발 하기에 API 가 나와있지 않아 방법이 없었다.
이에 따라서 목업 서버에대한 최대한 코드량을 줄이기 위해서 MSW 를 도입 하였고, 실제 API 통신과 다르지 않은 목업 서버를 사용하여 API 통신에 대한 코드를 작성 하게 되었다.
또한 이에 대해서 블로그 글을 작성 하였다.
MVP 를 만들면서, 나는 어떤 것이 아쉬운지
1. 코드를 작성할 때 원칙없이 작성 하였다
- 관심사 분리가 좋다는 것
- 좋은 아키텍쳐가 좋다는 것
이러한 좋다는 것들을 다 알고 있는데, 어떻게 하는 것이 관심사 분리이고 좋은 아키텍처인지 원칙이 없었다.
틀리더라도 나만의 원칙을 잡고 개발을 해야겠다
2. 어느정도 개발의 사이즈가 커지니까 어지럽다
개발을 하면서 불편하던 것들을 나중에 리펙토링을 하려다 보니까 리펙토링 할 것도 많은 것도 있지만 어떻게 리펙토링을 해야하는지도 모르겠고 어디서 부터 고쳐야 할지 몰라서 리펙토링을 하지 못했던 것도 있다
3. 코드부터 치지말고 먼저 어떤것을 할것인지 정하고 개발하자..
가장큰 문제점,, 코드부터 치지말고 어떤 것을 할것인지 어떻게 개발 할 것인지 정하고 개발해야 한다.
어떻게 개발할것 인지 머리속으로만 생각하고 코드 먼저 치니까 나중에 될 때 정말 좋지 않았던 것 같다.
최소한 어떤 것을 어떻게 개발 할 것인지는 정하고, 정리하고 코드를 치자!
