GPM Admin 프로젝트

GPM은 pixel이라는 페이스북의 분석툴을 입력하고 관리하는 백오피스다. 레거시 없이 새로 빌드해 7월 중순부터 지금까지 약 6주정도 개발을 했다.

폴더 구조에 대한 고민

POC 기간부터 폴더 구조에 대한 고민이 많았다. 나는 아토믹 디자인 패턴에서 발전시켜 나가려고 했는데 한계가 있었고, 회사에 있던 기존 구조를 따라서 작업을 하다 아래의 구조로 정착하게 되었다.

공통으로 사용하는 로직은 최상단에서 관리하고, features라는 하위 폴더 안에 각 도메인에 관련된 로직을 작성하는 방식이다. 이렇게하면 도메인이나 기능이 추가될 때 확장하기 쉽고, 도메인간 결합도가 낮아져 유지 보수가 쉬울거라고 판단했다. 이렇게 작업을 해보니 더 직관적이었고, 리팩토링이나 추가 기능을 구현할 때도메인은 전혀 상관하지 않고 해당 폴더 내부에서만 작업할 수 있었다. 꽤 마음에 드는 구조라 회사 프로젝트나 개인프로젝트나 당분간은 이 구조로 작업할 것 같다.

https://github.com/alan2207/bulletproof-react?fbclid=IwAR0Q3gck2B9CZyPaU5bEsA96NADfd0AA1t79uc_ZvN1C80JuAAN1w3ScvsQ

├── assets
├── components
│   ├── Elements
│   ├── Form
│   └── Head
│   └── Layout
├── features
│   ├── auth
│   │   ├── api
│   │   ├── components
│   │   ├── routes
│   │   ├── types
│   │   ├── hooks
│   │   └── index.ts
│   ├── comments
│   ├── teams
│   └── user
├── hooks
│   └── useHooook.ts
├── lib
│   ├── auth.tsx
│   ├── axios.ts
│   ├── react-query.ts
├── store
├── types
└── utils
    ├── format.ts
    ├── lazyImport.ts
    └──  storage.ts

react query 도입

api 요청은 일반적으로 redux middleware를 이용했는데 이번에 react-query를 도입했다.
사용해보니

• 미들웨어를 사용했을 때 보다 로직이 많이 줄어든다
• loading, error 등의 상태 처리가 용이하다
• redux를 쓰지 않고도 서버에서 받아온 데이터를 여러 컴포넌트에서 사용할 수 있다
  단점은
• click이벤트 등을 이용해 refetch를 할 때 useEffect를 이용해야 한다

자세한 사용기는 따로 포스팅을 할 예정이다!

redux 안 쓰기

api 호출을 제외하고 공통 상태 관리를 할 필요 없을 것 같아 이번 프로젝트에서 리덕스를 안 쓰기로 했다. redux로 주로 처리하던 로그인에서 애를 많이 먹었는데 어찌어찌 처리를 했다.(어찌를 다시 확인하기)

내가 작업한 컴포넌트에서 다른 도메인으로 분리해놓은 두 가지를 한 모달에서 사용하는 케이스가 있어서 최상위 컴포넌트에 서로 공유하는 데이터를 넣어두고 props로 전달하며 구현을 했는데 context 사용했으면 어땠을까요라는 피드백을 뒤늦게 받았다. 상태관리 라이브러리를 무조건 쓰면 안된다는 컨셉이라고 생각을 했기 때문에 리덕스의 필요성만 간절히 느끼며 작업을 했는데....그런게 아니었다....context는 생각도 못했다. 리덕스를 사용하지 않았지만, 사용하지 않았기 때문에 오히려 리덕스와 상태관리, context 등등에 대한 전반적인 이해가 부족하다고 느꼈다. 요즘 왜 리덕스가 미움을 받는지, 다른 새로운 상태 관리 라이브러리는 무엇이 있는지, 왜 나왔는지에 대해 공부할 예정이다.

JIRA

