2024년 7월 21일 TIL
TL;DR
- 과제 개발 진행 방식 변경함
- 브랜치 전략 짬
- 프로젝트 구조 선택함
- 테스트 써보기로함
한줄평
주말이라서 오랜만에 도파민 좀 충전했다.
계획 세우는 것도 중요하지만 빨리 코드를 좀 써야하는데 여의치 않게 상황이랑 체력상 그게 안되는 중
과제 개발 진행 순서 변경
기존 개발순서
- 엔티티 생성
- 리스폰스 DTO 개발
- 리포지토리 개발
- 서비스(비즈니스 로직) 개발
- 컨트롤러 개발
- 유효성 검사 개발
에서
개발 순서를 GPT 컨설팅 받아서 엔티티 → 레포지토리 → DTO → 서비스 → 컨트롤러 순으로 변경
과제 브랜치 전략 다시 짬
기존엔 도메인 별로 브랜치를 짜서 과제 진행 할려고 했는데
- 브랜치 수명 길어져서 컨플릭트 생길 확률 높음
- 코드리뷰 시 코드 양이 늘어 리뷰자가 불편할 수 있다는 점
때문에 기능당 브랜치를 생성하는 걸로 전략을 바꿈.
다만 이 방법은 브랜치 관리가 복잡해지고 브랜치 구조 파악이 어렵다는 단점도 발견함
그래서 파악하기 쉽게 브랜치 이름은 DEV/<도메인>-<기능명> 이렇게 짜기로함
과제 프로젝트 구조 선택함
Entity, Controller, Service, Repository 같은 역할로 패키지를 나눈 계층형 구조와 (예)coupon, member, order처럼 도메인 별로 패키지를 구성한 도메인형 구조의 두가지 구조를 알아봤고 최종적으로
- 과제 규모가 크지 않아 클래스들이 구분이 힘들정도로 많지 않음
- 결합도가 어느 정도 있음
의 이유로 계층형 구조를 사용하기로함.
참고한 레퍼런스
테스트 써보기로함
프론트했었을 땐 존재여부만 알고 쓰진 않았던 테스트를 이번 과제에서 써보기로 했다.
백엔드 개발에서 테스트는 꽤나 중요한 부분이라는걸 파악해서 이번 프로젝트에서 써보기로 했다.
물론 바로 도입하려고 하진 않았고 아래 이유로 고민을 했었다.
- 러닝커브
- 개발속도 저하
하지만 최종적으로 빠른 개발 보단 과제 수행을 통한 학습이 중요하다는 점, 통상적인 백엔드 개발에 필수적으로 테스트를 사용한다는 점에서 위 고려사항들이 있더라도 이번 과제에서 사용해보기로 하였다.