멍하냥 팀 프로젝트 회고

Jay·2023년 1월 24일
3

개요


[ 기본 정보 ]

  • 팀 프로젝트명 : 멍하냥
  • 팀 프로젝트 기간 : 2022.12.9 ~ 2023.1.4

[ 이번 프로젝트의 개인적인 목표 ]

  • 문제를 해결하고자 시도하기 전에 문제를 인지하고 정의하는 습관을 기르자.
  • 컴포넌트의 책임을 분리하고, 합성 컴포넌트로 재사용성을 극대화하자.
  • 기능 중심 개발에 집착하지 말고 가독성이 높은 코드를 작성하여 전반적인 코드 퀄리티를 높여보자.
  • 협업 방식과 개발 문화를 조성하여 협업 역량을 강화하자.
  • 코드 리뷰 및 지식과 노하우를 공유하여 공동 성장을 실천하자.

나의 역할

😸개발 팀장

  • 프로젝트 전반에 걸쳐 계획 수립과 기초 설정을 진행하였다.
  • 기능 구현 과정에서 맞닥트린 문제를 함께 고민하였다.
  • 코드 리뷰를 통해 코드가 어떻게 개선될 수 있을지 논의하였다.

로그인, 회원가입페이지

😁react-hook-form
로그인 페이지를 구현하면서 처음에는 새로운 라이브러리 도입에 부담감을 느끼기도 했지만 react-hook-form은 이해하기 쉽고 간단한 API로 구성되어 있었기에 채택하였다.

이 라이브러리를 사용하며 무엇보다 좋았던 점은 선언적으로 코드를 작성할 수 있어 가독성이 좋아지는 점이었다.

아직은 기능 개발 역량을 키우고 싶어 평소에는 이런 라이브러리 사용을 지양하였는데, 이런 단기적인 프로젝트에서는 적극적으로 라이브러리를 활용해 보는 것도 또 하나의 좋은 연습일 수 있겠다고 느꼈다.

검색 페이지

🤔검색 페이지 렌더링 성능 최적화
검색 페이지에서는 Blocking rendering을 해결하는 것이 가장 중요한 문제였다. 해결책으로는 가장 먼저 디바운스를 떠올렸다. 하지만 디바운스는 단순히 작업을 뒤로 미루는 것일 뿐이라 유저가 계속해서 입력을 하는 경우라면 화면 업데이트가 계속해서 지연되는 이슈가 있었다. 또한 적절한 딜레이를 선택하는 것도 고민되는 지점이었다. 딜레이가 너무 길면 유저 입력에 대한 반응도 그만큼 느려지지만, 너무 짧아도 적용하는 의미가 없어지기 때문이다.

쓰로틀의 경우에는 일정 시간을 주기로 화면을 렌더링하도록 할 수 있겠지만, 그 일정 시간 내에 연속적으로 입력하는 것이 아니라 중간에 입력을 하지 않는 경우에는 무의미하게 기다리는 시간이 생기는 문제가 생긴다.

따라서 Blocking rendering을 해결할 때 디바운스와 스로틀 모두 근본적인 해결책은 아닐 수도 있겠다는 생각이 들었고, 리액트 18에 새롭게 추가된 useTransition 훅을 사용해서 해결하고자 하였다.

startTransition으로 화면을 업데이트 하는 중에도 input 의 우선순위를 높여 입력이 끊기는 상황을 줄여주고, isPending의 boolean 값을 활용하여 로딩 중을 표시하는 ui를 띄워 손쉽게 ux를 향상 시킬 수도 있었다.

가장 좋은 점은 역시 간편한 hook으로 기능이 제공되기 때문에, 기존 로직에 아주 쉽게 적용할 수 있었다는 점이다.

아쉬운 점은 최근에서야 AbortController를 사용해서 API 비동기요청을 취소하는 기능을 구현할 수 있다는 사실을 알게 되었다. 이것을 함께 사용했다면 필요하지 않은 API 호출을 애초에 취소하여 웹페이지 성능이 더욱 크게 개선되지 않았을까 싶다.

