프로젝트를 시작하고, 최대한 주차별로 가벼운 회고를 남겨보려고 한다! 프로젝트의 시작, 회고의 시작... 1주차 시작해보자구~ ✌🏻 23.06.27 (화) - 프로젝트 시작 🏃🏻‍♂️ 1. 팀원 대면 드디어 팀원들을 처음 보게 되었다! 우리 팀은 나, BE 엔델, BE 로이, BE 필립, FE 유스, FE 요술토끼, FE 루루 이렇게 총 7명이다! 프론트엔드와는 친분이 없는게 당연했지만 백엔드에서도 그렇게 친한 사람은 없었어서 조금 걱정이 되었다. 단지 친하지 않아서 어색할 것 같았을 뿐이지, 그래도 이전에 몇 번 얘기를 나눴을 때 다들 괜찮았던 사람들이라서 좋은 사람이라는 인식은 있었다!! 😃 4~5개월 동안 같은 목표를 가지고 잘 달려보자고 혼자 다짐했다 ㅋㅋㅋㅋ 👍🏻 🌈 2. 팀 자리 배치 10시에..

이 글은 팀바팀 기술 블로그에 작성된 글입니다. https://team-by-team.github.io/event-storming/ 팀바팀 이벤트 스토밍(Event Storming) 도입기 해당 글은 우아한테크코스 5기 팀바팀 크루 성하가 작성했습니다! 🌈 이벤트 스토밍(Event Storming) 도입기 우아한테크코스 5기 팀바팀 Project에서 Event Storming을 처음 사용해보면서 적용했던 배경과 team-by-team.github.io 🌈 이벤트 스토밍(Event Storming) 도입기 우아한테크코스 5기 팀바팀 Project에서 Event Storming을 처음 사용해보면서 적용했던 배경과 적용 과정, 적용 후에 느낀점 등을 간단하게 기록하고자 합니다! 🎯 이벤트 스토밍 도입 배경 프..

🌈 0. 들어가기 전 이번에 Controller와 Service 레이어에서 Dto를 주고받는 과정에 대해 생각해보게 되었다. 이전에는 관성적으로 Controller와 Service 간의 요청, 응답 Dto 각각 하나로 관리했었다. 이때, Layered Architecture와 유지보수성의 관점에서 두 레이어 간의 Dto 사용을 다시 생각해보게 되었다. Web 요청 & 응답 시에 Controller와 Service 간의 Dto 사용에 대해 개인적인 생각을 기록하고자 한다. 🎯 1. Web 응답 : Service에서 Response Dto 생성 후 Controller에서 반환? 일반적으로, Web 응답에 Service가 Response Dto를 Controller에 반환하는 경우가 대부분일 것이다. ✅ Se..

1. 감정 회고 어제 레벨2 인터뷰를 진행했다! 레벨 2 인터뷰는 레벨 1 인터뷰와 한가지가 달랐다. 레벨 1 인터뷰에서는 자신이 공부했던 내용을 제출하고, 그 내용을 바탕으로 질문 & 답변을 했다. 하지만 이번 레벨 2 인터뷰에서는 모든 크루가 자신이 공부했던 내용을 바탕으로 질문지를 작성하고, 해당 질문지를 보면서 다른 크루들에게 질문을 하는 방식이었다. 이렇게 새롭게 바뀐 방식은 장단점이 존재했다고 느꼈다. 먼저 레벨 1 때는 내가 공부했던 부분을 제출해서 '내가 공부한 부분인데 해당 부분을 제대로 말하지 못하면 어쩌지?' 라는 생각에 더 떨렸었다. 하지만 이번 레벨 2 인터뷰는 어떤 질문이 올지 모르므로 오히려 긴장이 덜 됐던 것 같아서 좋았다. 그러나, 깊게 공부했던 부분 이외의 질문들을 많이 ..

🎯 0. 들어가기 전 테스트 시에 검증할 대상과 expected 객체의 값이 같은지 비교하는 일이 많았다. AssertJ의 usingRecursiveComparison을 알기 전까지는 객체의 getter로 값을 직접 비교하거나, equals & hasCode를 재정의해서 비교하는 경우가 많았다. 주변 크루와 리뷰어에게 AssertJ의 usingRecursiveComparison을 배우고 편하게 테스트 코드를 작성해서 공유하고자 한다! 🎯 1. 테스트 예시 하나의 테스트 예시로 usingRecursive 사용을 해보면서 익혀보자! 장바구니 상품의 영속성을 관리해주는 CartItemDao Test 예시를 들도록 하겠다! 테스트의 when 절은 다음과 같다. // when CartItem cartItem =..

