Convention
- Page Info
- page
- size
- total elements
- 패키지 구조 확인
- 도메인 별로 분리
- exception 처리용 패키지
- validation 처리용 패키지 (utils?)
- jwt
- configuration
- Method 네이밍
- find → get → show
- create
- update
- delete
- 변수명
- 예외 처리
- global exception handler
- error code
- custom exception
- Validation 처리 방법
- utils에서 null처리 함수
- 각 엔티티 별 레코드 존재여부 확인 함수ㄱ ㅏ필요할듯? 얘네는 못묶나?
- 서비스 레이어에서의 validation이 필요할지… dto와 entity로 충분하지 않을지
- dto 변환 위치
- 서비스에서…
- 컨트롤러에서 처리하는 것에 비해 파라미터가 현저히 적어짐
- 홍구님 왈) 엔티티가 한 레이어를 벗어나지 않도록 관리해라 → 서비스 레이어 밖으로 벗어나지 않게 할 수 있음
- dto 에는..?
- 개인적으로 생성자 파라미터로 entity를 받아서 dto를 만드는 것을 선호함
- 큰 이유는 없고 간단해서?
- dto 내부에 toEntity 로직을 만드는 것은 추천받지 않음
- 캡스톤 디자인 멘토님께서 entity 관련된 것은 entity class에서 처리하는 것이 좋다고 함. 이펙티브 자바에 나오는 내용인듯
- test 방법
- service
- 메소드 별 성공 테스트 1개, 실패 테스트 N개?
- controller
- 출력 값 보다도 상태코드, 에러 여부에 집중해서
- 출력 값은 사실 서비스 테스트에서 증명이 돼야 정상임
- 의존성
- maven vs gradle
- 그래도 maven 배웠는데 maven 써보는 것도 괜찮을 듯
- 필요한 라이브러리 확인
- Java 17 v
- Spring boot 2.6.8, Spring Data JPA, Spring WEB,
- Junit5, mockito, Rest
- MySQL, H2. Redis
- api 명세(Swagger, Restdocs)
- Docker, WAS(Tomcat, Undertow)
- Must Have API 분담
- Domain까지 분담
- 개발하면서 차차 분석해 나가기로
- Github Policy
- Commit, Push 방식 (Hook 쓸건지)
- hook이 필요할까?
- 그냥 체크만 해주는 훅
- 코드 리뷰 방식 (로직 위주)
- test code로 기능 명세 후, 작성하면 로직 알아보기 편할 듯
- 하지 말자 의견
- 머지데이
- 스크럼 때 자기 코드 간략하게 짠 거 설명 + 이슈, 막힌 점 이야기 하기
- 브랜치 네이밍
- Github flow, git flow
- 깃 플로우 너무 어려워보이는데….