본문 바로가기
개발 일지

코드잇 스프린트 기초 프로젝트 협업 후기

by 그랴 2024. 3. 20.

현재 수강 중인 부트 캠프에서 기초 프로젝트를 진행했다.

 

 

너글닿기

누구나 손쉽게, 온라인 롤링 페이지를 만들 수 있어요

itsbasic-c93d6.web.app

 

GitHub - innerstella/itsBasic: 코드잇 스프린트 4기 PART2 기초 프로젝트

코드잇 스프린트 4기 PART2 기초 프로젝트. Contribute to innerstella/itsBasic development by creating an account on GitHub.

github.com

 


🗓️ 프로젝트 일정

 


🚀 사전 회의

- 기술 스택 정하기
- 컨벤션 정하기 (코드, 폴더 구조)
- 문서화 방법
- 일정 및 마일스톤 관리 방법
- 의사소통 방법
- R&R 분배
- 깃 협업
- 회고

 

팀 내에 개발 협업을 처음해보는 팀원들이 있었고, 나 또한 5명 정도의 작지 않은 규모로 협업해보는 것이 오랜만이었기 때문에 작업을 시작하기에 앞서 많은 이야기를 나누는 것이 좋을 것 같다는 생각이 들었다. 효율적인 협업을 위해서 내가 그동안 경험해온 것들을 바탕으로 협업에 필요한 컨벤션 등을 소개하고 함께 논의를 통해 맞춰갔으며, 각자의 강점, 약점, 만들고 싶은 또는 만들 때 재밌는 기능 그리고 협업 시 지양해줬으면 하는 점에 대해 이야기 한 후 이를 바탕으로 R&R을 분배하여 조금이라도 더 재밌고 얻어가는 게 많은 프로젝트가 되도록 했다.

 

 

문서, 일정, 마일스톤은 깃허브의 이슈, 마일스톤을 통해 관리했다. 별도의 노션 페이지가 존재하기는 했지만, 작업 내용을 자주 작성하는 것을 지향하기도 했고 주로 깃허브를 많이 들어가는데 노션으로 이분화시키면 더 불편할 것 같았기 때문이다. 또한 이슈와 마일스톤은 각 브랜치와 PR과도 연결시켜 관리할 수 있었으며 이를 통해 프로젝트의 전반적인 진척도를 가시적으로 확인할 수 있어서 좋았다. (팀원들의 반응도 좋았다.)

 

 

그리고 팀원들의 반응이 좋았던 방식 중 하나는 코어 타임 중 본인의 상태 표시였다. 코어타임을 2시에서 6시로 정해두었긴 했지만, 개인의 자잘한 스케줄 변동 사항은 불가피하기 때문에 이를 팀원들에게 알릴 수 있는 장치를 마련했다. 사실 슬랙을 사용했다면, 슬랙 내부 기능을 사용할 수 있었겠지만 우리는 디스코드를 사용했기 때문에 이 기능을 모방해서 이용했다.


⚙️ 기본 요구 사항 구현

나는 팀원들이 하고 싶은 부분들을 다 선택하고 남은 부분의 개발을 맡았다.

  • 롤링 페이퍼 목록 페이지
  • 롤링 페이퍼에 메시지 작성하는 페이지

기능 구현 자체는 어렵지 않았지만, 메시지를 작성하는 부분에서 값이 매우 자주 변하는 부분을 useState로 관리하여 불필요한 렌더링이 일어나는 것을 확인했다. 따라서 이 부분은 useRef를 통해 값을 참조하고 있다가 메시지 전송 시에만 값을 확인하는 방식으로 개선하여 리소스 낭비를 방지했다.

 

또한, 반응형 디자인의 break point를 잡는 것이 다소 까다로웠는데, 팀 내부에서 정한 기준으로 하게 되면 데스크탑 크기에 따라 UI가 정상적으로 노출되지 않는 문제가 있었다. 따라서 이 부분은 데스크탑 내에서도 한 번 더 break point를 잡아서 작은 데스크탑의 일부에서는 태블릿 UI를 사용하여 사용자가 불편함 없이 상호작용 할 수 있도록 했다. 

 


🔥 추가 개발

  • 리팩터링
    • 작업 초반에 최대한 빠른 개발을 목표로 각자 맡은 부분만을 작업했기 때문에, 공통 컴포넌트로 분리할 수 있음에도 불구하고 그냥 작업을 진행했던 부분들이 있었다. 이를 리팩터링 해서 컴포넌트의 재사용성과 유지 보수성을 높였다.
    • 전반적인 코딩 스타일을 통일시켰다.
  • 성능 및 웹 접근성 개선
    • lighthouse를 통해서 성능 점수를 측정한 후, 지적 받은 항목들을 하나씩 고쳤다.
    • 시맨틱 태그를 작성하였다.
    • 로컬에서 점수를 측정했을 때는 낮은 점수가 나오는데, 배포한 사이트의 점수는 높은 점수가 나오는 것이 궁금했는데, 호스팅 플랫폼에서 빌드 시 자바스크립트 번들을 최적화시켜주기 때문인 것을 알게 되었다. 

♻️ 회고

주차마다 KPT 회고를 진행했고, 회고에서 나온 액션 아이템을 다음 주차 개발에 충분히 적용시켜 더 나은 협업을 할 수 있도록 노력했다.

  • 1주차 액션 아이템
    • 코드 리뷰 활성화
    • PR 전 코드 정리하기
    • 컨벤션 추가 정립
  • 2주차 액션 아이템
    • PR 및 이슈 템플릿
    • 코드 리뷰 더 활성화
    • 전반적인 버그 함께 확인

프로젝트를 끝마친 후에는, 4L 회고를 통해서 향후 다른 팀원들과 프로젝트를 진행할 때 이번 프로젝트에서 좋았던 점들을 계속해서 가져갈 수 있도록 했다. 

 


💡 배운 점 및 느낀 점

  • 원활한 협업을 위한 초기 컨벤션 정립
  • 깃허브와 노션을 통한 프로젝트 전반적인 관리
  • 데일리 스크럼을 통한 팀원들과의 진행 상황 공유의 중요성
  • 회고를 통해서 반성도 할 수 있지만, 팀원들을 칭찬하는 과정에서 유대감도 쌓을 수 있었다.
  • 불필요한 렌더링이 일어나고 있지는 않는지 확인하며 개발하기