0. 들어가기 전 이번에 테스트를 만들다가, @Sql문으로 초기 스키마와 데이터를 넣게 되었다. 그런데 테스트를 실행해보니 중복 데이터가 있다는 오류가 발생하게 됐다. 결론적으로, main 디렉토리 아래에 있는 초기화 sql을 실행하고 나서, @Sql의 초기 스키마와 데이터 sql을 실행해서 발생한 문제였다. Trouble Shooting 과정을 기록하고자 한다! 1. 문제 상황 기존의 sql 파일 구조는 위와 같았다. src/main/resources 아래에 프로덕션용 schema.sql, data.sql이 존재했고, src/test/resources 아래에 테스트용 test-schema.sql, test-data.sql이 존재했다. 이 상황에서 아래와 같은 테스트를 실행하니 오류가 발생했다. @Jd..

0. 들어가기 전 프로덕션과 테스트 환경에서 다른 DB를 연동해야하는 기능 요구사항이 있었다. 그래서, 스프링에서 프로덕션과 테스트 환경에 따라 다른 구성을 어떻게 하면 할 수 있는지 여러 방법을 알아보고자 한다! 1. 테스트용 properties 만들기 아주 간단하게 분리하는 방법은, application.properties 파일을 test 패키지 아래에 만드는 것이다. main/resources 아래에 application.properties는 기본으로 생성되어 있다. 프로덕션 properties와 마찬가지로, test/resources 아래에 application.properties를 생성해주면 간단하게 프로덕션 환경과 테스트 환경을 분리할 수 있다. 실제로 미션에서 application.prope..

🎯 0. 들어가기 전 흔히 API를 테스트하기 위해서, HTTP 요청을 보낼 때 Postman을 많이 이용했었다. 그래서 이전에 API를 테스트하기 위해서는 Postman을 작동시키고, API URI를 입력해서 요청을 보냈었다. API는 IntelliJ를 이용해서 작성하고 테스트는 외부 Postman을 사용하기 때문에, 불편한 점이 많았다. IntelliJ의 기능인 .http 파일을 사용해서 API를 테스트하게 되면 Postman 사용 시 보다 장점이 많다! IntelliJ에서 .http 파일로 어떻게 API를 테스트 할 수 있는지 알아보자! ※ .http 기능은 IntelliJ Ultimate 버전에서 지원된다. 무료 버전인 Community 버전에서는 지원이 되지 않는 점을 알고 가자! 🎯 1. .h..

🎯 0. 들어가기 전 MVC 패턴 & 자바 기반의 콘솔 애플리케이션에서는 관성적으로 model(domain) & controller & view 패키지를 만들고 시작하는 경우가 대부분이었다. 웹 애플리케이션을 구현하면서, 설계 단계에서 관성을 버리고 패키지 구조에 대해서 고민하기로 했다. 그리고 설계하면서 설계 단계에서 패키지 구조에 대한 고민을 겪었다. 늘 하던 것처럼 '계층형'으로 패키지 구조를 만드는 것이 좋을까? '도메인형' 구조가 있다는데 이 구조를 적용해볼까? 계층형과 도메인형 둘 중 하나를 선택하기 위해, 두 구조의 장단점을 비교해보자. 장바구니 애플리케이션이라고 가정하고, 도메인이 'Member', 'Product', 'Cart'가 있다고 하고 비교해보자. 🎯 1. 계층형 구조 contr..

❌ 문제 상황 테스트 시에 각각 개별 테스트는 통과했지만, 모든 테스트를 한 번에 돌리니 오류가 발생했다. 대충 요약하면, 이미 DB에 테이블이 초기화가 되어 있는데 DDL을 다시 재실행해서 테이블을 생성하려고 하니 오류가 발생한 것이다. 왜 이런 상황이 발생하는 것일까? 엄청 많이 파봤지만, 문제가 발생하는 정확한 원인을 찾지 못해서 깊게 파보면서 대충 예상해본 원인을 말해보겠다! (그래서 틀릴 수도 있다 ㅠㅠ) 🎯 @SpringBootTest의 ApplicationContext 생성 스프링에서는 @SpringBootTest을 실행하면 ApplicationContext를 생성해서 모든 스프링 빈들을 등록한다. 이때, 모든 테스트를 돌릴 때 @SpringBootTest를 실행할 때마다 Applicati..