[번개 모임 프로젝트 회고] 프로젝트 구조 설정, Git을 통한 버전 관리

기본적인 프로젝트 폴더 구성

1. 프로젝트 구성

이번 프로젝트는 Spring boot를 사용하고 JPA를 적용했기 때문에 위와 같이 폴더를 구성해 보았다.

아래는 Notion 페이지를 통해 공유한 프로젝트 구조와 설명들을 작성한 내용이다.

• Controller
  • 해당 요청 url에 따라 적절한 view와 mapping을 처리한다.
  • @Autowired Service를 통해 service의 method를 이용한다. (사용자의 입력을 받고 서비스로 전달하는 역할)
  • 적절한 DTO를 담아서 Client에게 전달한다.
• Service
  • 비즈니스 로직을 수행 ( ex 중복 아이디가 있는지 없는지를 검사하기 위한 일련의 과정들)
    • 어떻게 데이터가 생성, 저장, 수정, 삭제, 조회 등 되는 지를 정의한 것
    • DAO로 DB에 접근하고 DTO로 데이터를 전달받은 다음, 비즈니스 로직을 처리해 적절한 데이터를 반환한다.
  • @Autowired Repository를 통해 repository의 method를 이용한다. (Hibernate JPA를 사용하는 경우)
• Repository(DAO)
  • 실제로 DB에 접근하는 객체
  • Service와 DB를 연결하는 고리의 역할을 한다.
• DTO
  • 계층 간 데이터 교환을 위한 객체(Java Beans)
    • DB에서 데이터를 얻어 Service나 Controller 등으로 보낼 때 사용하는 객체
    • 로직을 갖고 있지 않은 순수한 데이터 객체, getter/setter 메서드만을 갖는다.
    • 하지만, DB에서 꺼낸 값을 임의로 변경할 필요가 없기 때문에 DTO클래스에는 setter가 없다. (대신, 생성자에서 값을 할당한다.)
• Domain(Entity) ⇒ 실제 DB의 테이블과 매칭될 클래스
  • @Entity, @Column, @Id 등을 이용한다.
• Entity 클래스와 DTO 클래스를 분리하는 이유
  • View Layer와 DB Layer의 역할을 분리하기 위해서 사용
  • 테이블과 매핑되는 Entity 클래스가 변경되면 여러 클래스에 영향을 준다.
  • View와 통신하는 DTO 클래스(Request, Response 클래스)는 자주 변경되므로 분리해야 한다.
• resources
  

  폴더 및 파일	설명
  templates	해당 디렉터리에는 타임리프 관련 파일이 위치하게 되고, 타임리프는 HTML5 기반이기 때문에 HTML 파일로 화면을 구성한다.
  static	해당 폴더에는 css, fonts, images, plugin, scripts 등의 정적 리소스 파일이 위치한다.
  application.properties	해당 파일은 웹 애플리케이션을 실행하면서 자동으로 로딩되는 파일이다. 톰캣의 포트 번호, 콘텍스트 패스(Context Path) 설정이나, 데이터베이스 관련 정보 등 애플리케이션에서 사용하는 여러 가지 설정을 해당 파일에 Key - Value 형식으로 선언해서 사용할 수 있다.

2. Git 규칙

버전 관리는 Git을 사용해서 진행했다. Git branch 전략을 수립하고 커밋할 때 커밋 컨벤션을 정해 따르도록 하였다.

Git branch 전략은 많이 사용되는 Git Flow를 간소화해서 사용해 보았다.

일반적인 Git Flow 전략은 위와 같이 main, release, develop, feature, hotfix로 나뉘어 사용된다.

• main : 실제 배포되는 버전의 브랜치
• develop : 새로운 기능을 개발/테스트하는 브랜치
• feature : 특정 기능을 개발하는 브랜치
• release : 해당 버전의 출시를 위한 브랜치
• hotfix : 운영 중 생긴 버그를 수정하기 위한 브랜치

실제 개발에서는 main 브랜치와 develop 브랜치를 사용하고 팀원들 각자 맡은 기능을 나누어 놨기 때문에 feature 브랜치를 사용하지 않고 본인의 이름으로 브랜치를 생성하여 코드를 작성하고 일주일에 2번 develop에 Pull Request 하고 같이 코드를 보면서 리뷰하고 테스트하고 모든 테스트가 끝나면 최종 결과물을 main 브랜치에 병합하는 식으로 진행했다.

 

깃 커밋 컨벤션도 아래와 같이 설정하였다.

1. Commit 메시지 구조

기본 적인 커밋 메시지 구조는 type, body, footer 세 가지 파트로 나누고, 각 파트는 빈 줄로 구분

type : subject

body

footer

2. Commit Type

type은 태그와 제목으로 구성되고, 태그는 영어로 첫 문자는 대문자로 한다.

태그: 제목의 형태(: 뒤에만 space가 있음)

• feat: 새로운 기능 추가
• fix: 버그 수정
• docs: 문서 수정
• style: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
• refactor: 코드 리펙토링
• test: 테스트 코드, 리펙토링 테스트 코드 추가
• chore: 빌드 업무 수정, 패키지 매니저 수정

3. Subject

• 제목은 최대 50글자가 넘지 않도록 하고 마침표 및 특수기호는 사용하지 않는다.
• 영문으로 표기하는 경우 동사(원형)를 가장 앞에 두고 첫 글자는 대문자로 표기한다.(과거 시제를 사용 x)
• 제목은 개조식 구문으로 작성한다. --> 완전한 서술형 문장이 아니라, 간결하고 요점적인 서술을 의미

* Fixed --> Fix
* Added --> Add
* Modified --> Modify

4. Body

본문은 다음의 규칙을 지킨다.

• 본문은 한 줄 당 72자 내로 작성한다.
• 본문 내용은 양에 구애받지 않고 최대한 상세히 작성한다.
• 본문 내용은 어떻게 변경했는지 보다 무엇을 변경했는지 또는 왜 변경했는지를 설명한다.

5. footer

꼬리말은 다음의 규칙을 지킨다.

• 꼬리말은 optional이고 이슈 트래커 ID를 작성한다.
• 꼬리말은 "유형: #이슈 번호" 형식으로 사용한다.
• 여러 개의 이슈 번호를 적을 때는 쉼표(,)로 구분한다.
• 이슈 트래커 유형은 다음 중 하나를 사용한다.
  • Fixes: 이슈 수정 중 (아직 해결되지 않은 경우)
  • Resolves: 이슈를 해결했을 때 사용
  • Ref: 참고할 이슈가 있을 때 사용 Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
    • ex) Fixes: #45 Related to: #34, #23

6. Commit 예시

Feat: 회원 가입 기능 구현

SMS, 이메일 중복확인 API 개발

Resolves: #123
Ref: #456
Related to: #48, #45

결론

프로젝트 구조를 미리 설정하고 공유해서 팀원 모두가 통일성 있게 코드를 작성할 수 있었던 점은 좋았다.

Git Flow를 간소화 한 건 Git Flow의 장점을 잘 활용하지 못한 방법이었던 것 같다. 사실 Git Flow와는 멀리 떨어진 무언가가 된듯하다.

그리고 개인이 아닌 기능별로 브랜치를 나누는 게 맞지 않았나 싶다. 각자 맡은 부분이 나누어져 있다지만 같은 코드를 건드리게 되고, feature 브랜치에서 해결하고 넘어와야 할 일을 develop에서 하게 된 느낌.

지속적으로 운영되고 있는 웹 사이트에 적용한다면 hotfix나 release 브랜치도 사용해서 100% 활용될 수 있을 것 같다.