2023.05.08 ~ 2023.06.01
전체 사이클을 경험할 수 있는 프로젝트를 진행 중입니다.
배운점, 깨달은 점
pull request
그동안 혼자서 토이프로젝트는 github에 initial commit, push는 해봤지만 협업하기 위해 제대로 사용해본 적이 없었다.
프로젝트 1회차부터 부족한 점이 드러나는구나
그럼 pull request란 무엇인가?
의미
내가 작업한 코드가 있으니 나의 브랜치를 당겨서(pull) 검토 후 병합(merge) 해주세요(request).
merge는 나중에 더 알아보겠지만 의미 그대로 받아들여도 문제없어 보인다. 기존의 코드에 다른 브랜치에서 수정된 코드를 병합하는 것 같다.
언제 쓰이나
아직 경험해보진 못했지만, 다른 사람들의 글을 읽어보면 코드 리뷰를 자연스럽게 할 수 있다고 한다. 또한 의미에서 유추할 수 있겠지만 오픈 소스 컨트리뷰션할 때 기본이 되는 것 같다.
내 경험
처음 접했을 때는 글로만 개념을 파악하려고 하니 좀 어려워 보였다. 하지만 직접 해보면 그렇게 어려운 것 같진 않고 왜 코드 리뷰를 이걸로 하나 이해가 갔다. 보통의 경우는 fork, clone부터 시작하지만 나의 경우는 조금 달랐다. 가입한 조직내에서 reopsitory를 생성하고 내가 branch를 만들어 내 repository에 pull request를 시작하는 것이다.
$git init
$git clone (복사한 url)
$git add .
$git commit -m ""
$git push
여기까지는 평소에 자주해봤던 과정이라 넘어가고
$git checkout -b 브랜치이름
브랜치 이름을 새로 만들고 그 브랜치로 이동할 수 있는 명령어다.
참고로
$git branch
위 명령어를 통해 현재 branch목록과 내가 어디 있는지 확인할 수 있다.
그리고 나서 아무거나 수정하고 똑같이 (add,) commit, push를 진행하면 된다.
pull request를 누르고 comment, reply를 통해 동료와 소통할 수 있다. 내가 commit한 내용에서 동료가 코드 부분을 선택해 comment를 할 수 있는 편리한 기능들이 있다. 이 부분은 그냥 직접 해보는게 글을 읽는 것보다 와닿았다.
메소드 이름을 이용한 Spring data jpa
게시판 데이터를 관리하는 프로젝트에서 모든 게시판의 정보를 넘겨줄 때 다음과 같은 제한 사항을 추가했다.
- 최대 100개까지만 불러오기
- 생성시간을 기준으로 최근순으로 불러오기
findTop100AllOrderByCreatedDateDesc()
처음에 내가 적용한 repository interface 속 메서드 이름은 위와 같았다. CreatedDate는 생성 시간을 저장하는 필드명이다. 무엇이 잘못됐는 지 잘 몰랐지만 친절한 우리의 인텔리제이가 뿌려준 오류 내용은
No property 'desc' found for type 'LocalDateTime'; Traversed path: Board.createdDate
LocalDateTime 타입에는 'desc'란 프로퍼티가 없다.
별로 안친절한가? 아무튼 메서드에서 find...By 형식이 적용된다는 사실을 깨닫게 되면 문제를 해결할 수 있다.
우선 Top숫자를 통해 SQL 쿼리의 숫자가 limit으로 들어간다.
그리고 나서 find와 By사이에는 뭐가 들어와도 상관이 없기 때문에 무시된다. 그리고 By뒤의 필드를 통해 WHERE절이 들어간다.
그래서 문제가 무엇이냐. 내가 원했던 OrderBy를 인식하는 것이 아니라 By를 먼저 인식했기 때문에 문제가 생긴 것이다. 따라서 위 메서드명을 아래와 같이 바꾼다면 정상적으로 동작한다.
findTop100ByOrderByCreatedDateDesc()
어려웠던 점, 반성하고 싶은 점
1. form을 따로 만들까?
아직 검증의 내용이 들어가지 않았고 request나 response할 때 data 정의가 달라지지 않았기에 따로 추가하지는 않았다. 하지만 가까운 미래를 위해서 따로 구분해야할까? 고민이 많았다. 코드를 작성하는 시간보다 이런 기초적인 설계 부분에 대한 고민 시간이 압도적으로 많았다. 경험이 부족한 단점이 이 기회에 확실히 드러나는 것 같다.
2. 응답을 ResponseEntity를 사용할까?
3. 검색기능에서 url경로에 리소스 search 추가할까?
요구사항 밑에 REST API 규칙 중 이것만은 지켜보자!를 나중에야 봤습니다 ㅎㅎ..
모든 게시판을 요구하는 url에 default값을 설정한 쿼리 파라미터를 넣어야 하나, url경로를 따로 만들어야하나 고민을 조금 했습니다. 글을 읽어보고 url경로를 따로 만들기로 결정했습니다.
boardSearch라는 DTO를 추가해야하나?가 새로운 고민으로 떠올랐고 아직 고민중입니다.
4. 단위 테스트
지금까지 무지성으로 @SpringBootTest를 통해 모든 빈을 사용하면서 단위 테스트에 대한 생각을 소홀히 했다. 지금까지 찾아본 결과로는 통합테스트는 시간이 오래걸리고, 무겁고, 의존성으로 인해 간단히 테스트를 진행할 수 없다.
지금까지 기록한 내용 외에도 상당히 많은 시행착오를 겪으며 단위 테스트를 단시간에 파악하기에 어려움이 많아 아직 해결하지 못한 문제다.
Controller, 즉 presentation layer에서 단위테스트는 어떻게 하는가?
- @WebMvcTest를 사용?
- @ExtendWith, @InjectMocks 등 MockMvc를 직접 생성하는 방법?
다른 블로그에서도 이 두 가지 방법으로 의견이 많이 갈리는 것 같다. 더군다나 사용되는 문법들에 대한 이해가 부족한 현재로선 단위 테스트를 작성할 수 없었다. 시간을 두고 차근차근 알아보고자 한다.
