[러닝하이] 컨벤션 및 프로젝트 관리

수박이삼촌·2024년 3월 29일

목록 보기

8/11

🎉 코드 컨벤션의 중요성

코드 컨벤션을 사전에 명확히 정의함으로써, 우리는 서로의 코드를 더욱 쉽게 이해할 수 있으며, 오해가 줄어들 것이라 생각합니다.

물론, 각자의 고유한 코드 스타일에서의 장점이 있을 수 있지만, 그것이 다른 팀원들이 이해를 하지 못한다면 그 코드는 장점으로 보이지 않을 것입니다.

우리가 공통된 코드 컨벤션을 정의함으로써, 개별 스타일의 장점을 유지하면서도 모두가 쉽게 이해할 수 있는 코드를 작성할 수 있을 것입니다. 이러한 노력은 결국 프로젝트의 효율성과 품질을 높여주며, 우수한 결과물을 창출할 것으로 기대합니다!

1. 커뮤니케이션 컨벤션

🦒 매일 08시 30분! 데일리 스크럼이 있을 예정입니다! 전원 필 참!

하루에 한 번, 개발 타임라인에 당일 처리한 일(한 일)과 다음 일정을 업데이트해주세요.

모여서 회의가 불가능할 경우 Discord를 통해 회의합니다.

회의록, 논의 사항은 GIt DIscussion 과 Notion에 정리합니다.

협업 툴 : Github, Notion, Discord

2. 코드 컨벤션

🎉 클래스 명칭

[ 도메인 이름 ] + [ Controller / Service / Repository]

Domain + Service => [도메인 이름] + checker

Infra Structure + Service => APi + [도메인 이름] + Service

🎉 메소드 명칭

C : create + [ 명사 ]
R : get + [ 명사 ]
U : update + [ 명사 ]
D : delete + [ 명사 ]

메소드 명은 🐫(Camel Case)로 표기할 것!

🎉 API 응답

{
  "timeStamp": "",
  "status": "",
  "message": "",
  "data":""
}

응답의 형태는 Common 패키지에서 공용으로 사용되며 공통 양식을 유지할 것!

🎉 예외 처리

Common 패키지에서 Exception Response Handler 클래스를 생성하여 전체 도메인에서 발생하는 예외를 공용으로 관리할 것!

🎉 Entity

1. 생성자 Builder

setter 사용 금지! → builder 직접 구현
클래스에는 builder 사용 절대 금지!

2. All Argument 사용하지않기

생성자 builder를 사용하려면 All Argument를 사용하면 안됨.

🎉 Test Code

DisplayName 명칭 통일

🐏 [ 도메인 이름 ] + [ 생성 / 조회 / 수정 / 삭제 ] + 테스트 : {테스트 내용}(성공 확인 시 ‘success’ 기입)
ex) 키워드 생성 테스트 : success

3. GitHub : PR & Commit 컨벤션

✅ Git Convention

Convention	내용
Feat	새로운 기능 추가
BugFix	버그 수정
Fix	피드백 내용 반영하여 수정
Test	테스트 코드 / 리팩토링 테스트 코드 추가 + 실제 사용하는 코드엔 변경 X
Refactor	프로덕션 코드 리팩토링
Comment	필요한 주석 추가 및 변경
Rename	파일 폴더명을 수정하거나 옮기는 작업만인 경

✅ PR 제목 & 이슈 제목

Back End

🐘 [Label 이름(첫 글자 대문자) - 월 주차, 년도] - {작업 컨텍스트(대문자)} pr 내용 ex) [Feature - Feb 1st, 2024]{USER} 엔티티 설계

Front End

🦒 [Label 이름(첫 글자 대문자) - 월 주차, 년도] - {작업한 페이지} pr 내용 ex) [Feature - Feb 1st, 2024]{ADMINPAGE} 페이지 제작

✅ PR & Commit 규칙

main branch에 바로 push 금지! develop branch로 Pull requests 하기.

git convention을 지키기.

PR 전에 이슈 발행 필수, PR 할 때 이슈 번호 입력 필수!
ex) [#12] Feat : 메인 기능 구현 완료했습니다.

이슈 하나는 본인이 하루 내에 해결할 수 있는 양으로 선정하기.

PR에 적극적으로 코드 리뷰 남기기 (LGTM 금지🙅).

두 명 이상의 PR 승인이 이루어져야 Merge 가능.

Action이 통과해야만 Merge 가능.

Action 실패 시 원인 파악 및 테스트 성공 시까지 수정.

🚩 깃 브랜치 전략

러닝하이팀에서는 브랜치 전략 중 Git Flow 방법을 채택하였습니다.
목적에 따라 브랜치를 나눠두고 관리하는 것은 매우 효율적이라고 생각합니다.
5 종류의 브랜치를 나누어 효율적으로 관리할 예정입니다.

main: 제품 출시 버전을 관리하는 메인 브랜치
dev: 다음 출시 버전을 위해 개발하는 브랜치
feature: 새로운 기능을 개발하는 브랜치
release: 다음 출시 버전을 준비하는 브랜치
hotfix: 출시된 제품의 버그를 고치기 위한 브랜치

🍻 프로젝트 형상 관리

하나의 컨벤션이라고 할 수 있겠습니다. 저희 러닝하이팀이 어떤 방법으로 프로젝트 형상 관리를 하는 지 정리해 보겠습니다.

우선, 미리 추가한 태그들 목록을 이용해 Discussion, Issues, Pull Request에 모두 이용합니다.

🚀 Discussions

디스커션 탭에서는 데일리 스크럼, 공지 사항, 트러블 슈팅 등이 관리되고 있습니다.

회의한 내용을 하루만 지나도 까먹게 되는 현상이 계속돼서 데일리 스크럼 내용을 글로 기록해두기로 했습니다. 확실히 이전에 말한 내용을 확인하기 편하고 커뮤니케이션 비용이 오히려 줄어드는 것을 체감할 수 있었습니다.

동일한 이유로 공지 사항과 트러블 슈팅을 기록할 예정입니다. 글로 옮겨 적으며 공부한 내용을 다시 한번 되새길 수 있고, 주제 별로 참고 자료를 정리해두면 추후에 다시 찾아보기 수월할 것이라 생각하고 설계하였습니다.

🚀 Issues

회의를 통해 해야 할 일을 각자 파악하고 나서, 이슈를 발행합니다.
이전에 만들어둔 양식을 이용해 Refactoring, Feature, Bugfix, Request를 이용해 종류 별로 진행 중인 작업을 활용합니다.
담당자와 라벨을 설정하고, 현재에 맞는 프로젝트를 설정해서 팀원들에게 진행 상황을 알려줄 수 있습니다.

🚀 Pull Request

PR도 Issue, Discussion 탭과 동일하게 양식이 정해져있어, 개발이 마친 뒤 task 단위로 PR을 작성해서 올리게 됩니다.

담당자는 관련 이슈를 명시해두어, 어떤 task를 마무리했는지 명시해 주어야 합니다. merge 시에 자동으로 닫힐 수 있도록 설정해둡니다.
팀원들에게 기능 개발 중 알게 된 사실 혹은 좋은 참고 자료가 있다면 공유해 주고, 다음 날 데일리 스크럼에서 작업 내용에 대해 상세하게 설명해 줍니다.

PR에 대해선 변동 사항에 코드를 상세히 보고 코드 리뷰를 진행합니다. 더 좋은 방안이 있다면 제안하고, 궁금한 내용이 있다면 담당자에게 질문하고 있습니다.