Skip to content

01. Develop Convention

Jump to bottom
E1psycongr00 edited this page May 6, 2022 · 12 revisions

Flow Rule

  • fork 없이 공통 저장소 사용

  • 하나의 issue 발행하고 develop 에서 분기한 브랜치 만들어서 pr 하기

  • pr에 대해 반드시 merge 승인 리뷰 1개 이상 받을 것

  • 자신의 pr은 자신이 merge 하기

  • 되도록 1issue-1PR, PR에 커밋 수 제한 X, 리뷰하기 좋은 단위로


Git Convention

Git flow 브랜치 전략 기반

  • master: 현재 서비스 버전 (서비스로써 동작할 수 있는 최소한의 필수적인 것들을 갖춘 상태여야 함)

  • develop: 다음 master 버전을 위해 개발하는 브랜치로 상시 유지합니다

  • feature: 기능 개발 브랜치 (develop 에 합침)

  • (option)release: 이번 출시 버전을 준비하는 브랜치 (develop 에서 분기 후 master 에 병합)

  • (optional)hotfix: 이미 출시한 버전(마스터)에서 발생한 버그를 수정하는 브랜치


Branch Convention

같이 정해야 합니다.

<type>/<issue number>/<summary>

  • 예시: feat/#13/signup

<fe/be>/<type>/<issue number>/<summary>

  • 예시: be/feat/#15/member-register

Commit Convention

**소스 코드**

feat : 새로운 기능 추가
fix : 버그 픽스
refactor : 로직, 동작 변경 없기 구조적인 변경만 발생했을 경우(효율성 증가, 재사용성 증가 목적의)
style : 코드 의미에 영향을 주지 않는 변경사항 (포맷, 세미콜론 누락, 공백 등)

**코드 외적인 부분**

docs : 문서 수정 (ex: .md, .txt)
chore : 그 외 자잘한 작업 (ex: yml, properties)
ci : CI/CD (ex: travisCI, github-actions 등)
build : 시스템 또는 외부 종속성에 영향을 미치는 변경사항(npm 같은거 말하는 듯)


test : 테스트 코드

커밋 제목

  • 50자 이하
  • 마침표 x, 개조식 구문으로 작업 내용을 대표할 수 있게끔 알아서 작성할 것

커밋 내용

  • 생략 가능

  • 부연설명, 커밋한 이유 작성

  • 어떻게 보다는 무엇을 왜 했는지 작성


PR Convention

같이 구체화 해야 합니다.

제목

  • [프론트/백] 제목 / [저자]

내용

  • 이슈번호 명시 resolves #이슈번호

  • 뭘 했나요?(작업 내용 기재, 최대한 구체적으로)

  • 현재 작업을 통해 팀이 반드시 알아야 하는 사항은?

  • 질문/요청사항(자율)


댓글

  • 리뷰어가 반드시 봤으면 하는 것은? / 중점적으로 리뷰해줬으면 하는 부분은?
    • 이거 긴가민가해요. 잘 모르겠어요
    • 이 부분 어떤가요? 중점적으로 봐주세요

Merge Rule

예시

  • feature -> develop : squash merge

  • develop -> master : rebase merge


Review Rule

PR 저자

  • 의미있는 커밋 단위와 제목/메시지로 리뷰어의 원활한 리뷰를 돕는다.

  • 리뷰를 원하는 시점에 리뷰 요청을 한다.

  • 리뷰어가 상세하게 봐줬으면 하는 부분을 반드시 pull request에 명시한다.

  • 개선 / 수정에 대해 리뷰를 받고 반영한 후 반영 여부를 반드시 알려준다.

  • 자기 분야 개발자(백/프론트) 모두의 Approve 가 있을 경우 발행자가 pull request 를 merge 한다.

    • 또는 개발자들을 위한 한 명의 리뷰어를 고정으로 둔다던가, 3명이라면 각자의 담당일진 리뷰어를 두는 것도 좋아보임

리뷰어

  • 리뷰 요청을 받고 가능하다면 즉시 리뷰한다. (되도록 1일내로, 짧은 작업단위면 더 빠르게)

  • 필수적으로 변경/수정 해야하는 사항이라면 왜 그런지 설명한다.

  • 보며 자신이 배운 부분, 잘한 부분은 칭찬한다.

  • 우리의 리뷰 우선순위는 프로젝트 이해 및 버그/오류 식별이다.

    • 해당 사항이 아니더라도 알아볼만한, 개선해볼만한 점에 대해 같이 공부할 수 있도록 자유롭게 리뷰한다.

기타

  • 폭언, 욕설, 인격모독 금지

  • 스타일, 문법, 컨벤션 등 사소한 문제 이외에 사유 or 사실 or 사상 없는 리팩터링, 변경 요청 금지

  • 1인 이상의 리뷰 approval 이 있어야 merge 승인토록 설정


Code Convention

같이 정해야 합니다.

  • EX) Google Java Style Guide

  • pull request 리뷰 전 sonarlint 같은 코드분석 플러그인 도입해서 컨벤션 검사 하는 것도 고려해볼만 함

if 문 : if (x == 1) { 코드 한줄 }

dto =>풀네임

  • request
  • response

test

  • 카멜 표기법
  • displayName
  • 클래스 마지막 'Test'

class 형식

class helloTest {
   
    private String hello;
    private String world;

    void s() {
    }
}

메서드 간 띄어쓰기 1줄

코드 중간에 주석 작성시 1줄 띄어쓰기


최소한의 Clean Code Rule

예시입니다.

  • 하나의 메소드에서 깊이 2 이하만을 허용 (함수 하나에 많은 역할을 부여하지 말란 의미임)

  • 축약형 변수명, 메소드명 금지


Clone this wiki locally