업무
1. 신규 서비스 기능 개발
폭풍 같이 몰두한 한 주...
a. 전체 아키텍처 구성
기본적인 애플리케이션 구조를 설계했다.
가장 신경 쓴 부분은 → 각 컴포넌트들 간의 관심사 분리.
지금껏 운영해 온 여러 서비스들을 생각해 보면
유지보수와 확장이 용이한 프로젝트도, 그렇지 않은 것도 있었다.
그 차이를 곰곰이 생각해 보면...
물론 여러 이유가 있겠지만, 애플리케이션의 최초 설계 역시 제법 큰 부분을 차지함을 느꼈다.
최초 설계 시 명확하지 않은 개념(올바르게 분리되지 않은 관심사)들은
필연적으로 개발자 각각의 정의로 이어졌고,
이로 인해 각 컴포넌트나 함수의 관심사가 모호해지는 경우가 허다했다.
따라서 지금까지 나온 요구사항에 기반해
핵심 상태 및 제어 로직과 전체 컴포넌트 구조를 정의하는데 노력을 기울였고,
팀원들과 계속해서 공유 및 피드백을 주고받으며
프론트 팀 전체가 동일한 서비스 구조를 그리며 작업할 수 있게끔 힘썼다!
b. custom router 기능 개발
서비스 내 패널 기능에서 navigator와 유사한 기능이 필요했다.
(특정 페이지로 이동, 뒤로 가기 등)
처음에는 특정 페이지에 해당하는 상태(step)를 제어하는 개념으로 설계를 했는데,
페이지 이동 시 필요한 정보를 넘겨받는 등의 추가 기능이 필요해서
next js의 useRouter와 유사한 인터페이스를 제공하는 custom router hooks를 작성했다.
→ 보편적인 라이브러리나 패키지의 인터페이스를 참고하는 것이, 추후 공유 및 팀원들의 재사용에서 이점을 가짐을 느낄 수 있었다!
c. 각 기능별 api 연결
늘 하는 CRUD 작업!
d. 업데이트 함수 액션 작성
서비스 사용자가 각종 요소들을 커스텀하는 부분이 신규 서비스의 주된 기능인데...
해당 상태를 업데이트하는 로직을 작성했다.
reducer를 통해 업데이트 로직을 별로 함수로 분리해 작성했는데...
액션에 대한 type과 인자값(payload)에 대한 타입 추론이 이뤄지지 않아 불편하다는 피드백이 있었다.
이런저런 방법을 찾다, 결국 type과 payload 각각에 맞는 타입들을 정의하고
해당 타입의 union type을 지정하는 방식으로 리팩토링을 진행했다.
type을 통한 payload를 강제할 수 있어 편리했지만
각 action이 추가될 때마다 type과 payload를 하드코딩해야 한다는 단점도 있었다.
해당 부분을 어떤 방향으로 개선할 수 있을지는... 고민 중인 부분!
'lean > 주간 회고' 카테고리의 다른 글
| 23.11.05~23.11.12 (0) | 2023.11.12 |
|---|---|
| 23.10.22~23.11.05 (0) | 2023.11.05 |
| 23.10.15~23.10.22 (2) | 2023.10.22 |
| 23.10.08~23.10.15 (1) | 2023.10.16 |
| 23.10.01~23.10.08 (0) | 2023.10.08 |
