프로젝트 회고 정리

[blcklamb]

KEEP

---

잘하고 있는 점. 계속 했으면 좋겠다 싶은 점.

• 하루 2번 스크럼 ⭐⭐⭐⭐
• 편하게 질문할 수 있는 분위기
• API 문서 작성
• Figma 활용으로 시각화-의견 충돌 감소 효과
• 디스코드를 활용한 빠른 소통
• 스프레드 시트 활용한 의견 공유 및 추합

• 피피티 공유 사이트 활용

  PROBLEM

  ---

  뭔가 문제가 있다 싶은 점. 변화가 필요한 점.

• 디스코드만 썼어도 되지 않았을까? 하는 생각이 들었다.
• 엘리스 강의실보다 디스코드가 훨씬 더 편하다
• MUI 커스터마이징을 활용한 대가로 CSS가 난잡해지면서 전체적으로 코드가 더러워짐 ⭐⭐
• 우선순위 파악이 잘 되지 않아 활용 난이도가 높았다
• 주석을 잘 달지 않음
• 코드 로직은 알겠으나 코드 작성 이유를 알기 어려웠다
• api 자동화 연동시켰으면 더 좋았을 것 같다.
• 토큰 만료 로그아웃 기능 만들었음 좋았을 것 같음
• 더 많은 리코일의 기능을 활용하여 리코일의 장점을 극대화 시키지 못한 점?⭐⭐
• 반응형이 아쉬웠음
• 백엔드 에러 핸들링 취약-마지막 발생한 data.category 오류는 결국 원인을 파악할 수 없었다
• 백엔드 기반 수립 불안정-잦은 API 수정으로 프론트엔드와의 소통에 큰 지장을 안겼다
• 기능 테스트 부족-마지막 배포 전에 급하게 기능 테스트를 하여 이전에 찾을 수 있던 오류를 너무 늦게 찾았다
• 주기가 긴 develop merge - 기능 테스트 및 기능 추가를 위해 필요한 작업이 늦어졌다
• 더 잦은 커밋을 했으면 좋았겠다
• 깃랩 마일스톤 및 이슈를 기능을 소극적으로 사용한점.
• 스크럼 시간이 너무 늦었다.

• 오후 스크럼이 늦은 시간에 진행되었고, 스크럼 진행 시간도 길었다.

TRY

---

잘하고 있는 것을 더 잘하기 위해서, 문제가 있는 점을 해결하기 위해서 우리가 시도해 볼 것들

<나왔던 의견들>

• styled component, emotion 사용법을 더 숙지해 효율적으로 사용하기

• MUI를 커스터마이징해서 사용할거면 확실하게 사용하기

• 리코일 select 기능을 전혀 활용하지 못했는데 관련해서 더 많은 공부 시행

• 협업과 시간 단축을 위해 처음에 각 MVC에 어디서 어떤 에러 핸들링을 할 것인지 회의하고 코드를 짜기 시작한다.

• 하루 두 번 스크럼을 10시와 5시로 정하고, 스크럼 시간이 길어지는 것을 방지하여 해당 스크럼을 위해 각자 한 것을 미리 정리하고, 준비한다.

• 스크럼은 30분 이내에 마치고, 문제 해결을 위한 시간은 필요 인원들끼리 따로 방을 만들기(한 번에 여러 문제 해결을 하려다 보니, 오디오가 겹치는 등의 문제가 발생했던 것 같음)

• 스크럼 자신이 할 것 1-2분으로 짧게 공유하고 앞으로 할 것 이슈에 간단하게 정리해 등록한다.

• 스크럼 직후 작은 단위로 쪼개 본인의 이슈를 작성한다.

• 자신이 개발할 부분을 코딩하기 전에 먼저 마일스톤과 이슈에 자신이 어떤 일을 하고 있는지 마일스톤엔 전반적인 부분을, 이슈는 그 기능을 세부적으로 쪼개서 작성하기.

---

최종 실행해야하는 Try

• 1 행위 1 커밋 💪🐽🚀🍊🌵

• 하루 두 번 10시, 5시 스크럼 전 각자 한 것을 미리 정리한다. 스크럼은 해당 부분을 2분 이내에 짧게 공유하는 것으로 시작해 30분 이내에 마친다. 스크럼 후 앞으로 할 것 간단한게 정리해 깃 협업 툴 마일스톤 및 이슈로 등록한다.(마일스톤은 전반적인 부분, 이슈는 해당 부분을 세부적으로 쪼개서 작성) 🐽💪🛠🍊🚀🌵

• swagger 사용법을 익혀 api가 실시간으로 업데이트되고, 바로 api 테스트를 할 수 있도록 기반을 다져놓는다.🍊🐽🛠🚀🌵

  앞으로의 계획

  ---

  <아래 두 가지 경우가 있음>

• 엘리스 트랙이 끝난 후라면 전격으로 참여할 의향 있음

• 끝난 후에 확실하지 않은 경우

<만약에 한다면>

mui, 반응형, refactoring

에러핸들링

swagger api 수립