여덟 번째 프로젝트 (팀) - 잼렐로 API KPT

 

오늘 일을 내일로? 잼렐로와 함께라면 바로바로!

😎 GitHub

JamminTeam

😎 UI/UX

😎 ERD

😎 KEEP

• 설계
  • 코드 컨벤션 통일을 함으로써 코드 통일성을 확보하여 가독성을 높혀서 좋았습니다.
  • 컨벤션 덕분에 통합하기에 어려움이 적었습니다.
  • 상황 간 메서드명을 규칙을 정함으로 써, 메서드를 활용해야 할 때 예상이 가능해서 좋았습니다.
• 코드 리뷰
  • 깃허브의 적극적인 PR의 코드 리뷰 활용으로 부족한 점을 파악함으로써 실력 향상이 될 수 있었습니다.
  • 상호 피드백을 통해 미처 발견하지 못한 부분을 확인 할 수 있어 좋았습니다.
• 회의
  • 정해진 시간에 회의 및 회의록을 작성해서 좋았습니다.
  • 회의 시작전 회의 때 말할 내용들을 10분전에 정리해서 회의를 시작하니 수월하게 이루어졌습니다.
• 참여도
  • 팀원 모두의 적극적인 참여가 이루어져서 좋았습니다.

😎 PROBLEM

• 엔티티 그래프를 적용하여 FetchJoin을 대체하려고 했으나, 엔티티 그래프만으로는 해결되지 않았습니다.
• S3 에서 putObject와 inputStream 중 어떤 것을 사용해야할지 고민이 됐습니다.
• 프론트엔드를 구현하지 못해서 아쉬웠습니다.
• 작업한 파일이 있는 상태로 로컬에 Pull 할 때 Conflict 해결에 시간을 들였습니다.
• 잘못된 브랜치에서 작업한 것을 취소하고 다시 커밋하는 시행 착오를 겼었습니다.
• 엔티티 변경 전이 오류를 겪었습니다
• 환경 변수가 테스트 코드 동작 시 적용이 되지 않아 잦은 에러가 있었습니다.
• CI/CD 환경에서 TestDB를 MySQL로 사용하고 싶었는데 끝내 사용하지 못해서 아쉬웠습니다.

😎 TRY

• 엔티티 그래프를 적용하여 FetchJoin을 대체하려고 했으나, 엔티티 그래프만으로는 해결되지 않았습니다.
  • 개발 일정을 고려하여 엔티티 그래프를 포기하고, 쿼리문을 직접 던져서 해결 하려하였으나, 여기서는 N+1 참조가 발생했습니다.
  • 그래서 엔티티 연관 관계를 활용하여 해결했습니다.
• S3 에서 putObject와 inputStream 중 어떤 것을 사용해야할지 고민이 됐습니다.
  • 둘 다 장단점이 있었습니다. putObject는 로컬에 데이터가 저장되는 단점이 있으나, 안정적이며 inputStream은 그 반대로 램을 사용하여 속도가 빠르고 로컬에 저장되지 않는다는 장점이 있지만, 안정적이지 않다는 단점이 있었습니다.
  • 소규모 팀프로젝트이기 때문에, 어떤 것을 적용해도 큰 문제가 되지 않을 것이라 판단하여 putObject를 적용했습니다.
• 프론트엔드를 구현하지 못해서 아쉬웠습니다.
  • 최소한의 프론트엔드 구현을 위해 Js를 익혀야 겠습니다.
  • Client가 인증 인가를 어떻게 하는지 타임리프의 서버 사이드 렌더링 방식이나 Stateless or Statefull 한 방식에 대한 이해가 필요할 거 같습니다.
• 작업한 파일이 있는 상태로 로컬에 Pull 할 때 Conflict 해결에 시간을 들였습니다. / 잘못된 브랜치에서 작업한 것을 취소하고 다시 커밋하는 시행착오를 겼었습니다.
  • 깃과 깃허브에 대한 연습 및 숙련이 필요합니다.
• 엔티티 변경 전이 오류를 겪었습니다.
  • JPA에 대한 연습 및 숙련이 필요합니다.
• 환경 변수가 테스트 코드 동작 시 적용이 되지 않아서 잦은 에러가 있었습니다
  • 사용할 기술과 필요한 환경변수를 미리 준비하고 설정을 마친 상태에서 프로젝트를 시작해 빌드에서 발생할 에러를 사전에 방지합니다.
  • 테스트 코드 템플릿 활용으로 모든 테스트 코드의 환경 변수를 일괄적으로 관리해서 해당 문제를 사전에 방지합니다.
• CI/CD 환경에서 TestDB를 MySQL로 사용하고 싶었는데 끝내 사용하지 못해서 아쉬웠습니다.
  • Docker Runner에 대해서 어떻게 연결해야 하는지 공부가 필요합니다.