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 해결에 시간을 들였습니다. / 잘못된 브랜치에서 작업한 것을 취소하고 다시 커밋하는 시행착오를 겼었습니다. 깃과 깃허브에 대한 연습 및 숙련이 필요합니다.
-
사용할 기술과 필요한 환경변수를 미리 준비하고 설정을 마친 상태에서 프로젝트를 시작해 빌드에서 발생할 에러를 사전에 방지합니다.
-
테스트 코드 템플릿 활용으로 모든 테스트 코드의 환경 변수를 일괄적으로 관리해서 해당 문제를 사전에 방지합니다.
-
CI/CD 환경에서 TestDB를 MySQL로 사용하고 싶었는데 끝내 사용하지 못해서 아쉬웠습니다.
-
Docker Runner에 대해서 어떻게 연결해야 하는지 공부가 필요합니다.
