#04. Github를 통해 협업하기
- 다른 개발자와의 협업한 경험이 적은 엔지니어
- 팀 내부의 생산성 향상을 위해 고민하는 개발자 및 Team Lead
소프트웨어 엔지니어의 시간의 대부분은 코드를 쓰기 보다는 읽는 데 소비합니다.
엔지니어는 팀 내에서 다른 팀원의 코드를 읽고 리뷰합니다.
오픈소스 프레임워크 또는 라이브러리의 소스 코드를 보기도 합니다.
스택 오버플로우에 질문에 대한 코드를 읽고 지금 해결하고자 하는 문제의 답을 찾습니다.
물론 코드를 누가 읽더라도 의미전달과 맥락을 명확하게 하는 것도 중요하지만 팀 안에서 효과적으로 읽어야할 코드에 집중하고, 더 중요한 문제를 놓치지 않으려면 팀이 어떻게 일해야하는 지 정의하는 것이 좋습니다.
이 문서에는 팀이 코드를 작성하고 제품에 적용하는 과정에서 어떻게 협업 해야하는 지에 대한 고민들에 대해 다룹니다.
- 코드의 형상 관리를 위한 도구로 여러가지 방법을 사용하지만, 이 문서에서는 Github에 대한 정보만을 다룹니다.
소프트웨어 엔지니어가 협업하는 과정은 위와 같습니다.
팀이나 조직에 따라서 구체적인 방법은 다를지라도 엔지니어들이 협업하는 방식은 주로 Github과 같은 형상 관리 저장 플랫폼에서 이뤄집니다.
코드를 체크인하고, 서로에 대한 코드를 리뷰 및 토론하고, 코드 베이스에 변경 사항을 적용합니다.
이 과정에서 어떤 문제가 생길 수 있고 그 문제를 풀기 위해서 소프트웨어 엔지니어가 더 잘 협업하기 위해 어떤 고민을 할까요?
- 코드 컨벤션, 스타일 가이드의 부재: 좋은 코드에 대한 정의가 사람마다 달라 코드 리뷰가 때에 따라 지나치게 오래걸립니다.
- 지나치게 큰 PR의 코드 변경사항: 코드 변경 사항에 대한 맥락을 파악하기 힘듭니다. 또한 떄문에 소프트웨어의 결함을 제때 발견하기 어려워집니다.
- 이슈 템플릿의 부재: 버그에 대한 이슈 트래킹 방법이 제각기 다를 경우, 코드의 결함을 제때 처리하기 어렵습니다.
- 그외에 일어날 수 있는 코드와 그를 위한 협업에서 일어나는 어려움을 파악할 수 없습니다.
위의 문제들을 해결하기 위해 많은 소프트웨어 엔지니어링 팀은 사내, 팀내 규칙을 도입합니다.
내부적인 컨센서스와 교육, 그리고 실행을 통해서 더 빠르게 구성원들이 코드를 체크인하고, 일련의 과정을 거쳐서 코드를 메인 브랜치에 머지할 수 있도록 합니다.
하지만 이는 분명히 장단점이 있습니다.
첫 번째로, 협업 규칙들은 정착되서 생산성을 높혀주기 까지는 생각보다 오랜 시간이 걸립니다. 다른 회사에서 잘 동작했던 규칙들이 현재의 팀에서는 생산성을 저해하고 팀원들의 사기를 저하시키는 요인이 될 수 있습니다. 충분한 커뮤니케이션과 해당 규칙에 대해서 솔직하게 피드백할 수 있는 문화가 없다면 없으니만 못한 액션이 될 수 있습니다.
두 번째로 일부 연차가 높은 개발자의 입맛에 맞춰서 흘러갈 수 있습니다. 파이썬 개발 10년을 넘게 한 시니어 개발자의 규칙들에 대한 의견은 신입 개발자보다 더 신뢰하기 쉽습니다. 하지만 그에 대한 의견이 소수의 인원이 가지고 있는 배경 지식과 다른 팀원들과의 배경 지식의 불균형을 좁힐 수 없다면, 해당 규칙은 없어지거나 수정되어야 합니다.
세 번째, 모든 규칙은 일관성있어야 합니다. 구성원 모두가 해당 규칙을 잘 지키려고 노력하고 다른 구성원의 코드를 리뷰할 때 그 규칙을 근거로 리뷰가 이뤄져야합니다. 이는 생각보다 어려운 일입니다. 때로는 누군가 메인 브랜치에 머지되는 코드의 퀄리티를 관리하는 "수문장"이 되어야 하는 등 (자동화된 툴이 있다면 더 쉽게 해결할 수도 있지만) 규칙만 정해진다고 해서 끝이 아니라 시작입니다.
위에서 말했던 트레이드 오프들이 있다는 것을 인지하고, 규칙을 조심스럽게 도입해야합니다.
'구글 엔지니어는 이렇게 일한다'라는 책에서 팀내 규칙을 도입하기 전에 고려할 것들에 대해서 이렇게 이야기 합니다
이루고자 하는 목표를 명확히 했을 때, 규칙이 따라온다.
규칙이 필요해서 규칙을 만드는 것보다. 문제를 정의하고, 조직에서 해결해야하는 것들이 무엇인지, 그것들을 어떻게 해결할지에 대한 고민의 끝에는 규칙이 있습니다.
아래에는 주로 하는 팀내 규칙들에 대해 이야기 합니다.
각 코드 변경 사항을 세부 코드를 열어보지 않아도, 커밋 메시지만 읽어도 변경 기록을 유추할 수 있도록 하는 목적
Conventional Commits 컨벤셔널 커밋은 커밋 메세지에 사용자와 기계 모두가 이해할 수 있는 의미를 부여하기 위한 스펙입니다.
<타입>[적용 범위(선택 사항)]: <설명>
[본문(선택 사항)]
[꼬리말(선택 사항)]
위에서 언급한 것처럼 컨벤셔널 커밋은 하나의 예시입니다.
팀 내에서 다른 커밋 규칙을 따른다고 해서 잘못된 것이 아닙니다. 다만 팀내에서 일관성있어야 하고, 전달하려는 바가 명확해야 합니다.
참고: [Git] Commit Message Convention(커밋 메시지 컨벤션)
PR은 각 엔지니어의 작업 단위와 코드 내의 변경 사항, 그리고 코드에 대한 논의와 결정이 일어나는 곳입니다. 좋은 PR이 중요한 이유는 긍정적인 논의를 통해 코드의 결함을 미연에 방지하고 더 견고해지게 만들기 위하고, 나아가 다른 작업에서의 작업 생산성을 높히기 위한 팀내 협업을 위해서 이기도 합니다. 위에서도 언급한 것과 같이 PR의 코드 변경 사항은 작으면 작을 수록 좋습니다 (참고: Optimal pull request size). 리뷰어는 리뷰를 할 코드가 너무 많아서 피로해지고, 리뷰받는 사람은 변경사항이 많기 때문에 피드백 후 고칠 사항도 많아져 더 피로해지게 됩니다.
Github에서는 레포 내에서 사용할 PR 템플릿을 만드는 기능을 제공합니다. 자세한 방법은 아래의 사항을 참고해주세요.
좋은 Pull Request를 만드는 방법과 PR Template 구성
Adding a pull request template | Github Docs
PR TEMPLATE에서는 아래와 같은 정보를 주로 담으면 좋습니다.
- Tickets/Issues: 관련 이슈나 티켓
- Description: 설명
- 체크리스트: 해당 레포에 만들어지는 PR 공통으로 수행해야하는 체크리스트 (테스트 수행 여부, 특정 스타일가이드 관련 코드 체크 여부 등)
- (optional) 리뷰 받고 싶은 부분
리뷰에서는 PR로 만들어진 코드 변경사항들을 리뷰합니다.
위 그림은 리뷰에서 집중해야하는 것과 집중하지 않아도 되는 것들을 알려줍니다.
스타일에 대한 리뷰가 가장 덜 중요합니다. 스타일은 린터나 툴을 통해서 최대한 해결하는 것이 좋습니다.
대신에 잠재적인 버그와 코드의 디자인, 또한 문제와 그에대한 접근법에 대한 논의를 통한 팀원들과의 협의를 찾는 것이 더 중요하다는 점을 잊지 말아야합니다.
아래는 구글의 코드 리뷰어 가이드입니다.
깃헙에서 이슈는 어려가지 방법으로 사용됩니다. 작업에 대한 진행 상황, 버그 트래킹, 피쳐 요청에 대해서 사용하기도 합니다.
많은 오픈 소스 프로젝트에서 이슈를 버그와 문제 해결 방법에 대한 위키로 사용하기도 합니다.
깃헙에서는 PR과 마찬가지로 이슈 템플릿 기능을 제공하고, 추가적으로 이슈들을 필터링하기 위한 라벨링, 그리고 작업 상황, 피쳐에 대한 계획을 더 잘 파악하기 위한 마일스톤도 제어할 수 있습니다.