-
Notifications
You must be signed in to change notification settings - Fork 2
컨벤션 및 깃 프로젝트 관리
코드 컨벤션은 프로젝트 내에서 개발자들 간의 이해도를 높이고 협업을 용이하게 하는 중요한 역할을 합니다.
일관된 코딩 스타일과 구조를 유지함으로써 코드의 가독성을 향상시키고, 오해의 소지를 줄일 수 있습니다.
우리가 공통된 코드 컨벤션을 정의함으로써, 개별 스타일의 장점을 유지하면서도 모두가 쉽게 이해할 수 있는 코드를 작성할 수 있을 것입니다.
이러한 노력은 결국 프로젝트의 효율성과 품질을 높여주며, 우수한 결과물을 창출할 것으로 기대합니다!
하루에 한 번, 개발 타임라인에 당일 처리한 일(한 일)과 다음 일정을 업데이트해주세요.
모여서 회의가 불가능할 경우 Discord를 통해 회의합니다.
회의록, 논의 사항은 GIt DIscussion 과 Notion에 정리합니다.
협업 툴 : Github, Notion, Discord
> 변수명: camelCase (ex. memberName, memberAge)
> 함수명: camelCase (ex. getMember, createMember)
C : create + [ 명사 ]
R : get + [ 명사 ]
U : update + [ 명사 ]
D : delete + [ 명사 ]
> 클래스명: PascalCase (ex. User, OrderManager)
> 상수명: UPPER_SNAKE_CASE (ex. MAX_CONNECTIONS, DEFAULT_TIMEOUT)
> DB 칼럼명: snake_case (ex. user_no)
{
"timeStamp": "",
"status": "",
"message": "",
"data":""
}
응답의 형태는 Common 패키지에서 공용으로 사용되며 공통 양식을 유지할 것! `Tab 키` 와 `space bar` 를 혼합해서 사용하지 않습니다.
코드 라인이 길어지면 적절한 위치에서 줄 바꿈을 합니다.
대략 8~90줄에선 `줄 바꿈` 을 고려합니다.
모든 블록에 대해 중괄호 사용 {} ( if, for, while)
연산자, 콤마, 세미콜론 앞뒤에 공백 추가
> Title
=> 커밋 종류 - 관련 Task 제목
> Content
=> 템플릿에 맞게 작성
=> Project 설정
> Title
=> [#관련 이슈] 관련 Task 제목
> Content
=> 템플릿에 맞게 작성.
> 관련 이슈의 `Close` 설정을 해줍니다.
> 최소한 두 명 이상의 리뷰어의 승인이 있을 시, PR 작성자가 `Merge 진행`.
> 추후에 필요 시 팀원이 확인해도 내용을 알 수 있도록 정리.
> PR 생성 시 카카오톡 단톡방에 한번 더 알림 부탁드리겠습니다.
> Action
> 통과해야만 Merge 가능.
> 실패 시 원인 파악 및 테스트 성공 시까지 수정.
`이슈 기반 브랜치 명` 사용 (ex. feature/[#관련이슈])
- Title
`[#관련이슈][커밋종류] 커밋내용`
-
커밋 종류
커밋 유형 설명 Feat 새로운 기능 추가 BugFix 버그 수정 Fix 피드백 내용 반영하여 수정 Docs 문서 수정 Style 코드 스타일 변경 (코드 포매팅, 세미콜론 누락 등) Design 사용자 UI 디자인 변경 (CSS 등) Test 테스트 코드, 리팩토링 (Test Code) Refactor 리팩토링 (Production Code) Build 빌드 파일 수정 Ci CI 설정 파일 수정 Perf 성능 개선 Chore 간단한 수정이나 빌드 업데이트 Rename 파일 혹은 폴더명을 수정만 한 경우 Comment 필요한 주석 추가 및 변경 Remove 파일을 삭제만 한 경우
> 리소스 이름은 복수형 (ex. /users, /orders)
> CRUD 작업에 맞는 HTTP 메서드 사용
> GET /users: 사용자 목록 조회
> GET /users/{id}: 특정 사용자 조회
> POST /users: 사용자 생성
> PUT /users/{id}: 특정 사용자 수정
> DELETE /users/{id}: 특정 사용자 삭제
> 상태 코드 사용
> 200 OK: 성공적인 GET, PUT, DELETE 요청
> 201 Created: 성공적인 POST 요청
> 400 Bad Request: 잘못된 요청
> 401 Unauthorized: 인증 필요
> 404 Not Found: 리소스를 찾을 수 없음
> 500 Internal Server Error: 서버 에러
- 단위 테스트, 통합 테스트, E2E 테스트를 모두 작성하는 것이 이상적
- 테스트 함수 이름은 테스트하려는 기능을 설명하도록 명명 (ex. testUserLogin)
- `@DisplayName` 을 사용해 테스트 목적을 간단 명료하게 작성
코드 커버리지 최소 70% 이상 유지 권장
> DEBUG: 개발 중에만 필요한 상세 정보
> INFO: 주요 이벤트
> WARN: 주의가 필요한 상황
> ERROR: 심각한 오류, 반드시 조치 필요
> FATAL: 치명적 오류, 프로그램 종료 필요
> 예상 가능한 에러는 적절히 처리하고 로그로 기록
> 예상하지 못한 에러는 전체 에러 핸들러에서 처리하고 알림 또는 모니터링 시스템과 연동
> 입력 검증: 모든 입력값에 대해 엄격한 검증을 실시
> 암호화: 민감한 데이터는 반드시 암호화하여 저장
> 인증/인가: JWT 토큰, OAuth 등을 사용한 인증 및 권한 관리
> CORS 처리: 허용된 도메인만 접근 가능하도록 설정
함수 및 클래스 상단에 Docstring 작성 (ex. 파라미터 설명, 반환값 설명)
Swagger, OpenAPI 사용 권장
프로젝트 개요, 설치 및 실행 방법, API 사용법 등 기본 정보 포함
디스커션 탭에서는 데일리 스크럼, 공지 사항, 트러블 슈팅 등이 관리되고 있습니다.
회의한 내용을 하루만 지나도 까먹게 되는 현상이 계속돼서 데일리 스크럼 내용을 글로 기록해두기로 했습니다.
동일한 이유로 공지 사항과 트러블 슈팅을 기록할 예정입니다. 글로 옮겨 적으며 공부한 내용을 다시 한번 되새길 수 있고, 주제 별로 참고 자료를 정리해두면 추후에 다시 찾아보기 수월할 것이라 생각하고 설계하였습니다.
회의를 통해 해야 할 일을 각자 파악하고 나서, 이슈를 발행합니다.
이전에 만들어둔 양식을 이용해 Refactoring, Feature, Bugfix, Request를 이용해 종류 별로 진행 중인 작업을 활용합니다.
담당자와 라벨을 설정하고, 현재에 맞는 프로젝트를 설정해서 팀원들에게 진행 상황을 알려줄 수 있습니다.
PR도 Issue, Discussion 탭과 동일하게 양식이 정해져있어, 개발이 마친 뒤 task 단위로 PR을 작성해서 올리게 됩니다.
담당자는 관련 이슈를 명시해두어, 어떤 task를 마무리했는지 명시해 주어야 합니다. merge 시에 자동으로 닫힐 수 있도록 설정해둡니다.
PR에 대해선 변동 사항에 코드를 상세히 보고 코드 리뷰를 진행합니다. 더 좋은 방안이 있다면 제안하고, 궁금한 내용이 있다면 담당자에게 질문하고 있습니다.
2명 이상✌️의 승인이 되면, ** 마지막 리뷰어가 merge를 진행** 합니다.
그렇게 완성되는 것은 Projects 탭입니다.
현재 팀원들의 진행 사항을 한눈에 보드 형태로 조회가 가능합니다.
월 별로 정리 중에 있습니다. 현재 두 개의 조건으로 자동화를 진행 중입니다.
1. issue가 발행되면, Todo로 위치하게 됩니다.
2. PR이 merge 되면, Done으로 이동됩니다.
최종수정일: 24.08.29