2년전 사내 개발 컨벤션과 코드리뷰 등의 정책을 정했었다
회사에서 팀원들과 코드리뷰,컨벤션등을 정하고 시작한지 어언 1년 반정도가 흘렀다. 그때 내가 작성했던 글이 이 글이다.
코드리뷰를 위한 지침 '코드리뷰 피라미드'
코드리뷰 피라미드 관련글만 보시려면 아래로 쭉 스크롤해주세용 ⭐서론(겸 잡담) 아래 페이지에서 코드 리뷰 피라미드에 대한 글을 보았다. 관련글 : https://www.morling.dev/blog/the-code-review-pyramid/
janggiraffe.tistory.com
잠깐 지금까지를 돌아보자면.
우리 유닛이 3명에서, 추가로 3명이 합류해서 6명이 됐고, 담당하는 시스템도 많아지고, 컨텍하는 팀, 담당자도 너무 많이 늘어났다. 대충 요약하면 일이 더 많아졌다는 이야기다.
그래서 코드리뷰를 잘 하고 있는가? 라고 묻는다면 슬프지만 '아니다' 라고 답할 수 바께 없다. 우선 내가 너무 바빠지면서, 팀을 돌볼 수 있는 시간이 적어진게 한몫 했다. 그럼에도 불구하고 하는사람은 하고 안하는 사람은 안하는데, 잘 지켜주는 팀원에게 고맙고 미안할 뿐이다..
절반뿐인 성공(?) 그 반절의 원인은 무엇일까
내가 생각하는 정책이 흐지부지된 이유는 이렇다.
1. 팀원들의 공감을 얻지 못했을..까?
2. 일이 너무 많아 우선순위에서 밀렸다.
3. 귀찮다. 정말 귀찮다!!
4. 그리고 시간도 많이든다.
5. 컨벤션에 맞추기가 익숙하지 않다.
우리팀은 일이 정말 많다. 운영팀이지만 나는 우리 팀을 개발,운영팀이라고 생각한다. 현업들의 끊임없는 니즈가 전부 SR건으로 운영으로 넘어온다. 덕분에 운영 안정성보다는 기능개발에 초점이 좀 맞춰진 느낌이 없잖아 있다.
컨벤션 적용이 장점이 있다지만 원래 하던 업무 스타일을 갑자기 바꾸긴 쉽지 않을 것이고, 특히 연차가 많을수록 더더우 말이다. 그래서 강제성이 없다면 우선 쉽고 간단한것부터 하나씩 적용해가는것도 좋을 것 같은데, 그 중 하나가 바로 커밋 컨벤션 중 하나인 깃모지이다.
깃모지(gitmoji)란?
깃모지는 커밋 메시지에 이모지를 붙이는 규칙이다.
ex) ✨ 새 기능 추가: 로그인 기능 구현
팀 후배와 사내 공모전을 나가게 됐는데, 후배가 제안안 커밋 컨벤션이다. 나름 신선하고, 장점도 확실한 것 같아 이번 사내공모전 프로젝트의 커밋 컨벤션으로 채용했다.
깃모지의 장점
깃모지를 사용한 커밋 메시지의 장점은 이렇다.
1. 한눈에 파악하기 쉬운 직관적인 메시지
2. 팀원과 같은 이모지를 사용해서 협업 및 커뮤니케이션에 도움을 줌
일단 뭘 했는지 커밋메시지가 눈에 확 띄여서 내용을 파악하고, 추적하기가 쉬워진다.
3. IDE의 Extension을 이용해 이모지를 외우지 않아도 사용할 수 있음
회사에서는 다음과 같은 한글 형태의 프리픽스를 사용했었다. 물론 이것도 위의 1,2번의 장점을 가진다고 생각한다.
예제
버그수정 [IM0001]: 단체항공권 승인 관리 검색 시 GDS PNR 노출 오류 수정_01
리팩토링 [IM0002]: 환불 실패 수정_중복 프로세스 제거_01
유형 [ITSM번호]: 제목_순번
기능추가 : 새로운 기능에 커밋
기능삭제 : 기존 기능 삭제 커밋
기능변경 : 기능 변경 커밋
버그수정 : 버그 수정에 대한 커밋
리팩토링 : 코드 리팩토링
문서 : 문서 추가 삭제 수정
다만 정해놓은 프리픽스 외에도 다양한 변형들이 생겨났다. 예를들면 이런건다.
원래 정의한 프리픽스 : 기능추가
실제 사례 : 기능개발, 기능생성, 추가개발 ...
이렇게 되면 배포하는 입장에서는 커밋메시지를 보면서 배포내역을 정리할 때 좀 피곤한데, 깃모지를 사용하면 이런 좋은게 있다.
깃모지 확장도구를 설치하면 다음과 같이 커밋메시지에 쓸 깃모지를 내가 선택하는 메뉴가 생긴다. 고로 위와 같은 프리픽스의 변형이 나오지 않을거란 말씀..
아무튼 잘 써보고 후기를 또 올리겠다. 깃모지에 대한 더 자세한 정보는 아래 공식 사이트를 확인하면 좋다.
gitmoji
:truck: Move or rename resources (e.g.: files, paths, routes).
gitmoji.dev
