17:00 ~ 17:30 5분 브리핑 세션 😵😵
5분 브리핑 세션은 직접 영상을 찍고, 내가 맡은 부분에 대해서 소개하는 느낌이다. ( 예전 트랙에서는 중간 발표라는게 있었다는데, 그것에 대한 대체 방식이고, 다른 의미로 내가 구현한 코드를 남들에게 소개해보는 연습 자리 일수도 있을것 같다. )
벌써 6월이다.. 어느덧 2월에서 시작한 캠프가 벌써 끝을 향해 달려가고있고 시간이 참 빠른것 같다.
오늘은 저번 금요일부터 시작해서, 휴일포함 문제 관리 기능을 구현하였다.
PR을 올리기전에 팀원 한분에게 찾아가서, 검사를 받고 올렸다.
git rebase문을 한다고 하기도하고, 여러 과정을 겪었다.
rebase란?
커밋을 다른 베이스 끝의 최상위에서 적용, base를 재설정한다는 의미
git rebase <target branch>
= '나를 쟤 위로 올려'
쉽게 생각하면 이런의미 이다. 한 팀원분이 git rebase에 대해서 잘 알려줘서 안전하게 PR까지 올릴수 있었다. 실제로 git rebase를 해보는 것은 처음이다. git rebase를 하면 커밋 히스토리가 시간순서대로 반영되어 이력관리가 용이해져서 관리하기 편해진다.
이를 함으로써, merge를 통해 발생하는 불필요한 병합 커밋을 제거할 수 있다
⭐ 문제 관리 기능
자세한 코드는 아래의 내용에서 커밋 이력으로 확인해 볼수 있다.
https://github.com/ezcode-my/backend/pull/17/commits
4 Layer 아키텍처 구조를 처음 사용하는 만큼 많은 시행착오가 오고 갔다.
각각의 계층에서 어디에다가 예외처리를 해야하는지 어떤 의존성을 주입받아야하는지, Repository와 구현체에 적절한 메소드나 쿼리문을 사용하고 있는지, 팀 컨벤션 규칙에 맞춰서 Dto는 record 방식으로 사용하고 디자인패턴은 builder 패턴으로 방식으로 쓰자는 등등 여러가지 난관이 있었다.
📃 개선 사항
- 기능은 동작하나, 아직 문제 등록, 수정, 삭제 기능은 관리자가 사용하게 처리되지 않음. ➡ Spring Security가 적용되어야함.
- 목록 조회시, 카테고리 Enum 필드만 검색됨 ( 정확히 입력해줘야 함 ) ➡ 고도화에서 다룰 내용
- 문제 이미지는 일단 후순위로 둠 ( 현재 없음 )
- 구현체 에서 update, delete 처리하기 ( 구현체 변경에 유연해지기 위함 )
- ProblemDomainService에서 ( 한 팀원의 요구사항 )
직접 글로 작성해보니 많은 생각보다 많은 개선사항들이 있었다.
해당 개선사항들을 필두로 코드 리팩토링하는 시간을 가져봐야 겠다.
새로운 아키텍처를 시도해본 팀 프로젝트 이지만, 그래도 처음이지만 나름 선방한것 같다.
항상 기존에 충실한 것도 좋지만 새로운 것에 대해서 도전해보는 것도 나는 좋다고 보고 있다.
처음 한다고해서 그것에 대해 두려울수 있지만, 점차 적응 해나가는 나의 모습이 성장해나가는 것 같아서 뿌듯하다.
조금더 보완해 나가야겠다. 이후 테스트 케이스 CRUD도 마저 완성할 계획이다.