JIRA를 이용한 스프린트 애자일 방식으로 프로젝트를 진행했다. 프로젝트를 하며 스스로 가장 발전한 부분이 이 부분이라고 생각한다. 집중이라는 스프린트의 컨셉을 이해하고, 잘 실행했다고 생각한다. 티켓을 잘게 쪼개서 작업하니 내가 해야할 것, 하고 있는 것을 직관적으로 파악하고, 그것에 집중할 수 있었다. 작업하는 중에 다른 수정 사항이 보이면, 바로바로 처리하고 싶은 욕구가 생겼지만 티켓을 새로 만들고 하던 작업을 마친 다음 작업을 하는게 효율이 훨씬 좋았다. 그리고 PR했을 때 리뷰어들이 코드를 파악하기도 수월하다. 일하는 방식에 익숙해지고 있는중이다. 추가적으로 애자일 방식이 뭔지 공부가 필요하다.

코드 리뷰와 리팩토링 그리고 페어 프로그래밍

프로젝트 중 가장 힘들고! 가장 보람있었던 것이! 페어 프로그래밍을 통한 리팩토링이었다. 우리의 페어 프로그래밍의 목적은 각자 다른 코딩 스타일을 맞춰 앞으로의 프로젝트에서도 일관된 스타일을 유지하고, 리팩토링을 통해 코드 품질을 높이기 위해서였다. 내가 짠 코드를 상대에게 이해시키고, 나와 생각이 다른 부분을 맞춰가고, 내가 고수하던 스타일을 버리는 과정이 쉽지는 않았지만, 다른 관점, 다른 방식을 많이 배울 수 있었고, 리팩토링을 통해 더 나은 결과물을 만들 수 있었다. 다만 과정이 힘들어서 좀 더 즐겁게 할 수 있는 다른 방식이 있는지는 궁금하다. 그리고 antd 사용법을 통일하거나 사용하는 방법이나 랩핑 레벨 등을 맞추고 싶었는데 못해서 아쉽다.

맥락에 대하여

맥락없이 일하고 있다는 것을 요즘 많이 느낀다. 분명 1주일 스프린트 단위로 일을 잘 쳐냈는데 릴리즈가 많이 늦어졌다. 구현은 2~3주 만에 빨리했는데...? 전체 프로젝트 일정에 대한 인식이 없었다고 생각한다. 그리고 벌써 일한지 두 달인데 회사 도메인이나 프로덕트에 대한 이해가 많이 부족하다. 나는 아직 신입이니까라는 생각으로 깊이 이해하려고 하지 않았던 것 같다. 또 반성... 일을 할 때 전체 맥락을 항상 생각하면서 일하기!!!

그래서 발전한 것

• refresh token 관련 로직을 처음 작성해봤다
• type 사용에 익숙해지고 있다

공부 + 읽은 것

리팩터링 2판

리팩터링 말만 많이 듣고, 하는 시늉만 했지 왜 하는건지 어떻게 하는 건지는 잘 몰랐다. 그걸 알기 위해 주 2회 스터디를 하고 있다. 이번 달에는 리팩터링이 무엇인지, 왜 하는지에 대해서 그리고 코드의 어떤 부분을 리팩토링 해야하는지에 대해 읽었다. (ch 1,2,3)

왜 개발자 일의 8할이 이름짓기인지 이해했다. 피알하기 전에 리팩토링을 하자는 원칙을 세우고 실천중인데 자꾸 까먹는다..^^;

브라우저 101

자바스크립트와 브라우저 작동 방식을 더 잘 이해하기 위해서 듣고 있는 강의다. 강의 내용은 내 목적에 부합하는데 진도가 너무 안 나간다. 어쨌든 이번 달에는

• web api
• 이벤트
• crp에 대해 공부하고 정리했다.

다음 달 목표

• 정산 프로젝트 화이팅
• browser 101 강의 다 듣기
• 운동 일주일에 3번 꼭하기
• 운전면허 따기
• 리팩토링 부지런히 읽기
• webpack, aws에 대한 이해도 높이기