회고 및 정리

✨ Liked (좋았던점)

승은

• 지금까지는 작은 규모의 실습정도로만 개발을 진행해오다보니 전체적인 큰 틀을 보지 못하고 개발을 했던것 같고, 그로 인해 개발을 하면서도 확신을 갖지 못했었습니다. 이번에 나름 큰 프로젝트를 직접 설계하고 개발을 해보니 전체적인 개발 과정을 확실하게 파악할 수 있었고, 그 과정속에서 각각의 Layer들을 어떻게 생각하면서 구현해야하는지 많은 깨달음을 얻었습니다! 기본적인 개발 과정도 확실히 손에 익힐 수 있어서 좋았습니다!!

• 협업을 하면서 다양한 툴을 써본 것도 좋았습니다! Jira, Notion, Slack, Git Organizaion 등 실무에서도 사용하는 툴을 경험해본 것도 좋았고, 팀원분들이 잘 알려주신 덕분에 수월하게 익힐 수 있었습니다!

• Git Flow를 적용시켜서 프로젝트를 진행한 부분도 좋았습니다! 팀원들이 기능 개발을 진행할 때 각자 브랜치를 따서 나중에 합치는 과정에서 굉장히 많은 conflict를 경험했고, 덕분에 rebase와 merge를 확실히 파악할 수 있었습니다!!

• DB 테이블 설계 및 전체적인 프로젝트 설계를 직접 해보면서 팀원들의 다양한 생각을 고려해볼 수 있었던 것도 좋았습니다! 다 비슷한 생각으로 금방 설계가 끝날 줄 알았는데 의견이 다른 부분들을 해결해나가는 과정에서 많이 배운 것 같습니다!

찬의

• 깃허브, 슬랙 그리고 노션 등 다양한 툴을 사용하여 협업을 해보는 것이 처음이었는데 코드 리뷰가 왜 필요한지, 어떻게 이슈를 관리하는 것이 좋은지, 어떤 git 전략을 사용할지 등등 협업을 효과적으로 할 수 있는 방법에 대해서 많이 배울 수 있어서 좋았습니다.

• 테이블 설계부터 비즈니스 로직에 대한 API까지 구현하면서 세세한 부분 하나하나 팀원들과 의견을 공유하고 조금씩 개선해 나갈 수 있었던 점이 좋았습니다.

민희

• 협업을 하면서 Git Flow 를 활용하는 방법에 대해 배웠습니다. 특히 Git Rebase를 하면서 Conflict를 띄워주는 단위가 Commit 단위였던 것으로 파악되는 것으로 보아 왜 커밋을 잘게 쪼개야하는지, 작업단위로 혹은 팀에서 정해진 방향으로 따라가야하는지를 경험 할 수 있었습니다.

• 같은 구현에 대해서도 서로 다른 방법을 떠올릴 수 있다는 점이 새롭고, 좋았습니다. 제 생각에서 벗어나서 다른 분들의 생각을 이해할 수 있는 시간을 가질 수 있었습니다.

• 잘 모르는 것이 생겼을 때 같이 상의하고 멘토님께 여쭤볼수 있었던 시간이 좋았습니다.

• 팀원들의 역할이 생각보다 아주 아주 아주 아주 잘 정해졌던것같습니다. 승은님이 탱커처럼 후다닥 많이 잘 만들어주시고 찬의님이 개선할만한방법을 던져주시고 저는 알아보면서 적용해서 알리고 각자 맡은 역할에 최선을 다해주셨어서 감사했습니다.(sm po developer도 잘정했던것같습니다)

✍ Learned (배운점)

승은

• 학습 기록 / 에러 해결 모음 정리

• 저는 개인적으로 이번 팀 프로젝트를 통해 기본적인 개발 과정을 손에 확실히 익히고 싶었습니다. 이번 프로젝트를 비교적 크게 설계해서 많은 숙달을 이뤄낼 수 있어서 아주 만족스럽습니다!

