프로젝트 회고

협업 문화

데일리 스크럼과 위클리 스프린트

시작 스크럼과 마무리 스크럼

프로젝트 기간 동안 코어 타임 시작과 끝에 한 일, 할 일, 이슈에 대해 15분 정도 공유하는 시간을 가졌다.

팀원들이 뭘 하는지 짧은 주기로 꾸준하게 공유하였고, 그에 따라 다음 태스크에 대한 대처를 할 수 있어 일정 산정과 업무 속도 향상에 도움이 되었다. 또, 고정된 커뮤니케이션 시간이었기 때문에 자잘한 이슈나 변경사항 공지에 따로 비용을 들이지 않을 수 있었다. 이슈 공유가 길어지면 따로 안건을 잡아 회의를 생성하였다.

스프린트

월요일에는 스프린트 목표 수립하고 금요일에는 스프린트 회고를 진행하였다.
초반 기획 때 주차 별 스프린트 목표를 세우고 시작했다. 회고를 진행하며 유동적으로 목표를 재설정해나갔다.

• 1주차 목표

  1. 기획서
  2. 디자인
  3. 프로젝트 세팅
  4. 개발 컨벤션
  5. 라우팅
  6. 업무분배

• 2주차 목표

  1. 모든 페이지 UI 완성 + mvp 기능
  2. 중간 발표 영상 제작

• 3주차 목표

  1. 페이지 최종 완성
  2. 고도화
  3. 추가 기능

• 4주차 목표

  1. 데이터 만들기
  2. QA
  3. 최종 발표 준비

1,2주차에는 목표를 잘 이뤄냈는데 3주차에는 예상치 못한 문제에 부딪히는 탓에 일정이 조금씩 늦춰졌다. 그 때문에 QA를 제대로 못한 게 살짝 아쉽다. 최종 발표에서 프롱이들이 준 피드백과 함께 버그들을 고쳐나가야겠다.

Git-All-in-One

멘토님께서 추천하신 Git-All-in-One으로 코드 저장과 관련 상호 작용을 한 번에 관리했다. 하나의 통합된 환경에서 수행할 수 있어 학습 곡선을 줄일 수 있었다.

방법

discussion으로 project에서 issue를 발행하고 작업을 한 뒤에 pr을 올린다. code review 후에 2명 이상의 approve를 받으면 merge 할 수 있다.

특히 좋았던 점

issue : 팀원들 업무 파악하기 편했다. (초반에 실수로 이슈를 발행하지 않고 개발해 다른 팀원의 업무를 빼앗을 뻔한 적이 있다 🥲)
code review : 코드 품질 향상에 도움을 많이 받았다. 벌레 잡기도 좋다.

깃과 깃허브 외에 bitbucket이나 zira 등을 사용해보지 않아서 비교군은 없으나, 필요한 태스크 산출부터 코드 공유, ci/cd까지 간편하게 할 수 있는 점이 굉장히 편리하고 좋다.

감정회고

이것 또한 멘토님께서 추천하신 팀 문화이다.
감정을 배제하고 개발을 하다보면 속에 쌓이는 것이 생길 수 있는데, 감정에 대해 얘기하는 것만으로도 감정이 해소되어 협업에 도움이 된다고 한다.

배민에서 하는 팀문화라고 하셔서 솔깃해서 도입해 보았다. 감정이라는 단어에서 떠올려지는 뭔가.. 응어리진 것만 같은.. 그런 깊은 감정 공유가 아니더라도 고마웠던 점이나 사과하고 싶은 점을 말로 가볍게 주고 받는 것만으로도 해소되는 게 분명히 있는 것 같다.

페어 프로그래밍

두 사람이 하나의 컴퓨터로 프로그래밍을 하는 협업 방식이다. 한 사람은 코드 방향성을 제시하고 다른 한 사람은 그에 따라 코드를 작성한다.

팀에서는 초반에 페어 프로그래밍을 몇 번 진행했다. 나는 공통 컴포넌트를 페이지에 적용해 볼 때 페어프로그래밍을 경험해 보았다. 약식으로 진행했는데 몰랐던 mui 속성에 대해 서로 알려줄 수 있었고, 막히는 부분은 페어로 고민할 수 있어 좋았다.

개발

기술 스택

Redux ToolKit

팀원 분께서 문서화를 잘해주셔서 쉽게 익힐 수 있었다. redux와 비교해보았을 때 사용법이 간단하고 보일 플레이트를 최소화할 수 있다는 점이 큰 장점이다.

mui

