[240103] 심화 주차 KPT회고

Keep (계속 이어갔으면 하는 부분)

• infra 활용해서 하고 싶은 것들 다 해볼 수 있었음
• 팀원들의 적극적인 참여, 코드 리뷰를 통해 완성도 높은 프로젝트가 나올 수 있었음
• 컨벤션을 설정하고 지킴으로써 통일성 있는 코드를 작성함
• Issue와 PR을 적극적으로 활용함
• CI/CD 환경을 구축함으로써 여러 팀원이 개발에 참여했음에도 충돌의 문제 등 불필요한 시간을 보내지 않음
• 팀원 모두가 Rivew를 작성함으로써 코드 개선에 도움이 됌
• 컨벤션을 미리 잡고 프로젝트를 시작한 점.
  • 그리고 이를 sample 디렉토리로 프로젝트 시작때 만들어 둔 것.
  • 단순히 문서화 이상으로 어떻게 코드를 작성해야하는지 바로 확인하며 작성할 수 있어서 아주 좋았음
• 스타일 가이드를 미리 적용해놓고 시작한 점.
  • Google style guide 로도 줄바꿈에는 팀원마다 달랐지만, spotless를 통해 이마저도 강제하여 충돌난 경우가 확연히 줄어들게 됨.
• 리뷰 및 소통, 참여에 적극적
  • PR 하나에 최대 41건의 리뷰가 달릴 정도로 리뷰에 적극적이며, 문제가 발생해도 서로 해결하려고 함.
  • 커밋 수가 700개가 넘을 정도로 다들 열심히 함
• redis를 토큰 관리 뿐만 아니라 mail 서비스에도 활용해볼 수 있어 좋았음
• convention을 정하고 개발하면서 전체적인 통일성을 지킬 수 있었음
• github actions, issue, PR 등을 적극적으로 활용하여 프로젝트를 진행하여 보다 효율적으로 완성도 높은 성과를 낼 수 있었음

 

Problem (개선이 필요한 부분)

• 코드 리뷰가 원활했음에도 파악하지 못한 코드 실수가 있었음
• 잘못된 설계로 인한 버그가 다수 발견되었음
• 이후에 ERD를 변경하면서 코드 변경이 발생함
• 본인 기능에 집중하다 보니 다른 기능에 대해 온전히 파악하지 못함
• 짧은 기간 안에 완성해야 한다는 압박감에 더 꼼꼼히 설계를 하지 못해서 중간에 연관 관계가 한번 바뀜
• 모르는 기술을 코드에 접목 시키는데 시간이 오래 소모되어 시간 분배를 실패
• 문제가 없어서 문제를 찾을 수 없어서 문제였다.
• 프로젝트 시작 전에 도입을 고려했던 기술적 도전을 다 해보지 못해서 아쉬웠다.
• softDelete 도입 당시, 단순히 생각하여 softDelete를 적용하지 않아도 되는 테이블에 적용하였음.
• 설계를 조금 더 꼼꼼히 해야 할 필요성을 느낌
• 단기간 내에 완성도 높은 결과물을 내려다 보니, 중간 중간 소통이 급하게 이뤄져 전달이 잘 되지 않았음.

 

Try (Problem에 대한 해결책)

• 좀 더 체계적인 코드 리뷰가 필요하다고 생각함
• 최종 프로젝트에는 설계에 시간 투자가 많이 되어야겠다는 생각이 들었음
• 기능에 대해 이해한 뒤 ERD를 꼼꼼하게 작성할 필요를 느낌
• 서로 각자가 맡은 부분을 설명하는 시간을 가지면 좋을 듯
• 기술 명세서를 작성할 때 예외 케이스인 부분을 고려하지 못하면 개발할 때 놓치기 쉬운 거 같음 -> 더 꼼꼼히 기술 명세서 작성
• 접목하고 싶은 기술이 있다면 사전에 얉게라도 공부를 하고 접목 하면 좋다고 생각함
• 앞선 프로젝트들에서 겪었던 시행착오들로 프로젝트를 시작하는데 준비하는 시간을 압축하면 좋을 것 같다.
  • 컨벤션 정리, CICD 적용, 깃허브 이슈 및 PR 템플릿 적용, 기획, 등
• CI/CD, 배포 등 아직 시도해보지 못한 부분이 많아 아쉬움. 시도해 보겠음.
• 이번 프로젝트를 기반으로 다른 프로젝트에도 적용하여 보다 완성도 높은 프로젝트를 진행할 예정임.