tech.md

개발 가이드

개발 가이드 문서입니다.

목차

• 목차
  • 의존성 제한
  • 코드 품질 제한
    • 일관성 있는 코드
    • 린트 도구
  • 협업 방법
    • 이슈 등록
      • 이슈 라벨
      • 이슈 네이밍
    • 신규 브랜치 생성
      • 브랜치 네이밍
    • 개발 중 커밋 컨벤션
    • 풀 리퀘스트
      • 풀 리퀘스트 네이밍
      • 풀 리퀘스트 라벨링
      • 테스트 전용
    • 메인 브랜치 반영 이후

의존성 제한

• api : 모든 모듈을 의존 가능합니다. 단, 우발적으로 application이 아닌 다른 모듈의 코드를 의존하는 것은 지양합니다.
• application : domain에게만 의존할 수 있습니다.
• domain : 다른 모듈을 의존할 수 없습니다.
• infrastructure : application, domain에게만 의존할 수 있습니다.

코드 품질 제한

일관성 있는 코드

• 코드 베이스 반영 전에 import 최적화를 수행합니다.
• 코드 베이스 반영 전에 불필요한 공백이 있는지 확인합니다.
• 테스트가 실패할 경우, 코드 베이스에 절대 반영하지 않습니다.
• 프로젝트 라인 커버리지 제한은 70% 이지만, 90% 이상을 목표로 합니다.
• 중요하지 않은 hotfix를 제외한 모든 유형의 코드 반영은 PR을 통해 이루어져야 합니다.
• 모든 develop 브랜치에 병합되는 PR은 협업자간에 코드 리뷰를 수행합니다.
  • 만약, 시간적인 제약으로 인해서 코드 리뷰를 받지 못하는 경우에는 PR에 run: gpt code review 라벨을 붙이고 ChatGPT에게 리뷰를 받습니다.

린트 도구

• 린트와 인텔리제이 코드 자동 정렬 설정을 협업자간에 동일하게 구성합니다.
• git commit 이전에 린트 검사를 수행합니다.
  • commit 이전에 자동으로 스타일 검사를 수행하기 위해서 다음 명령어로 Hook을 등록합니다.
  • ./gradlew addKtlintCheckGitPreCommitHook
• 린트로 인해 빌드가 안될 경우에 빌드 디렉터리에 들어가 원인을 파악하고 코드를 수정합니다.
  • 코드를 수정한 다음, ./gradlew ktlintCheck 를 수행해 린트 검사 결과를 최신화합니다.
  • 만약, 어떻게 코드를 수정해야하는지 모르겠다면, ./gradlew ktlintFormat 을 수행해 코드를 자동 수정할 수 있습니다.

협업 방법

이슈 등록

새로운 작업을 하기 이전에 깃헙 이슈를 등록합니다.

이슈 라벨

이슈에 등록 가능한 라벨의 유형은 다음과 같습니다. problem은 problem 이슈 템플릿을, 나머지는 task 이슈 템플릿을 사용합니다.

• new : 신규 개발
• enhancement : 리팩터링과 최적화를 비롯한 개선 작업
• chore : 설정을 비롯한 부수적인 작업
• problem : 문제 발생
• documentation : 문서화

이슈 네이밍

• 이슈의 이름 형식은 [type] title 입니다.

• 이슈의 이름 형식 타입은 PR에서 사용하는 제목의 타입과 동일합니다. 단, PR 제목 타입에는 배포가 추가됩니다.

  • 기능 구현 : new
  • 개선 : enhancement
  • 설정 : chore
  • 문서 : documenation
  • 문제 : problem

신규 브랜치 생성

현재 개인 환경에 있는 브랜치가 저장소에 있는 최신 코드인지 확인하고, develop 브랜치에서 신규 브랜치를 생성합니다.

브랜치 네이밍

• 브랜치의 이름 형식은 type/이슈 번호 입니다.

• 브랜치 이름의 타입은 다음과 같습니다. (앵귤러 JS 커밋 컨벤션의 타입을 따름)

  • feat : new
  • refactor : enhancement
  • chore : chore
  • fix : problem
  • docs : documentation
  • 기타 추가 가능

개발 중 커밋 컨벤션

개발 시 커밋 메시지는 앵귤러 JS 커밋 컨벤션을 따르되, type + subject까지만 작성해도 괜찮습니다.

풀 리퀘스트

풀 리퀘스트 네이밍

• 개발이 끝나면 develop 브랜치로 PR을 생성합니다.
• 풀 리퀘스트 이름 형식은 이슈 형식과 거의 동일합니다.
• 차이점은 PR 뒤에 () 내부에 연관 이슈를 추가하는 것입니다.
  • 예시 : [문서] 가이드 문서 작성(issue#58)
• 관련 이슈가 한 개가 아니라면 구분자를 콤마(,)를 이용해 나열합니다.
• (중요) main 브랜치에 반영되는 경우에는 [배포]를 접두어로 사용하고, deployment 혹은 no-deployment 라벨을 등록합니다.
• (중요) main 브랜치에 반영되는 경우에는 () 내부에 연관 PR을 추가합니다.
  • 예시 :
    • [배포] 메인 브랜치 반영(PR#23,PR#28) : 버전이 증가하지 않는 경우
    • [배포] v0.0.1(PR#12,PR#98) : 버전이 증가하는 경우

풀 리퀘스트 라벨링

• 현재 풀 리퀘스트의 라벨을 이용해서 자동으로 실행하는 github actions 작업이 존재합니다.
  • run: ci : 빌드, 테스트, 테스트 커버리지 분석, 린트, 정적 코드 분석 실행
  • run: gradle test : 빌드, 테스트, 테스트 커버리지 분석 실행
  • run: gpt code review : ChatGPT 코드 리뷰 실행
  • no-deployment : 컨테이너 이미지 저장소(docker hub)에 신규 이미지 릴리즈하지 않음

테스트 전용

• [테스트] 접두어를 사용하고, ignore 라벨을 등록합니다.
• 테스트 전용 PR은 코드 베이스에 반영하지 않습니다.

메인 브랜치 반영 이후

• 개인 개발 환경에서 머지 커밋을 포함한 최신 main 브랜치의 코드를 내려받습니다.
• 태그를 만들고, 태그를 저장소에 push 합니다.
• 해당 태그로 새로운 릴리즈 노트를 작성합니다.

⬆ 위로 올라가기