Skip to content

Latest commit

 

History

History
273 lines (191 loc) · 6.96 KB

컨벤션.md

File metadata and controls

273 lines (191 loc) · 6.96 KB

1. 백엔드

기본적으로 네이버 컨벤션을 따르고 추가적으로 필요한 컨벤션을 정리하였습니다.

1.1. Naver VS Google

1.1.1. Tap Space

Naver

4.2. 탭의 크기는 4개의 스페이스

[4-spaces-tab]

1개의 탭의 크기는 스페이스 4개와 같도록 에디터에서 설정한다.

Google

4.2 Block indentation: +2 spaces

Each time a new block or block-like construct is opened, the indent increases by two spaces. When the block ends, the indent returns to the previous indent level. The indent level applies to both code and comments throughout the block. (See the example in Section 4.1.2, Nonempty blocks: K & R Style.)

Naver은 1탭을 사용하여 4개의 스페이스를 두며 Google은 2개의 스페이스를 둡니다.

public class Naver {
    private int i;
}

public class Google {
  private int i;
}

1.1.2. Line length

Naver

6.1. 최대 줄 너비는 120

[line-length-120]

최대 줄 사용 너비는 120자까지 가능하다.

Google

Column limit: 100

Java code has a column limit of 100 characters. A "character" means any Unicode code point. Except as noted below, any line that would exceed this limit must be line-wrapped, as explained in Section 4.5, Line-wrapping.

1.2. 어노테이션

어노테이션은 A-Z 순으로 정렬하며 클래스의 위에는 해당 클래스에서 중요한 어노테이션을 작성합니다.

Good

@RequiredArgsConstructor
@Transactional(readOnly = true)
@Service
public class FooService {

}

Bad

// Bad 어노테이션 정렬이 안됨
@Transactional(readOnly = true)
@RequiredArgsConstructor
@Service
public class FooService {
	// ...
}

// Bad `@Service` 메인 어노테이션의 위치 부적절
@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class FooService {
	// ...
}

1.3. 결론

네이버 문서가 한글화 되어 있어서 기능에 대한 해석을 원활히 할 수 있고 라인의 길이와 탭의 길이가 구글보다 더 넓기 때문에 가독성이 좋을 것 이라고 판단하여 선택하였습니다.

2. 프론트엔드

✅에어비엔비 스타일 가이드

대표적인 스타일 가이드로는 Airbnb, Google, Naver 등 에서 제공하는 코딩 컨벤션이 있습니다. 이 중에서 우리 프로젝트는 Airbnb 스타일 가이드를 따릅니다.

❓에어비엔비 선택 이유:

  • 다른 컨벤션에 비해서 Airbnb 스타일이 가이드가 상세하고 규칙이 세부적임.
  • 커뮤니티에서 가장 널리 쓰이는 코드 컨벤션임.
  • ESLint와 같은 도구를 이용하여 Airbnb 스타일 가이드를 프로젝트에 쉽게 적용할 수 있음.
  • 지속적으로 업데이트 되고, 자바스크립트 언어와 생태계의 변화를 반영함.

💥Airbnb vs Google

  1. 긴 문자열의 사용
// Google
// 문자열이 길어 질 경우 '+' 연산자를 사용함. 
const errorMessage = 'This is a super long error that was thrown because ' +
      'of Batman. When you stop to think about how Batman had anything to do' +
      'with this, you would get nowhere fast.';
  
// Airbnb
const errorMessage = 'This is a super long error that was thrown because of Batman. When you stop to think  about how Batman had anything to do with this, you would get nowhere fast.';

Airbnb 스타일 가이드에 경우, 나뉜 문자열은 코드 검색을 어렵게 한다는 이유를 명시했다.

  1. Template String
// Google
function arthmetic(a, b) {
  return `Here is a table of arithmetic operations: 
$(a) + $(b) = $(a + b)
$(a) - $(b) = $(a  b)
$(a) * $(b) = $(a * b)
$(a) / $(b) = $(a / b)`;
}
    
// Airbnb
// Bad - 템플릿 문자열의 간격의 사용을 없애는 것으로 강제한다. (ESLint 에서 default로 적용)
function sayHi(name) {
  return `How are you, ${ name }?`;
}
    
// Good
function sayHi(name) {
  return `How are you, ${name}?`;
}
  1. Escape, 불필요한 이스케이프의 사용을 허용하지 않는다. (ESLint) - 이 가이드는 Airbnb에만 명시되어 있다.
//Airbnb
// bad
const foo = '\\'this\\' \\i\\s \\"quoted\\"';
    
// good
const foo = '\\'this\\' is "quoted"';
const foo = `my name is '${name}'`;

Template String의 경우 Google은 프로그래밍 방식의 문자열만 예시를 보여주고 있다. 반면, Airbnb의 경우 문자열 내에 작은 따옴표가 있는 경우나 이스케이프()가 필요한 경우도 예시를 보여준다.

3. Jira

3.1. 에픽

기능별로 작성

3.2. 스토리, 작업, 버그

3.2.1. 💭 스토리

  • 회의(스크럼 제외)

3.2.2. 🛠️ 작업

🔔 @SEIKIM : “산출물이 나오는 것들을 작업이라고하자”
  1. 문서화 😎
    1. ERD
    2. PPT
    3. WireFrame
    4. Figma
  2. 개발 👿

3.2.3. 🐛 버그

  1. 빌드 실패
  2. 머지 블락

3.2.4. “하위 이슈는 버그로 인해 사용하지 않는다.”

3.3. 제목 컨벤션

  1. 이슈의 이름이 대표하므로 중복하여 적지 않는다.

    **Good**
아이디어

**Bad**
[회의] 아이디어

  2. 대표자의 이름을 중복하여 적지 않는다. 왜냐하면 지라에서 대표자를 선택할 수 있다.

    **Good**
아이디어

**Bad**
[김정욱] 아이디어

  3. 날짜가 필요하다면 작성해도 괜찮다.(동일한 대표자와 제목인 경우에만) 단, 하루만 넣어야 한다.

    **Good
[2024.02.27]** 아이디어

**Bad**
[2024.02.27-28] 아이디어

  4. 스토리포인트는 최대 8시간을 넘기지 않는다.

    **Good**
아이디어 - 8

**Bad**
아이디어 - 16

4. Git

Feat: 생성기능내용(#이슈번호)

Fix:

Chore:

Design:

Docs:

4.1. Git 전략 - GitFlow

  • main : 기준이 되는 branch로 제품을 배포하는 branch이다.
  • develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합(Merge)친다.
  • feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop branch에 합친다.
  • hotfix : main branch로 배포를 했는데 버그가 생겼을 때 긴급 수정하는 branch이다. 총 4개의 브랜치를 사용한다.

https://t1.daumcdn.net/cfile/tistory/99CD994C5E69CCF223

5. GitLab + Jira

  1. Jira 에서 이슈 작성 ( 할 일 )
  2. Jira를 활용하여 Git Branch 생성
  3. 커밋 메시지 키워드: 내용 ( Jira 이슈 번호 )
  4. GitLab PR 작성 제목 ( Jira 이슈 번호 )
  5. 코드 리뷰 요청
    1. 승인은 리뷰어
    2. 머지는 본인