• 개발을 하는데 있어서 기본기가 확실해야 빠르고 정확하게 원하는 서비스를 개발해낼 수 있을거라고 생각해서, 기본기에 많이 집중했습니다. 각각의 Layer를 설계할 때 필요한 부분을 확실히 배웠습니다.

• DTO를 설계하는 부분도 이번에 많이 배웠습니다. Service Layer에서 Converter를 통해 Dto로 converting 할 때, Service Layer에서만 Repository를 사용하도록 하는 것을 간과하다가 제대로 수정했습니다!

• Service도 인터페이스를 사용하는 것도 새로 알게됐습니다! 유지보수(기능개발)를 할 때 좀 더 유리하고, AOP도 인터페이스에 적용할 수 있다는 이유로 사용하는군요!

• @PathVariable, @RequestParam, @RequestBody을 활용한 controller 설계를 확실히 배웠습니다!

• 유용한 어노테이션들을 배웠습니다! @SuperBuilder: 싱글테이블 전략에서 Builder를 사용해야 할 때 사용, @Builder.Default: Builder 패턴을 이용할 때 엔티티 필드를 초기화해줘야 하는 경우 필드에 붙이면 초기화가 먼저 실행됨(연관관계 편의 메소드에서 초기화 작업을 생략 가능) @Transactional(readOnly = true): repository를 통해 save 하지 않고, 조회만 하는 경우 사용할 수 있다. 스냅샷을 안찍는 등의 성능 향상. @JsonFormat, @JsonValue, @Convert(converter = ~.class): Enum 타입을 Json으로 변환 가능하게 한다. DB에 들어가는 문자열을 convert 할 수 있다.

• 다양한 에러를 해결하면서 많은 부분을 배웠습니다!! (에러 해결 모음에 정리)

찬의

• 다양한 어노테이션을 활용하는 방법이나 스프링 스케쥴러, soft delete구현하는 방법, 메소드 쿼리 등등 기술적으로 배운점도 많았지만 어떻게 계층 구조를 효과적으로 설계할지 또는 클린코드를 구현할 수 있을지 고민하면서 배운점이 많았던것 같습니다.

• 예를들어 Dto를 이용하여 요청과 응답에 대하여 필요한 값들만 전달할 수 있으며, 엔티티들은 service내의 트랜잭션에서만 관리함으로써 컨트롤러와 서비스계층간의 역할과 책임을 분리할 수 있었습니다. 이러한 Dto내에서도 목적에 맞게 깊이를 늘려 세분화 할 수 있었습니다.

• 프로젝트에는 아직 제대로 구현이 되어있지 않지만, 지역을 구분하거나 Type을 구분할때 분기문을 줄이기 위해 Enum을 활용하는 방법을 배웠습니다.

• 단일 책임 원칙을 지키기 위해 구조를 세분화 할수록 얻을 수 있는 장점이 많다는 것을 배웠습니다. 추가할 사항이나 변경사항이 생길 경우 그 대상이 명확해서 좋았습니다. 예를들어 특정 Api의 응답 Dto에 필드를 추가하고자 한다면, Converter만 변경해 주면 되었습니다.

민희

• JPA에서 연관관계(편의) 메서드의 필요성을 익힐 수 있었습니다.

• SpringScheduler를 처음 사용해보았고,시간 설정에 맞춰 쉽게 업데이트 가능한걸 배웠습니다.

• 프로젝트를 하면서 처음 접한 어노테이션들이 꽤 많았는데 사용방법을 익힐 수 있었습니다.

@ResponseStatus
@JsonFormat(shape = JsonFormat.Shape.OBJECT)
@JsonValue
@Converter
@ElementCollection
@CollectionTable
@SuperBuilder
@Builder.Default
@JPAIgnore
@SQLDelete
@Where
@DynamicInsert
@Scheduled
@Access

🕯 Laked (아쉬운점)

승은

• 아직 부족한 실력으로 좀 더 퀄리티있는 서비스를 만들지 못한점이 아쉽습니다 😢 이번에 많이 배웠으니 다음 프로젝트는 더욱 고퀄로 만들수 있을 것 같습니다!!

