- 백엔드와 함께 학습
서비스의 전체적인 구조와 데이터 흐름에 대해 이해할 수 있었습니다.
- 페어 프로그래밍
동료와 함께 실시간으로 지식을 공유하고, 코드의 구조/로직을 함께 고민하여 코드의 품질을 높였습니다.
4️⃣ 삼방구(우아한 문방구)
2021.08.09 ~ 2021.08.31(3주)
Links
New Skills
- React.js, TypeScript
- react-query, ContextAPI
- Jest, Stroybook
Experience
- 테스트하기 쉬운 코드
처음으로 테스트 코드를 작성하다보니 무엇을 어떻게 테스트해야 하는지 감이 잘 잡히지 않았습니다. 그리고 컴포넌트 단위로 테스트하려고 보니 어려움이 있었습니다. 그 이유는 로직에 API call이 포함되어 있는 것이었습니다.이후에 비동기 작업은 상위에서 진행하고 결과 데이터를 컴포넌트에 넘겨주는 방식으로 코드 구조를 개선하였습니다. 이렇게 변경함으로써 코드 관리와 디버깅이 더 수월해졌습니다.
- 직접 구현한 styled-component
tagged template literal을 사용하여 styled-component 라이브러리를 직접 구현하였습니다. 라이브러리의 공식 Github에서 코드를 읽고 핵심 원리를 파악하였습니다. 기능을 빠르게 구현하고 간단한 테스트 후 프로젝트에 적용하였습니다.적용 후 버그가 발생하기 시작했고 저는 바로 대응하였습니다. 제가 작성한 코드로 인해 기존에 동작하던 코드를 변경하고 싶지 않았습니다. 발생한 버그들 모두 해결하는데에 크게 어려움이 있었던 것은 아니지만, 온전히 저 혼자 개발한 코드에 대해 책임감을 느낄 수 있었습니다.
- 상태관리(react-query, ContextAPI)
많은 상태 라이브러리를 두고 react-query를 선택한 이유는 data fetching이 빈번히 발생하기 때문입니다. 로딩 상태나 데이터 관리를 위해 여러 hook을 사용해야 했었지만, react-query를 사용함으로써 하나의 hook으로 상태를 한 번에 제어할 수 있었습니다.저를 포함한 팀원 모두 React에 경험이 많이 없었기 때문에 전역 상태 관리 라이브러리까지 학습하기에는 러닝 커브가 높다는 문제에 동의하였습니다. 그래서 전역 상태 관리 라이브러리는 따로 선택하지 않고, Context API를 페어 프로그래밍으로 함께 학습하여 사용하였습니다.
- 팀을 위한 회고
마지막 프로젝트는 이전의 프로젝트와 달리 팀의 인원이 2명에서 4명으로 증가하였습니다. 사람이 4명으로 늘어난다고 일이 4배 빨라지는 것은 아니었습니다. 오히려 일의 진행 속도 자체는 이전보다 더 느려진 것 같았습니다. 중반부터는 서로의 일 진척도가 투명하게 보이지 않았고, 계획했던 일정이 딜레이되었습니다. 이렇게 된 원인은 이슈 단위가 너무 큰 것이었습니다.팀원들과 회고 후 현재 작업하고 있던 이슈를 포함한 남은 모든 이슈를 쪼개어 다시 설정하였습니다. 그 후 모든 이슈를 assign하여 일의 진척도가 눈에 보이도록 하였습니다. 이런 방법이 확실히 맞는 것이라 자신할 순 없지만, 팀의 목표를 위해서 계획과 방법을 지속적으로 개선하고 이루어내는 과정을 경험하게 되었습니다.