코드 컨벤션
레포 규칙
레포지토리 규칙깃 커밋 메시지
커밋메시지네이밍
- 테스트 메서드 네이밍
- CamelCase
- 인터페이스 구현체 네이밍
- xxxxService
Impl
- API 네이밍
- Api
- DTO 네이밍
- 기존에 inner class 로 작성할 때 존재했던 불편함 : import 가 자동완성되며 어떤 것은 Request.CreatePost, 어떤것은 CreatePost 로 사용하는 모습이 나타났음.
- Request
- {도메인}{Action}Request
- Response
- {도메인}{Action}Response
Request 패키지, Response 패키지를 분리하여, 각각의 DTO 클래스를 생성하도록 한다
- 변수
- var 금지 🥀🥀
- Converter 클래스 네이밍
- A(바꾸기 전) to B(바꾼 후)
예외처리
- 기본 : Business Exception
세부 : 세분화 된 Exception
ex - (EntityNotFound 같은)
Q. ErrorCode가 필요할까?
메시지랑 중복되지 않을까?
- 에러 응답 - 프론트와 논의후 결정
스프린트
- 1스프린트 - 7일
- 4번 스프린트가 일어나겠네여
- 스프린트 계획 잘 짜기!
브랜칭 전략
main ← develop/sprint-{no} ← feat/이슈번호-어쩌구
업무시간
- 10시에 출근해서 자율
- 스크럼 시간 프론트랑 정하기
- 일단 백앤드만 할 경우 2시 정도
- 주말에 어느정도 공부할지?
- 자율 // (인데 PR은 올라옴)
API 문서
- Swagger vs RestDocs → 통합
로깅전략
- AOP
- 최대한 필요하다고 생각되는부분만 로깅
- 핸들링 하는 예외들 에 대한 로그레벨은
- warn → BusinessException, BindException 등 예상한 예외들
- error → Exception 과 같은 예외들
- 예외의 기준은 우리의 기준을 정하고 이를 준수한다
협업툴
깃헙 프로젝트
테스트
- 한글 메서드 금지
- DisplayName은 ㄱㅊ
- 이슈단위로 Nested 해서 테스트하기?
테스트 커버리지 85~100%
디렉토리 구조
domain global config파일등...
문서화
- 사용 툴 :
Plant diagram,Sequence Diagram,ERD-cloud,Mermaid
- 백로그 양식
- DTO
- 시퀀스 다이어그램
- 유스케이스
- 유저스토리
각자 도메인 정해서 합치는 방식
중요 도메인 인터페이스 만들어서 세부사항 구현만 따로 하는 느낌으로 가면 좋겠다
롬복 사용범위
- 롬복 어디까지 사용할까용?
- @Noargsconstructor(access=protected)
- PROECTED 사용하자~~~
- @Builder
- 생성자에만 붙일 것 !!!! ( 클래스는절대안됩니당)
- @Getter
- 일단 @Getter 롬복 사용하지 않는 것으로
- @Slf4j
- 클래스에 대한 Logger 를 사용할 때
- @RequiredArgsContructor
- 사용한다!