이직한 회사에 입사한지 6개월 정도 지났다.
처음 이 회사에 왔을때는 코드리뷰도 진행하고 배포도 주기적으로 하고 스크럼을 진행하는 등 꽤 애자일하게 잘 굴러가고 있다는 인상을 받았다.
그래서 지금은 '이 회사가 그렇지 않느냐?' 라고 물어본다면 그건 또 아니다. 다만 부족하거나 아쉬운 면들이 있었고 이를 해결하기 위한 나의 노력들을 한번 포스팅해보고자 한다.
커밋 메세지 제대로 작성하기
처음 입사하였을때 커밋에 규칙도 없고 커밋 메세지로는 전혀 업무를 확인할 수가 없었다.
단순히 "수정" 이라거나 "ㅇㅇ 모듈 로직 수정" 정도의 커밋이 전부였다.
문제는 이러한 커밋 메세지는 전후 관계를 알 수 없는 신입이 볼 때 전혀 이해가 되지 않는다는 점이다.
또 한 팀원이 오타나 실수를 했을 경우에도 이게 어떤 의도로 변경했는지를 알 수 없기 때문에 캐치하는데 너무 힘이 든다.
커밋 메세지를 잘 작성하는 방법에 대한 이야기는 아래의 글들을 참조하길 바란다.
- Git 커밋 메시지 작성법(How to Write a Git Commit Message) - item4 Dev Story
- 좋은 git 커밋 메시지를 작성하기 위한 7가지 약속 : TOAST Meetup
나부터 잘 하자!
무작정 팀원들을 바꿀 수 없다는 생각에 나부터 잘 하자는 생각으로 커밋 메세지를 작성했다.
커밋 메세지에서 가장 중요한 것은 무엇을 했는지를 제목에 간단 명료하게 작성하는 것 그리고 무엇이 바뀌었는지와 왜 그렇게 수정하게 되었는지를 작성하는 것이 중요하다.
무엇이 그리고 왜 수정되었는지를 잘 추적하기 위해서 github의 issue나 jira의 issue 번호를 커밋 메세지에 붙여 트래킹이 가능하도록 해야 한다.
커밋 메세지의 숫자를 맞추기 위해 나는 Visual Studio Code를 사용해 Git 커밋 메시지 작성하기라는 아티클을 참고 했다. 기본 에디터를 visual studio code를 사용하고 최대한 이 길이에 맞춰서 명료하게 작성하기 위해 노력한다.
그 이후..
내가 먼저 이 규칙을 지킨 이후로 몇번의 코드리뷰에서 코드를 이렇게 짠 이유가 커밋 메세지에 있다고 답변 한 뒤로는 다른 팀원들도 커밋을 자세히 쓰는 모습들을 보이고 있어서 나름 뿌듯해졌다.
물론 아직 글자수를 맞춘다거나 하는 규칙을 지키고 있지는 않지만 보다 자세히, 트래킹이 가능하도록 커밋을 하고 있다는 것 만으로도 충분히 긍정적으로 변했다고 나는 생각한다.
문서화 하기
입사한 당시에는 정말 큰 프로젝트 단위의 설명을 제외하고는 어떤 문서화도 되어있지 않았다.
그러다보니 신규 입사자가 올때마다 시스템을 이해하기 위해서는 현업자에게 물어봐야 하는
깃헙, 지라의 이슈 잘 작성하기
우리 팀은 지라를 단순히 테스크 관리 용도로만 작성하고 설명이 부족한 상황이었다.
이러면 문제점이 신규 입사자는 작업 히스토리를 파악할 수가 없어서 현업자에게 모든 것을 물어봐야만 하는 상황이 반복된다. 이렇게 의존도가 높아지면 자율적인 작업이 불가능하다.
이를 해결하기 위해 지라에는 변경 사항들을 댓글로 열심히 달았고, 개발적인 이슈는 깃헙에서 관리했다. 물론 이중 관리 포인트가 되기 때문에 좋지는 않지만 아예 하지 않는 것보다는 낫다고 생각했고, 나를 시작으로 다른 팀원들도 깃헙 이슈를 사용하고 있다.
확실히 추적이 가능한 작업이 이어지고 있어서 코드 리뷰때도 어떤 내용인지 물어보는 경우가 줄어들고 있어서 만족 스럽다.
위키에 문서화 시키기
내가 작업하거나 공통적으로 알아야 되는 내용들은 문서화를 했다.
아래는 내가 작성했던 문서화 내용들이다.
- 신규 입사자를 위한 메뉴얼
- 개발 환경 세팅
- 개발시 자주 생기는 문제
- 프로젝트에서 발생한 문제
- 프로젝트때 생성한 모델들에 대한 관계 설명
그 이후 다른 개발자들도 위키에 문서를 작성하거나 수정하고 있어서 변화를 준 것 같아 좋았다.
그 외
그 외에도 꾸준히 좋은 아티클들을 공유하면서 정적 분석기 도입(JSLINT, Rubocop) 코드 리뷰 온라인화 라거나 Pull Request 방식의 워크 플로우를 추천했고 도입했었다.
정적 분석기의 경우에는 처음에는 외면 당했지만 많은 코드리뷰에서 대부분 코딩 스타일의 문제를 찾는게 대부분이어서 git prehock 으로 체크하도록 도입을 시켰고
코드 리뷰 온라인화는 절반의 도입을 성공하여 우선 코드 리뷰를 온라인으로 먼저 본 뒤 다시 모여서 하는 방식으로 변했고, Pull Request 방식은 도입 하루만에 커미터가 없으면 부담스럽다는 의견으로 실패했다.
결론
팀원들은 개개인의 성향을 가지고 있고, 특히 개발자는 자기만의 생각이 강한 개개인이기 때문에 모두를 변화시키려고 하면 안된다.
좋은 경험을 지속적으로 보여주고 스스로 체감하도록 이끄는 게 더 좋다고 본다.
그리고 끝내 설득할 수 없을지도 모른다. 팀마다 문화가 다르기 때문에 올바른 방법은 없다. 다만 변하하고 싶다면 먼저 좋은 경험을 공유해주는 것에서 시작해보면 좋을 듯 하다.