프로젝트 문화

<type>: <제목>

<본문>

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

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

Pull request(이하 PR) 템플릿을 적용해 PR마다 일관된 내용을 자동으로 만듭니다. 이를 통해 이전에 작성한 PR description을 확인하거나 템플릿을 매번 만들지 않도록 해 생산성을 높이려고 합니다.
템플릿에 어떤 내용을 넣을지 논의하면서 리멤버 팀에서 쓰는 PR 템플릿 을 참고했고, 여기서 우리가 필요한 부분을 추렸습니다.
정한 PR 템플릿 내용은 다음과 같습니다.
작업 내용 : 작업한 내용에 대해서 나열합니다. 어떤 기능을 개발했는지, 리팩토링한 내용 등을 리뷰하는 사람이 인지하기 쉽게 작성합니다.
기타 사항 : 개발하면서 고민됐던 부분들에 대해서 작성합니다.
Merge 전 필요 작업 : 머지 및 배포하기 전에 선행되어야 할 부분을 잊지 않고 리마인드하기 위한 체크리스트입니다.
셀프 체크리스트 : 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 제목 앞에 PR과 연관된 이슈 번호를 적습니다. 예를 들어 PR 제목이 Spring 기본 설정이고 이와 연관된 이슈 번호가 1번일 때, [#1] Spring 기본 설정과 같은 형식으로 적습니다.
PR merge 기준은 다음과 같습니다.
- (당분간은) 멘토님의 Approve
- (나중에는) 1 Approve
- 리뷰 수정 요청이 없는 상태에서 3일이 지남

%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8 %EB%AC%B8%ED%99%94 - f-lab-edu/sool-dam-a GitHub Wiki