mui를 사용해 스타일링에 힘을 빼고 편하게 개발할 수 있었다.

공통 컴포넌트를 만들 때 mui에서 제공하는 컴포넌트를 다른 팀원들이 사용하기 편하게 공용 컴포넌트 폴더에 파일을 만들지, 그렇게 한다면 필수적인 속성들을 명시할 수 있도록 props에 속성을 추가할지 아니면 사용법을 문서화하여 익히는 방법을 알려주는 게 좋을지에 대한 고민이 있었다. 결과적으로는 전자를 택했고 자주 사용할 만한 display : flex;에 해당하는 컴포넌트인 Stack만 문서화하여 사용법을 공유했다.

기존 개발자 외주 사이트의 ui와 완성도를 높이는 방법 중 하나로 mui를 도입한건데 결과물을 보았을 때 아주 조금 아쉬움이 남는다.

분업

빠른 개발을 위해 수직적으로 태스크를 분리하여 진행했다. routing, store, layout, 공통 컴포넌트로 네 파트로 나누어 시작했다.

업무 처리 속도는 빨랐으나 다른 기술은 접해보지 못한다는 아쉬움이 있어,
이후에는 태스크를 페이지 별로 분리해 페이지 내에서 이뤄지는 모든 작업을 경험할 수 있었다.

비슷하거나 겹치는 부분도 거의 독립적으로 개발을 했는데 덕분에 팀원들의 코드와 내가 작성한 코드를 비교하면서 좋은 코드가 뭔지 고민해 볼 수 있었다. 차후에 리팩토링하게 된다면 효율성, 가독성 등을 비교해보고 더 좋은 코드로 컴포넌트화 하면 좋을 것 같다.

코드 리뷰

예전 멘토링에서 좋은 코드를 많이 봐야 실력이 는다는 말을 들은 적이 있다. 코드 리뷰를 드리면서 잘하는 팀원들의 코드를 열심히 보다 보니까 읽기 좋은 코드나 설계적인 부분에 대한 감이 생긴 것 같다. 멘토님께도 도움을 많이 받았다.

코드 리뷰는 최고의 개발 문화인 것 같다.

개인 회고

Keep

• 일단 개발
  아직 맨데이 파악이 잘 안 돼서 일정 산정이 어려웠다. 스프린트 기간 내에 pr은 올려야 하기 때문에 일단 작성하고 올리기 전까지 수정을 반복했다. 바퀴는 굴러가게 틀은 만들어두고 살을 덧붙이는 방식으로 진행해 기한을 맞출 수 있었다.

• 일단 배워
  훌륭한 팀원들을 만나 도움을 많이 받았다. 코드 리뷰를 드리면서 질문도 하고 모르는 부분은 많이 검색해 보았고, 받으면서도 리뷰를 남긴 이유에 대해 고민하면서 검색했다. 개발보다 구글링을 더 잘하게 된 것도 같다.

Problem

• 미루기
  윈도우와 맥의 개행차이로 팀원들이 올린 코드를 lint로 돌리면 개행이 바뀌어 파일이 전부 파란색이 되어버리는 문제가 있었다. 문제 해결 방법을 이리저리 찾아보다가 명령어로 해결되지 않아 결국 시간이 없다는 핑계로 프로젝트가 끝날 때까지 불편하게 커밋을 했다. 합치면 꽤나 큰 시간을 투자한 셈인데 지금 돌이켜보니 너무 아깝다.

• 훅에 대한 이해
  최종 제출 전날, 상세 페이지 댓글 달기에서 useEffect의 높은 dependencies로 인해 무한 api 호출이 발생했다.
  input이 layout에 존재해 전역 store에서 가져오기 때문에 useEffect 안에서 input의 value를 제출하는 코드를 작성했다. 댓글을 제출할 때 post id, 사용자 아이디 등이 필요하고 댓글에 대한 알림을 보낼 때도 여러 상태들이 필요해 많은 상태들을 의존성 배열에 담다보니 결국 useEffect가 계속 돌아가게 되었고 무한 api 호출에 걸려버렸다.
  전역으로 관리하는 isLoading이 문제 발생 원인이어서 삭제해주었고, 로딩 화면 대신 낙관적 업데이트를 도입하여 문제를 해결하였다.

Try

• 팀원들 문제에 적극적으로 뛰어들기
  무한 api 호출로 골머리를 앓고 있을 때 팀원들이 다같이 고민해 준 게 많은 도움이 되었다. 무슨 문제든 함께 해결하려는 태도 가져야겠다.