-
Notifications
You must be signed in to change notification settings - Fork 2
03. 개발 가이드
Choi Hyung Joong edited this page Feb 28, 2022
·
1 revision
- 전체적으로 패키지는 web이 domain을 의존하는 구조를 유지할 것.
me.project.web.도메인명.*me.project.domain.도메인명.*
-
me.project.domain: 비즈니스에 대한 공통 관심사에 대한 로직을 모듈화한 패키지.- ex. data collection: repository, business logic: service.
-
me.project.web: 원격 서버와 인터넷 서버간의 통신을 하는데 관여하는 로직을 모듈화한 패키지.- ex. http error handling, servlet filter, interceptor etc.
- entity(or DTO) -> repository -> service -> controller
- 제목과 본문을 한 줄 띄워 분리.
- 제목은 50자 이내로.
- 제목 첫글자를 대문자(영어기준).
- 제목 끝에
.금지. - 제목은 명령문으로 사용, 과거형은 사용하지 않는다.
- 본문은 영문 기준 72자마다 줄 바꾸기.
- 본문은
어떻게보다무엇을,왜에 맞춰 작성하기.
"태그: 제목"의 형태이고, : 뒤에 공백이 있음에 유의한다.
| 태그 이름 | 설명 |
|---|---|
| Feat | 새로운 기능을 추가할 경우 |
| Fix | 버그를 고친 경우 |
| !HOTFIX | 급하게 치명적인 버그를 고쳐야하는 경우 |
| Refactor | 프로덕션 코드 리팩토링 |
| Comment | 필요한 주석 추가 및 변경 |
| Docs | 문서를 수정한 경우 |
| Test | 테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X) |
| Chore | 빌드 task 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X) |
| Rename | 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우 |
| Remove | 파일을 삭제하는 작업만 수행한 경우 |

애플리케이션을 배포하기에 앞서 필요한 작업들을 병렬로 처리하여 협업의 효율성을 높이고 수정과 테스트, 재배포와 같이 순환하는 애플리케이션 개발 주기에 적절한 깃헙 워크플로우 전략이라 판단했다.
- main : 배포될 수 있는 브랜치
- develop : 다음 버전을 개발 중인 브랜치
- feature : 기능을 개발하는 브랜치
- release : 배포를 준비하는 브랜치
- hotfix : 배포 준비 중 발생한 버그를 수정하는 브랜치
main, develop은 거의 항상 유지되는 브랜치이고, feature, release, hotfix는 필요할 때만 유지되는 보조 브랜치이다.
- 중첩 클래스를 제외한 하나의 클래스에서 코드 시작/끝 부분에 한 칸씩 빈 줄을 삽입한다.
- 코드에 사용되지 않는 라이브러리는 삭제한다.
- 데이터 액세스 로직의 경우, 특정 프레임워크에 속하는 객체를 직접 DI 받아 사용하는 패턴을 금지하며, 꼭
respository로 캡슐화해서 사용할 것. - 클래스 멤버는 필드 - 생성자 - getter/setter 순서로 작성한다.
- getter 이외의 무의미한 setter는 지양한다.
-
setId(Long id) (x) updateItemInfo(Item item) (o)
-
- 서비스 클래스는 하나의 도메인을 기능별로 세분화해서 작성한다.(하나의 책임만을 갖게 하자)
- 무조건 짧고 명료한 코드보다 가독성을 고려하는 코드 작성을 지향한다.
- API URI의 핵심은 리소스 식별이다.
- 무언가를 생성하고 수정, 삭제하는 것은 행위.
- 적절한 리소스 식별자(URI)와 적절한 행위(method)만으로도 기능을 추측할 수 있는 http api가 될 수 있다.
GET /find-item/5 -> 5번 아이템을 조회
POST /create-item -> 아이템 등록
GET /items/5
POST /items
- 에러코드 자체는 포괄적으로 사용하되, 메세지는 에러의 원인을 파악할 수 있는 human readable한 내용을 포함한다.
- 빈 검증 과정에서 일어난 에러의 경우, 해당 필드명, 그 필드의 i18n 코드와, 메세지 내용을 포함해야 한다.
{
"exception":"ExceptionName",
"status":400,"error":"Bad Request",
"message":"Exception message",
"fieldErrors": {
"field" : "fieldName",
"code" : "messageSourceCode",
"message" : "messageSourceCode"
}
}이번 프로젝트의 경우 좀더 일관적인 포맷과 코드 스타일을 유지하기 위해, 라이브러리를 만들어서 배포하였다. https://search.maven.org/artifact/io.github.wannidev/simplehandlingexception/0.0.2/jar