 정채영(FE) |
 김은선(BE) |
 안종혁(BE) |
 한원태(BE) |
상태 관리
- 상태 설계에 대한 기본 생각
- UI에 필요한 데이터가 생길 때 마다 useState를 이용해 상태로 관리해야하는지 고민했습니다.
- 그러나, 상태가 많아지고, 상태 간의 관계가 존재하는 경우 서로의 의존성이 올라가고 복잡도가 증가했습니다.
- A 상태를 이용해 B 상태를 계산할 수 있는 경우, B를 상태가 아닌 A로부터 계산하는 일반 변수로 관리했습니다.
- 불필요한 상태를 줄여 렌더링 시점도 명확하게 컨트롤하며, 상태가 모순이 생길 일도 없어졌습니다.
- usePopup
- 해당 애플리케이션에서 처리해야할 팝업의 종류가 많았기 때문에 프로젝트 내에서 쓰일 팝업을 관리하는 커스텀 훅을 만들었습니다.
- 커스텀 훅에서는 useReducer를 사용하여 다양한 종류의 팝업을 쉽게 관리할 수 있게 했습니다.
- useApi
- api를 fetch하는 커스텀 훅을 만들었습니다.
- 기존에 사용하던 useState와 useEffect 등으로 처리하는 공통 로직을 모아 커스텀훅으로 만들어 코드의 부피를 줄이고 가독성을 증가시켰습니다.
- 필터 기능의 상태 관리
- 백엔드에게 이슈 필터링을 요청을 보내기 위해 query-string 라이브러리를 사용하였는데, 해당 라이브러리에 맞게 파싱하기 쉬운 객체 형식으로 useState로 관리했습니다.
백엔드와의 협업
- 백엔드 API의 응답값 구조가 변경된 사실이 공유되지 않아 에러가 발생하는 문제가 있었습니다.
- 디버깅 후 백엔드가 제공한 데이터구조가 바뀐 것을 알아내고, api를 사용할 때 응답값부터 확인하는 습관을 들이게 되었습니다.
- 동시에 문제의 재발 방지를 위해, API 명세를 하나의 문서 플랫폼(스프레드 시트)에서 관리하고, 변경 사항이 있을 땐 해당 문서에서 명세를 반드시 변경하는 것을 부탁드렸습니다.
- API에 대한 커뮤니케이션 창구를 단일화하여, API를 위한 커뮤니케이션 비용을 줄이고 문제 가능성을 낮췄습니다.
- 백엔드의 api가 완성되기까지 시간이 지연되는 경우가 있었습니다.
- 작업이 미뤄지는 것은 언제나 있을 수 있는 일이라고 생각합니다.
- 그러나, 전체 프로젝트의 일정은 최대한 지켜져야하므로, 기능을 명확히 파악하고 작업 전 API 명세에 대해 명확한 합의를 진행하고자 했습니다.
- 이 과정을 거쳐, API가 완성되기 전 미리 합의한 구조에 맞는 mock 데이터를 구성해 프론트 코드 설계 및 코딩 작업을 진행했습니다.
- 이에 따라 프론트엔드와 백엔드 개발 작업이 보다 원활하게 병렬적으로 진행될 수 있었고, 개발 속도와 효율성도 향상되었습니다.
- 서로의 개발 진행 상황을 자주 확인해야 함을 느꼈습니다.
- 각자의 작업에 몰입하여 상대방에게 작업 결과를 공유하는 것을 잊는 경우가 있습니다.
- 일례로, API 완성 후 전달 과정에서 전달이 누락되는 경우가 있었습니다.
- 문제를 해결하기 위해, 정해진 시간에 모든 팀원이 참석하는 데일리를 진행하였고 이 시간을 활용해 작업 진행상황 등을 공유하고 노션에 기록했습니다.
데이터 구조
- 기획서를 확인한 후, 화면을 구성하기 위해 필요한 데이터를 파악했습니다.
- 프론트엔드 개발자 입장에서 데이터를 사용하기에 효율적인 구조는 어떤 것인지 고민했고, 생각한 구조를 백엔드에게 제안했습니다.
- 그러나, 프론트엔드에게 필요한 구조가 백엔드에서는 다루기 까다로운 형태일 수 있다고 생각하여서 해당 데이터 구조가 서버 입장에서도 효율적인지, 개발 난이도와 공수는 어느정도인지 고려하고, 커뮤니케이션을 통해 늘 확인했습니다.
컴포넌트 재사용
- 사이드바, 페이지의 헤더 부분 등 웹 페이지 내에서 재활용될 수 있는 컴포넌트를 분리하였습니다.
- props를 활용해 형식은 비슷하지만 목적 등이 다른 경우(label을 수정하거나 생성할 수 있는 폼)에는 isCreation을 불리언 값으로 전달해 코드의 반복을 줄이고 좀 더 유연한 컴포넌트를 만들었습니다.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent