프로젝트 문화 - f-lab-edu/sool-dam-a Wiki

프로젝트 문화

Coding convention

  • google java convention을 사용합니다.

Git commit message convention

  • 다음 형식으로 커밋 메시지를 작성합니다.
<type>: <제목>

<본문>
  • type만 영문으로, 이외 내용은 한글로 작성합니다.
  • type
    • 첫 글자는 대문자로 씁니다.
    • type 종류와 각각의 쓰임은 다음과 같습니다.
태그 이름 설명
Feat 새로운 기능을 추가할 경우
Fix 버그를 고친 경우
!HOTFIX 급하게 치명적인 버그를 고쳐야 하는 경우
Style 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Refactor 프로덕션 코드 리팩토링
Comment 필요한 주석 추가 및 변경
Docs 문서를 수정한 경우
Test 테스트 추가, 테스트 리팩토링 (프로덕션 코드 변경 X)
Rename 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Remove 파일을 삭제하는 작업만 수행한 경우

type 종류 및 쓰임은 이곳 을 참고했고, 이 중 필요한 것만 추려냈습니다.

  • 제목
    • 영문 기준 50자 이내로 작성합니다.
    • 제목 끝에 . 문자를 쓰지 않습니다.
    • 제목에 동사는 (필요할 경우) 자유롭게 넣거나 뺄 수 있습니다.
  • 본문
    • 영문 기준 72자마다 줄을 바꿉니다.
    • 어떻게 보다 무엇을, 왜에 맞춰 작성합니다.

Git pull request template

  • Pull request(이하 PR) 템플릿을 적용해 PR마다 일관된 내용을 자동으로 만듭니다. 이를 통해 이전에 작성한 PR description을 확인하거나 템플릿을 매번 만들지 않도록 해 생산성을 높이려고 합니다.
  • 템플릿에 어떤 내용을 넣을지 논의하면서 다음 두 자료를 참고했습니다. 리멤버 팀에서 쓰는 PR 템플릿뱅크샐러드 팀에서 쓰는 pn 룰 을 참고해 우리가 필요한 부분을 추렸습니다.
  • 정한 PR 템플릿 내용은 다음과 같습니다.
  • 작업 내용 : 작업한 내용에 대해서 나열합니다. 어떤 기능을 개발했는지, 리팩토링한 내용 등을 리뷰하는 사람이 인지하기 쉽게 작성합니다.
  • 링크 : 리뷰하기 위해 필요한 링크들을 작성합니다.
  • 기타 사항 : 개발하면서 고민됐던 부분들에 대해서 작성합니다.
  • Merge 전 필요 작업 : 머지 및 배포하기 전에 선행되어야 할 부분을 잊지 않고 리마인드하기 위한 체크리스트입니다.
  • pn 룰 : P1~P5로 리뷰어가 코멘트를 강조하고 싶은 정도를 표현합니다. 이것은 PR 요청자가 아니라 리뷰어가 작성할 내용이지만, PR 템플릿에 있으면 PR 리뷰를 하면서 참고하기에 용이할 것으로 생각해 템플릿에 추가했습니다.

디렉토리 구조

  • 프로젝트를 진행하면서 작성한 클래스를 적절한 디렉토리에 모아두게 됩니다. 디렉토리 구조는 어떤 방식으로 디렉토리를 구성할지 말합니다.
  • 이 프로젝트는 도메인형 디렉토리 구조를 사용합니다.
  • 결정하는 과정에서 여기를 참고해서 계층형 디렉토리 구조와 도메인형 디렉토리 구조를 놓고 고민했습니다.
  • 계층형 디렉토리 구조에서는 controller, service 등의 계층으로 디렉토리를 나누고, 디렉토리마다 해당되는 클래스를 집어넣습니다. 도메인형 디렉토리 구조에서는 프로젝트 도메인을 기준으로 디렉토리를 나눕니다. 예를 들어 e-commerce 도메인이라면 order, member 등을 상위 디렉토리로 하고 각각의 아래에 controller, service 디렉토리를 두고 order에서 쓰는 controller 클래스는 order/controller 안에, member에서 쓰는 controller 클래스는 member/controller 안에 넣는 방식입니다.

객체지향 생활 체조

  • 객체지향 생활 체조는 소트웍스 엔솔로지라는 책 6장의 제목이자 제프 베이가 제시하는 코드 작성 훈련 방법입니다. 제프 베이는 코드를 짤 때 객체지향 생활 체조를 생활화함으로써 좋은 객체지향적 설계 원칙을 따르는 코드를 짜는 버릇을 들일 수 있다고 이야기합니다.
  • 술담아 프로젝트에서 우리는 객체지향 생활 체조 규칙 아홉 개 중 프로젝트 문화에 크게 도전적이지 않은 난이도로 적용할 수 있는 몇 가지를 골라 지키려고 합니다.
  • 우리가 지키기로 정한 규칙은 1, 5, 6번입니다. 각 규칙은 다음과 같습니다.
  • 규칙 1. 한 메서드에 오직 한 단계의 들여쓰기만 합니다.
  • 규칙 5. 이름을 줄여 쓰지 않습니다.
  • 규칙 6. 모든 entity를 200줄 이하로 작게 유지합니다. 책에서는 모든 entity를 50줄 이하로 유지하도록 제안하지만, 논의했을 때 서비스 로직 구현 시 50줄은 지키기 어려울 것으로 예상되어 200줄 이하로 기준을 조정했습니다.

PR 및 PR merge

  • PR과 이슈 연결: PR 제목 앞에 PR과 연관된 이슈 번호를 적습니다. 예를 들어 PR 제목이 Spring 기본 설정이고 이와 연관된 이슈 번호가 1번일 때, [#1] Spring 기본 설정과 같은 형식으로 적습니다.
  • PR merge 기준은 다음과 같습니다.
    • (당분간은) 멘토님의 Approve
    • (나중에는) 1 Approve
    • 리뷰 수정 요청이 없는 상태에서 3일이 지남

코드 리뷰

  • 다른 사람이 작성한 기능 리뷰를 꼼꼼하게 해서 내가 구현하지 않았더라도 다른 사람에게 설명할 수 있도록 합니다.
  • 코드 리뷰를 요청하는 사람은 자신이 구현한 내용을 다른 사람이 이해할 수 있게끔 이야기해줍니다.

이외

  • 프로젝트를 진행하다가 처음 등장하는 애노테이션이 있다면, 학습 목적으로 그 어노테이션이 하는 일을 주석으로 남깁니다.
  • 마찬가지로 build.gradle 파일 각 라인의 의미를 주석으로 남깁니다.
⚠️ **GitHub.com Fallback** ⚠️