[키즈존 어플 개발기] 3. Coding Convention, Git 활용 전략

생각보다 처음에 짰던 계획대로 진행이 되고 있고 일정관리도 나름 잘 되고 있어서 바로 퍼블리싱에 들어갈 수 있었다. 우리 둘 다 PM하면 나름대로 철저하게 잘 할 것 같다 나의 바람이지만...^^

 

협업을 요하는 프로젝트에서는 코딩 컨벤션이 필수적으로 필요하다. 코드의 가독성을 증진시키고 여러 사람들이 유지보수할 수 있게 이해도 활용도를 높이기 위해서이다. 인턴으로 근무하기 전에 혼자 개발 공부를 할 때에는 코딩 컨벤션이라는 것 자체를 몰랐다. 그래서 컴포넌트 명을 대문자로 쓰는 것 외에 지켰던 규칙이 단 한개도 없었던 걸로 기억한다. 회사에서 우리 팀 컨벤션을 지키려고 노력을 하다 보니, 자연스럽게 내 개발 습관이 되었고 개인 프로젝트에서도 클린 코드를 유지하기 위해 같은 규칙을 적용시키고 있다. 

 

그럼에도 불구하고 블록별로 클래스명 지정하는 방법론 등이 있다더라... 그런거 없이 wrap, container, item 등등 내 맘대로 골라쓰곤 했는데 나름 공부 많이 했다고 생각했는데 아직도 모르는 거 천지 ^^ 덕분에 배우는 거 엄청 많은 프로젝트가 되고 있어서 좋다! 혼자 했다면 아는 만큼만 했을 것 같기 때문...

 

깃도 열심히 활용하려 한다. 일단 프로젝트 보드도 사용하고 이슈, PR 모두 사용할 것이다. 깃헙액션으로 배포 테스트까지 하려고 하는데 아직 퍼블리싱 단계라 배포까지 하지 않아서 aws 연결하게 되면 그 때 고려해봐야할 것 같다. 둘이지만 어쨌든 협업 프로젝트이다 보니, PR리뷰라던지 등등에 대해 경험해보려 한다. 한 가지 걱정되는 점은 프론트는 코드리뷰가 어느정도 가능해도 백은 둘 다 무지한 상태라서 수고했습니다 외의 말은 써줄 수 없을 것 같다는 것이다... 열심히 공부해보자!!!!! 홧띵

 

Coding Convention

1. Variables
- 상수 : `UPPER_CASE`
- 그 외 모든 변수 : `camelCase`
- Boolean 타입 변수 : is, has, can 접두사

2. Types & Enums
- PascalCase
- any타입은 가급적 사용하지 않기

3. Functions
- 함수 이름은 동사로 시작

4. Event Handler
- Component Props 넘기는 이벤트 핸들러에는 on 접두사 붙임
- ``</testcomponent onclicksavebutton={} >
- 이벤트 핸들러 이름은 Noun first

5. Props Naming
- 컴포넌트 파일 내의 props 타입 정의 이름은 TProps로 통일
  그 외의 경우 T + 기능이름 + Props 로 통일

6. File Naming
- React Component 정의한 파일은 PascalCase.tsx
- React Component 포함하지 않는 파일은 .ts

7. Comments
TODO : 기능이나 최적화, 리팩토링 면에서 미래에 할 일
FIXME : 문제가 될 수 있지만 미래에 고칠 부분

---

Git 활용 전략

1. Commit
- feat : 새로운 기능 추가
- chore : 환경 설정 같은 작업
- fix : 오류 수정
- refactor : 코드 리팩토링 및 개선
- style : 스타일 수정
- test : 테스트
- docs : 문서 작성
위의 속성을 사용하여 아래와 같이 작성
feat(#issueNumber_branchName) : 새로운 컴포넌트 추가

2. Pull Reuqest
[FE / BE] 추가된 기능 및 작업 사항
1. 작업내용

   #1 Next.js 환경설정

   (#IssueNumber 제목)
2. 남은 작업

 

3. Git Branch
1) 주요 브랜치

• master
  배포되는 상용 코드
• develop
  테스트를 위한 개발중인 코드, release할 준비가 되면 master로 머지시키고 TAG, release 브랜치로 관리

2) 보조 브랜치

• feature
  곧 배포할 기능을 개발
  master에서 생성하고 develop에 머지하여 테스트함
  develop에서 테스트가 완료된 경우 develop에서 master로 머지하여 배포
  feature/#issueNumber_branchName
• release
  버전 넘버를 부여하여 관리하고 원치 않는 돌발사항에 대비하여 코드를 관리함
  배포된 이후 master에서 브랜치를 따서 release v1.0과 같이 커밋
  release-v1.0 과 같이 관리함
• hotfix
   배포한 이후에 버그가 나올 경우 master 코드 수정하는 용도의 브랜치