무엇을 먼저 개발?
우리팀이 좀 고민을 한 지점은 핵심기능을 먼저 개발하는게 먼저인지 쉬운것을 먼저 개발하는것이 먼저인지였다.
사실 핵심 기능을 개발하는것이 가장 중요했기에 나는 핵심 기능에 힘을 쏟아야한다고 생각했으나 팀원들의 의견을 들어보았을때 당장 구현이 힘든 핵심기능보다 뼈대를 만드는 작업이 우선이라고 했다.
API 명세서 작성
이제 프론트엔드와 백엔드가 협업을 해야했다.
그래서 통신을 위한 자세한 명세가 필요했다.
그래서 각각의 페이지에 대해 필요한 기능들을(특히 post, get 등 정보를 주고 받는것에 관한 기능들)나열하는것을 먼저 하였다.
그 후 각각의 페이지에 맞게 API를 작성하였다.
컨벤션 정하기
협업을 위해서 컨벤션(규칙)을 정하기로하고 각각의 컨벤션을 정했다.
커밋 컨벤션
- 네이밍 컨벤션
- feat : 새로운 기능에 대한 커밋
- fix : 버그 수정에 대한 커밋
- build : 빌드 관련 파일 수정에 대한 커밋
- chore : 그 외 자잘한 수정에 대한 커밋
- ci : CI관련 설정 수정에 대한 커밋
- docs : 문서 수정에 대한 커밋
- style : 코드 스타일 혹은 포맷 등에 관한 커밋
- refactor : 코드 리팩토링에 대한 커밋
- test : 테스트 코드 수정에 대한 커밋
그래서 보통 일반적으로 Feat : 로그인 기능 구현이런식으로 작성을 한다. 우리팀은 여기서 더 추가하여 Feat일때 Add, Fix, Change를 추가로 적어보자고 했다. 이것을 적용해서 예시를 들자면 Feat : Add 로그인 기능 구현 라고 적으면 된다.
추가적으로 커밋에 대한 자세한 설명과 이슈 번호를 적는것은 옵션으로 하도록 하였다.
브랜치 컨벤션
브랜치를 만들때에도 컨벤션을 정했다.
feat/{이름 이니셜}/{브랜치 제목(기능 등)}이렇게 작성을 하기로 하였다. 예시를 들자면 feat/ksd/makeDrawing라고 적으면 된다.
git-flow 전략
또한 우리 팀은 git-flow 전략을 사용하기로 하였다.
main(release)브랜치, develop브랜치, feature 브랜치로 나누어서 진행을 하고자 한다.
대부분의 작업은 각각의 feature 브랜치에 올리고 이를 develop 브랜치에 merge 하면서 작업을 할 것이다.
pr 정책
우리 팀은 main 브랜치에는 3명 이상의 approve가 있어야하고, develop 브랜치에는 1명 이상의 approve가 있어야 merge가 가능하도록 하였다.
오늘 하루는 어땠나
오늘은 올해의 마지막 날이었다.
계속 프로젝트를 하다가 급하게 KBS 연기대상을 틀고 카운트 다운을 보며 새해가 되자 소원을 빌었다.
실감이 나지 않는다...
아직도 2022년같은데 2023년이 되었다.
새해가 되었으니 다시 마음을 다잡고 가보자
