나의 첫 번째 팀 프로젝트 회고

2주 반동안 진행한 첫 번째 팀 프로젝트가 완성되었다.
잠깐 돌이켜보고 내일부터 바로 새로운 프로젝트에 들어간다..!
이번 경험으로 배운 것들, 반성할 것들 놓치지 말고 다음 프로젝트에 꼭 가져가야지.

성장한 모습으로 더 잘 해내고 싶다.
팀워크도 그새 좋아졌고 이번엔 손발도 더 잘 맞을 것 같다.

기대된다~!!

📔 개발 회고

다들 처음이다 보니 집중과 선택이 제대로 이루어지지 않아서 초반에 루즈하게 흘러갔고, 후반에 우당탕탕 작업을 마쳤다. 전체 일정을 정해두지 않아서 각자 작업 시간도 다르고 프론트와 백 간의 속도 차이가 났다.

좋았던 부분

• 프론트끼리는 작업 속도가 맞았던 것 같다.
• 원래 목표했던 기능을 다 구현한 점. 기능 선정이 적절해서 주어진 시간을 살짝 부족한듯 빠듯하게 잘 사용한 것 같다.
• 새로운 라이브러리를 공부하고 사용했다. (zustand, toast ui)

아쉬웠던 부분

• 토큰 저장 방식을 전체 회의를 통해 정하지 않은 것
• API 명세서, 응답 데이터 형식을 비교적 늦게 알아서 API를 사용하는 로직이 늦게 완성되고 오류도 늦게 발견하게 된 것
• 구현에 필요한 데이터를 요청할 엔드포인트가 만들어지지 않아서 결국 기능을 하지 않는 컴포넌트로 배포하게 된 것(내가 쓴 질문, 답변 확인 불가 / 멤버 정보를 로그인시 로컬스토리지에 저장하여 이곳저곳에서 사용)
• 프론트간에는 세세한 코드 컨벤션 정립을 하지 않아서 결과물을 보니 깔끔하지 않았던 점
• 깃허브 이슈 작성 & 브랜치를 만들고 삭제하고 새로 만드는 작업을 후반부로 갈수록 제대로 하지 않았다.

개선할 부분

• 다음에는 공통적인 API 요청 형식, 스타일 컴포넌트를 여러 번 작성하지 말고 공통 사용 폴더에 작성해 놓으면 효율이 좋아질 것 같다.
• 코드 컨벤션을 더 세세하게 맞춰놓기
• 작업 초반부터 API를 사용하면서 작업하면 좋을 것 같다. 오류를 초반에 잡으면서 하고 싶다. 어렵다면 응답 데이터 형식이라도 알아와서 json-server를 이용해야겠다.
• 체력 분배를 잘 해서 처음부터 끝까지 일관된 건강&마인드를 가지고 싶다.
• 첫번째 프로젝트에서는 개인의 역할, 기능 구현에 초점을 맞췄다면 메인 프로젝트에서는 팀 단위의 협업과 협업 방식에 초점을 맞춰서 임해야겠다.
• 취업과 직결돼있으므로 더 열심히 공부하고 더 책임감을 가지고 임하기
• git-flow 더 잘 활용하기

---

📓 개발 외 개인 회고

좋았던 점

처음 계획했던 기능을 모두 구현한 것

아쉬웠던 점

체력을 초반에 많이 쏟아서 후반부로 갈수록 할 게 더 많아지니까 몸과 마음이 힘들어졌다. 배포 일정을 정하고 시작하고 싶었는데 전체적으로 팀 일정 관리가 제대로 이루어지지 않아서 배포를 기한 내에 못 마쳤다.

다음에 도전해보고 싶은 것

• 그동안 하지 않았던 방식으로 세련된 UI 구현하기
• 그동안 하지 않았던 어렵고 까다로운 기능 구현하기
• 단순한 게시판, 블로그 기능의 웹 사이트 말고 다른 기능이 주가 되는 웹 사이트 만들기

---

📮 팀 회고

1. 분석/설계 회고

좋았던 점

• 기획할 때 와이어 프레임을 짜임새 있게 만들어서 구현할 때 수월하게 흘러갔음
• 반응형 웹을 적용해서 보다 더 유연하게 설계

아쉬운 점

• 공통적으로 들어가는 레이아웃이나 CSS를 정하지 못한 점
• API 명세서에 대해 응답으로 받는 json 구조가 어떻게 되는지 몰랐다는 부분 때문에 수정을 거듭하는 수고 발생
• 서버와의 통신이 어떻게 이루어질 것 인지에 대한 구체적인 생각이 떠오르질 않아 API 명세서를 작성할 때, 어떤 게 필요한 지에 대해 요구하지 못한 채 넘어갔다는 점

개선할 점

• 화면 정의서를 만드는 데 익숙해질 필요가 있음
• 기능 단위로 시간 계획을 체계적으로 세워서 앞서 말한 아쉬운 부분이 발생하지 않게 하는 것이 중요
• 백엔드와의 협업에서 구체적인 기능 구현 일정을 짜는 게 중요

2. 구현(개발) 회고

좋았던 점

• 프론트와 백 간의 원활한 소통으로 주요 기능을 모두 구현

아쉬운 점

• git flow 를 처음부터 끝까지 잘 지키지 못한 것
• 새로운 라이브러리(zustand)를 프로젝트에 도입했으나 제대로 활용하지 못해서 아쉬움이 있다.
• 전체 일정을 구체적으로 잡지 못하여 작업 환경에 까지 영향을 미치게 돼 시간이 갈수록 힘들었던 것

개선할 점

• github 이슈, 마일스톤을 처음부터 끝까지 성실하게 작성
• 공통적인 로직은 따로 분리해서 만들어 놓는 효율적인 코드를 작성

3. 배포(검증) 회고

좋았던 점

• 어려웠지만 결국 aws s3 및 EC2 배포에 성공 한 점

아쉬운 점

• 배포 일정을 미리 정해두고, 에러 잡는 날도 따로 빼놓았으면 좋았을 것 같다.
• 배포를 여유롭게 마치고 실제 사용하는 시간을 가지며 UX 점검을 했으면 좋았을 것 같다.
• 이미 많은 점검을 마쳤다고 생각했는데도 배포가 끝난 후 아쉬운 점들이 보여서 클라이언트를 다시 배포해야 했다.
• CORS 허용이 되어있지 않아서 마감날에 배포를 마치고 통신에 실패한 것을 확인했다.
• AWS 사용 방법이 어렵다는 것을 알고 있었음에도 미리 시작하지 못해서 마감 기한을 넘기고 배포에 성공했다.

개선할 점

• 배포 일정을 미리 잡고, 그 이전까지 개발 작업을 완료하도록 해야 한다
• 마감 기한을 반드시 지킨다. 마감 기한까지 에러 점검까지 마치고 완벽하게 완성한다.
• 배포일을 제외한 시간동안 만들 수 있는 기능만 도입한다. 배포일까지 못 만들게 되면 과감히 삭제한다