게시글 업로드, 팔로우 페이지

기능 구현이 어렵진 않았지만 리액트 컴포넌트의 재사용성에 대해 많은 고민을 했던 기억이 난다.
두 페이지 모두 하나의 컴포넌트 안에서 분기처리를 해야할 부분이 많았다.

  • 게시글 업로드, 게시글 수정
  • 팔로우 리스트, 팔로잉 리스트

회고하며 결론을 내어보자면 하나의 컴포넌트 안에서 분기처리 해야할 것이 많아지면, 역할 별로 쪼개서 사용하는 것이 오히려 효율적일수 있겠다는 생각이 든다. 컴포넌트를 나누는 일관적인 기준이 가장 중요하겠지만 복잡하지 않은 재사용성이라는 키워드를 마음에 새기게 된 것 같다.

애초에 view와 logic을 깔끔하게 분리했다면 이런 고민을 할 일이 없었을까?😥🥲

그 외

  • 컴포넌트 분리
  • 라우터 작업
  • eslint & prettier 설정
  • git wiki 스터디 노트 작성

진행 방식

🚀 Issue와 칸반보드:

진행 중인 기능을 Issue로 발행하고 페이지 별로 구분한 칸반보드에 전체 현황을 공유하였다. 그 결과 직관적으로 남은 과업을 트래킹 할 수 있었다.

🚀 Wiki:

위키에 회의록과 컨벤션을 기록하였고, 우리 팀만의 스터디 노트를 만들어 활용하였다. 개인이 공부하고 정리한 내용을 공유함으로서 학습 비용을 절감할 수 있었다.

🚀 게더타운:

게더타운은 유연한 화상 대화 및 멀티미디어 연동 기능을 갖춘 강력한 협업 툴입니다. 저희는 게더타운을 적극 활용하면서 비대면 협업의 단점을 극복하고 원활한 의사소통을 이끌어내고자 하였습니다.

🚀 몹 프로그래밍:

중요하거나 복잡한 기능의 경우 몹 프로그래밍을 진행하였다. 프로젝트를 통한 공동 성장을 추구하였기에 이러한 방법을 채택하게 되었는데, 비록 생산성은 낮아질지언정 지식과 노하우의 공유라는 측면에서 함께 자라기를 실천할 수 있었다.

또한 정해놓은 협업 컨벤션에 적응하고 서로의 관점을 이해하게 되면서 팀워크를 강화하는 계기가 되었다.

회고

[ 팀 및 커뮤티케이션 측면 ]
한 달동안 효율적인 의사소통에 대해 많은 고민을 하면서 마음속으로 되새기게 된 포인트가 몇 가지 있다.

  • 어떠한 의견을 제시할 때, 상대방이 자신의 의도를 파악하기 위해서는 자신의 의견을 구조적으로 정리하여 논리적으로 설명해야 한다.
  • 현재 업무 진행 상황을 솔직하게 공유하고 혼자가 아닌 함께 문제를 해결하고자 적극적인 소통을 진행하여야 한다.

두 가지 모두 분업을 하면서 발생한 문제점과 연관이 있었다.

[ 프로젝트 측면 ]
역시나 전역상태관리 라이브러리를 채택하지 못한 것이 아쉽다. 하지만 파일럿 프로젝트도 없이 섣불리 기술 스택을 채택하는 것은 복잡도를 크게 올려 프로젝트 일정은 물론 모두에게 큰 부담이 따를 것으로 예상되었다. 결과적으론 팀을 위해 옳은 결정이었다고 생각한다.

동료 피드백

개발 분야에서는 첫 협업이었기에 너무 귀중한 경혐이고, 소중한 팀원들이다. 이번 주에 팀원들과 만나기로 하였는데 회포를 풀며 재밌게 이야기도 나누고 앞으로도 좋은 인연으로 이어가고 싶다.❤️

0개의 댓글