현재 중소기업 IT회사에서 근무하고 있는데
안타깝게도 우리는 코드리뷰 문화가 활성화되지않아
코드리뷰 방법, CL, MR에 대한 내용을
현직 만 1년이 지난 시점에서 관심을 가지게 되었다.
오늘은 CL 작성 방법을 알아보고자 한다.
그리고 Kimtaeng님의 블로그에서
https://madplay.github.io/post/writing-good-cl-descriptions 좋은 cl 설명 작성글을 참고하였다.
CL은 Change List의 줄임말로 변경사항을 기록하는것을 뜻한다.
나는 보통 버그수정, 작업현황을 커밋 할 때 나는 어떤식으로 작성했는지 보았는데...
현직 2년차 개발자의 커밋내용이라 하기에도 민망할 정도로
나만 알아볼 수 있는 불친절한 기록, 사실 변경사항을 기록했다? 라고 말하기도 애매한 cl을 작성하고 있었다.
그냥 봐도 알겠지만
위의 cl은 좋지 않은 설명이다.
이유는 설명의 목적을 제공하지 않기 때문이다.무슨버그인지, 문제 해결을 위해 무엇을 했는지 정보제공이
이루어지지 않았기 때문이다.따라서 좋은 cl로 변경하기 위해서는
① 설명의 목적 파악
② 수행중인 작업에 대한 간략한 요약
③ 줄바꿈하여 명령문의 완전한 문장으로 내용 요약[예시-수정전]
"디자인부분 수정(8건 레드마인 업로드 완료)" 라는 내용을[예시-수정후]
디자인 수정레드마인 디자인 수정 요청 8건에 대한 변경 작업을 수행한다.
라고 바꾸는 것이다.④ 그리고 한줄 줄바꿈 후 충분한 설명을 작성한다.
[예시]
수정 1. 피그마1.3.0버전의 디자인을 적용하여 검색창의 크기 및 색상을 변경합니다.
수정 2. 기존 메인화면의 이미지배경의 깨짐현상이 w-full의 원임을 찾았고, 사이즈를 w-96사이즈에 변경하였습니다. 사용자의 이미지 크기에 따라 최대 w-96에 맞춰질 예정이나 크기가 작을경우 여백이 발생할 수 있습니다. 여백 디자인에 추가적인 이슈가 있을 경우 변경내용을 일감에 추가해주세요. 등이로써 첫번째 줄에는 cl의 변경사항을 알고, 나머지는 설명에 대한 특정 구현, 현재 해결방안 등을 알 수 있다. 이것이 버그수정이라고 할 경우에는 향후 방향에 대한 설명 및 변경을 진행하는 이유에 대해서도 붙일 수 있을 것이다.
그렇다면 변경사항이 장황하고, 더 디테일 할 수록 좋은건가?
해당 내용은 cl 변경사항을 작게 나누는 방법을 통해 알아보자!
