KEEP
📌 현재 만족하고 계속 이어가고 싶은 = 유지할 부분
- 나를 위한 커밋이 아니라 팀원을 위한 커밋을 하기 위해 메시지 내용을 어떻게 쓸 지 고민해
- 프로젝트를 진행하면서 활용하면 좋을 것 같은 다양한 로직과 기술을 사용하고 공유함 (코드 컨벤션, 소스패키지 구조 시각화 등)
- 정규표현식과 regxp 를 사용해 입력패턴을 적용해 봄
- 팀의 분위기를 긍정적으로 이끌어가기 위해 노력함
- 깃 컨벤션을 미리 정해놓은 부분이 좋았음
- 코드의 안정성을 위해 공통 기능을 우선적으로 준비하고 프로젝트를 시작했던 점이 추후 도움이 되었음
- 비즈니스 로직 간소화
- 검증 로직은 별도 메서드로 이원화
- 팀원들과 화목한 관계 추구 노력
PROBLEM
📌 불편하게 느꼈고 수정하고 싶은 부분 = 문제였던 부분
- 선행학습이 부족해 다른 팀원이 사용하는 기술을 이해하지 못함
- 계획을 세우지 않아 시간을 효율적으로 관리하지 못하고, 개인 학습 시간을 전혀 가지지 못함
- 깃허브 커멋 컨벤션이 엄격하게 지켜지지 않음
- 테이블 설계시, 처음에 고려치 못한 부분에 대해 우선순위에서 밀렸다는 이유로 반영 못함
- 다른 브랜치에 푸쉬하는 실수를 저질렀음
- 실제 애플리케이션 배포까지 경험해보자라는 목표로 프로젝트에 임했지만 AWS에 대한 이해 부족으로 배포 단계까지 가지 못함
- 예외 처리를 다소 복잡함. 어느 수준까지 분기할 건지 고민 필요
- API Url 설계할 때 조금 더 RESTful하게 만들 필요가 있음. url path만 보고 어떤 역할을 하는지 이해하기 쉽지 않은 API 다수
- 소규모 프로젝트라, 패키지 구조를 [controller, service, repository, domain, dto ...] 이런 식으로 만들었는데, 생각보다 DTO 클래스가 많아 조금만 더 프로젝트 규모가 커지면 유지보수 불가. domain 단위 패키지 구조로 마이그레이션 고려
TRY
📌 문제 해결을 위해 실행 가능한 것들 = 앞으로의 목표
- 혼자 해보기엔 어려웠던 기능을 팀원들과 협업하면서 시도해보기
- 계획표를 꼭 세우고, 개인 학습 시간 챙기기
-
다음에는 컨벤션을 더 확실히 정하고 프로젝트를 시작하기
-
타 팀의 잘한 점을 최대한 흡수하기, 새로운 인사이트를 얻기
- 우선은 필요 기능을 모두 구현하고, 디테일을 살리기
- 데이터베이스 설계나 sql에 대해 공부를 더 해야겠다는 생각이 들었음
- 기능을 왜 쓰는지, 어떻게 쓰는건지 정확히 파악하는 것이 가장 중요하다는 것을 알게됨
- 다음 프로젝트에서는 간트 차트를 작성해 보고자 함
- 테스트 코드를 작성
- 더미데이터를 정합성 있게 제조
- 테스트 코드가 github에서 자동으로 빌드되고, 애플리케이션이 자동으로 서버에 배포되는 단계까지 적용
-
AWS, Docker, 쿠버네티스, 엘라스틱 서치, 레디스, 카프카 적용
-
깃에 대한 상세 학습
[ 참고 자료 ]
'Project > Spring' 카테고리의 다른 글
일정표를 만들어 보자! 업데이트! (2) | 2024.12.19 |
---|---|
일정표를 만들어 보자! (2) | 2024.12.09 |
[ Spring ] 쇼핑몰 프로젝트 회고 (0) | 2024.11.25 |