• 엔드포인트는 팀원이 업무 분담을 해서 각자 만들었는데, 엔드포인트 정도는 같이 상의를 해봤어도 좋았을 것 같습니다!

• Git Flow를 지키긴 했지만, rebase가 미숙하여 브랜치가 난장판이 됐습니다.. 이것도 다음 프로젝트 떄는 완벽하게 rebase 해 볼 계획입니다!!

• 외부 API를 연동하는 부분을 미완성으로 끝냈습니다. 이 부분은 계속 보완하면서 추가할 계획입니다!

찬의

• 이슈관리를 슬랙 팀 채널에서 채팅으로 처리를 했는데 의미전달이 잘 안되거나 적용이 잘 안됐을 때도 있었고 개인적으로 지난 이슈내용들을 확인하기도 불편한점이 있었습니다. 다음부터는 Jira나 Github 이슈를 사용해볼 생각입니다.

• 저희팀은 PR을 보내지 않고 필요할때 개인적으로 Merge & Rebase 하거나 함께 충돌처리를 하며 프로젝트를 업데이트 했는데, 그 때문에 자연스레 팀원들간의 코드리뷰가 많이 부족했었고 변경 포인트에 대해 명확한 설계가 되지 않거나 공유한 이슈에 대한 내용들이 잘 적용이 안되어 수정할 내용도 많았던것 같습니다.

• MoSCoW를 이용하여 구현할 내용들에 대해 우선순위를 나눠 봤는데요, 큰 어려움이 없을거라 생각하여 추가한 기능과 테이블들 이었지만 Product를 두가지로 나누면서 단일 테이블 전략을 사용했는데 이와 관련된 부분들이 예상과는 다르게 찾아볼 내용들이 많아서 어려움을 겪었던것 같습니다. 그래서 아쉬웠던 부분은 각자 맡은 외부 API를 사용하여 구현할 내용들을 프로젝트 기간 내에 구현하지 못해서 아쉬움이 남습니다.

민희

• 태도: 제가 구현한 코드에 대해서 다른분이 다른 좋은 아이디어를 제시할 때, 자기 방어적인 태도로 임했던 것 같아 아쉽습니다. 그럼에도 계속 설득해주시고 알려주셔서 배울 수 있었습니다. 👍

• 협업툴: JIRA를 적극활용하고 싶었는데 1주간 개인 프로젝트를 하는것으로 변경되면서 잘 활용해보지 못한점이 아쉽습니다.

• 다른 스케쥴(면접, 코테,..등)과 일정이 겹치면서 제가 생각했던 것에 비해 많이 못해낸것 같습니다. (S3이미지 업로드, ElasticSearch를 해보기로 했었는데..)

📚 Longed For (개선할점)

승은

• Jira를 제대로 활용을 못해보고 Notion과 Slack, Gather, GitHub로 협업을 진행했는데, 실무에서도 많이 쓴다는 Jira도 좀 더 활용했으면 좋았을 것 같습니다!

• 프로젝트가 끝난 후에 돌이켜보면서 배운점을 정리하는데 빼먹는 부분이 많은 것 같아서, 중간중간에 바로 기록을 하는 습관을 길러야겠습니다!

찬의

• 개선하고 싶은 점은 위에서 언급한 아쉬운 점(Laked)들과 관련이 있을것 같습니다.

• 팀원들과 적극적인 소통도 중요하지만 그 수단이나 방법 또한 중요하다고 느꼈습니다.

민희

• JIRA를 사용해서 업무 관리를 했다면 다른 스케쥴이랑 겹치더라도 조금더 집중을 할 수 있지 않았을까 싶었어요. 나중에 API Spec문서라고 notion에 별도로 만들어두면서 내가 해야할 일이 조금씩 명확해지는 것이 보였기 때문에, JIRA든 notion이든 이렇게 작업 관리를 해나갔더라면 좋았겠다라는 생각을 해보았습니다.