Skip to content

03. 개발 가이드

Choi Hyung Joong edited this page Feb 28, 2022 · 1 revision

프로젝트 룰

패키지

  • 전체적으로 패키지는 web이 domain을 의존하는 구조를 유지할 것.
  • me.project.web.도메인명.*
  • me.project.domain.도메인명.*

domain & web

  • 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

커밋 메세지

출처 : 좋은 git 커밋 메시지를 작성하기 위한 7가지 약속

  1. 제목과 본문을 한 줄 띄워 분리.
  2. 제목은 50자 이내로.
  3. 제목 첫글자를 대문자(영어기준).
  4. 제목 끝에 . 금지.
  5. 제목은 명령문으로 사용, 과거형은 사용하지 않는다.
  6. 본문은 영문 기준 72자마다 줄 바꾸기.
  7. 본문은 어떻게 보다 무엇을, 에 맞춰 작성하기.

커밋 메세지 제목 작성 가이드

출처 : Git Commit Message StyleGuide

"태그: 제목"의 형태이고, : 뒤에 공백이 있음에 유의한다.

태그 이름 설명
Feat 새로운 기능을 추가할 경우
Fix 버그를 고친 경우
!HOTFIX 급하게 치명적인 버그를 고쳐야하는 경우
Refactor 프로덕션 코드 리팩토링
Comment 필요한 주석 추가 및 변경
Docs 문서를 수정한 경우
Test 테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X)
Chore 빌드 task 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X)
Rename 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Remove 파일을 삭제하는 작업만 수행한 경우

깃 플로우

gitflow

깃 플로우를 활용하는 이유

애플리케이션을 배포하기에 앞서 필요한 작업들을 병렬로 처리하여 협업의 효율성을 높이고 수정과 테스트, 재배포와 같이 순환하는 애플리케이션 개발 주기에 적절한 깃헙 워크플로우 전략이라 판단했다.

깃 플로우 branch 종류

  • 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 패턴 디자인 가이드

KEY POINT

  • API URI의 핵심은 리소스 식별이다.
  • 무언가를 생성하고 수정, 삭제하는 것은 행위.
  • 적절한 리소스 식별자(URI)와 적절한 행위(method)만으로도 기능을 추측할 수 있는 http api가 될 수 있다.

BAD CASE

GET /find-item/5 -> 5번 아이템을 조회
POST /create-item -> 아이템 등록

GOOD CASE

GET /items/5
POST /items

HTTP api Error handling

KEY POINT

  • 에러코드 자체는 포괄적으로 사용하되, 메세지는 에러의 원인을 파악할 수 있는 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

Clone this wiki locally