헤이딜러에서 팀으로 개발하면서 효율적으로 코딩하고 PR을 만들고 이 PR들을 관리하는 방식에 대해서 소개합니다.
안녕하세요. 헤이딜러 Android팀의 박상권입니다.
오늘은 효율적이고 행복하게 개발팀원들끼리 협업하는 방식에 대한 이야기를 해보려고 합니다.
서비스가 커지고 회사가 커질수록 함께 일하는 동료들은 늘어나기 마련입니다.👩🏻💻👨🏻💻
함께 일하는 개발자가 많아지면 많아지는 만큼 개발속도가 빨라질것이라고 생각하지만 실제는 그렇지 않은 경우가 많습니다.
개발자를 더 뽑았는데 개발속도는 더 느려지는 경우를 많이 경험하셨을 겁니다.😭
회사에서 팀으로 개발하면서 효율적으로 코딩하고 PR을 만들고 이 PR들을 관리하는 방식에 대해서 소개합니다.
(예전에 포스팅했던 ‘헤이딜러에서는 어떻게 일하나요?’ 의 내용중 협업과 관련된 내용에 기반해서 추가적으로 도움이 될만한 내용들로 작성했습니다.)
TL; DR; (Too Long Didn’t Read)
1. 코딩 규칙 정하기 2. Branch와 커밋이름에 이슈번호 prefix로 적기 3. PR과 커밋은 최대한 작은 단위로 쪼개기 4. GitHub 템플릿으로 PR내용 규격화 5. 라벨 활용하기 6. 리뷰어가 빌드 성공여부/코딩컨벤션 확인하지 않기 7. 코드리뷰 내용 반영할때마다 커밋 id남기기
[코딩 규칙정하기]
개발자마다 코딩하는 방식은 제각각입니다.
똑같은 if/else문을 작성하더라도 각자의 방식대로 코딩합니다.😱
if(){} else {}
vs
if(){}
else {}
name을 표시하는 TextView라는 UI의 id를 정할때도
- textViewName - textView_name - tvName - tv_name - name
등으로 자기가 맘에드는것으로 선택해서 정합니다.
혼자 개발할때는 문제가 없지만 여러명이 하나의 프로젝트를 개발할때는 각자 다른 방식으로 코딩하는것이 문제가 됩니다.
그래서 코딩 컨벤션📝이 필요합니다. 코딩 컨벤션을 만들고 이를 모두가 지켜서 코딩한다면 아래와 같은 점이 좋습니다.
프로젝트의 코드가 누가 개발했느냐에 상관없이 항상 균일하게 유지됩니다
어떤 사람의 코드를 읽어도 쉽게 이해할 수 있습니다
새로운 팀원이 합류해도 코딩 컨벤션을 기반으로 작성하게 되므로 여전히 프로젝트 코드의 일관성이 유지됩니다
개발자들간의 불필요한 논쟁이 필요 없습니다 : 코드 리뷰할때 간혹 답이 없는 문제에 대해 끝없는 논쟁을 하는 경우가 있는데 코딩 컨벤션이 있다면 그에 맞게 코딩하면 됩니다. : 만약 코딩 컨벤션에 관련 내용이 없다면, 서로 협의해서 코딩 컨벤션에 추가한뒤 따르면 됩니다
참고로 헤이딜러 Android팀은 코딩컨벤션을 만들고 오픈소스로 공유하고 있습니다.
PRNDcompany/android-style-guide Contribute to PRNDcompany/android-style-guide development by creating an account on GitHub.github.com
[Branch와 커밋이름에 이슈번호 prefix로 적기]
각 회사마다 사용하는 작업을 하기 위한 이슈번호가 존재할것입니다.
Jira ID
GitHub issues number
등등
저희 회사에서는 Jira를 사용하고 있으며 기획(FTR), 안드로이드(HDA), 아이폰(HDI), 웹(HDW), 서버(HDS) 각각의 프로젝트에서 해당 피쳐 이슈를 생성합니다.
Branch의 이름과 Commit의 이름은 항상 Jira의 이슈번호로 시작합니다.
Branch: feature/HDA-123-aaa-bbb
Commit: HDA-123 커밋내용
이러한 이슈번호 관리를 통해서 어떤 코드에 대해서 History를 확인했을때, 해당 코드가 어떤 피쳐와 이슈로 인해서 수정되었는지 직접 해당 티켓에 가서 확인할 수 있습니다.🔍🔍
[PR과 커밋은 최대한 작은 단위로 쪼개기]
PR과 커밋은 최소 작업단위를 기준으로 작으면 작을수록 좋습니다.
1개의 커밋에는 1개의 행위만 들어 있는게 좋습니다
1개의 PR에는 1개의 작업만 들어 있는게 좋습니다
예를 들어 보겠습니다.
디자인에 맞게 레이아웃을 추가해서 작업했는데 버튼 클릭 처리에 대한 코드를 작성하던중 기존에 사용하던 값을 상수로 빼서 재사용하도록 개선했다. 현재 작성되어 있는 파일의 코드가 정렬이 잘 되어 있지 않아서 IDE에서 제공하는 기능을 통해 코드 리포맷팅 작업도 진행했다.
⛔️ 이 작업에 대한 적절한 커밋이름을 짓기 어렵습니다
⛔️ 커밋 내용중 잘못된 내용이 있어서 특정 작업만 revert해야 하는경우 함께 포함된 작업도 다같이 revert 되어 버립니다
⛔️ 리뷰어가 커밋이름만 보고 어떤 작업을 했는지 명확하게 알기 어렵습니다
⛔️ IDE의 자동리포맷 기능으로 인해 단순하지만 코드가 엄청 많이 변경된것처럼 보여서 리뷰어가 불필요한 변경작업을 모두 봐야 합니다
위와 같은 작업은 3개의 커밋으로 분리되어야 합니다
- 디자인에 맞게 레이아웃을 추가해서 작업 - 기존에 사용하던 값을 상수로 빼서 재사용하도록 개선 - IDE에서 제공하는 기능을 통해 코드 리포맷팅 작업
✅ 1개의 작업에 1개의 명확한 커밋이름을 작성할 수 있습니다
✅ 특정작업만 revert해야할때 다른 작업에 영향을 미치지 않고 온전하게 revert 할 수 있습니다
✅ 리뷰어가 커밋이름만 보고도 어떤 작업을 했는지 파악할 수 있습니다
✅ IDE로 자동으로 변경된 내용들은 리뷰어가 확인할 필요가 없습니다
(1작업 1커밋)
비슷한 이유에서 PR도 최대한 작은 단위로 쪼개서 만들어야 합니다
새로운 화면이나 피쳐를 만들어서 개발할때 이슈를 여러개로 쪼개고 여러개의 PR로 작업합니다.✂️✂️
Jira에서 Base가 될 issue를 생성하고 그와 관련된 sub issue들을 만들어서 작업합니다.
(연관된 sub 이슈 만들기)
각 이슈들에 대한 작업을 진행하면 PR은 이슈 개수 만큼 만들어 집니다.
피쳐 branch를 base로 해서 그 아래 sub branch로 만들어 피쳐 branch로 merge하는 전략으로 진행합니다.
(피쳐 branch에서 따서 피쳐 branch로 merge하기)
이렇게 PR을 작은단위로 쪼개면 아래와 같은 장점이 있습니다
✅ 이슈가 여러개이므로 하나의 피쳐개발을 1명이 아닌 여러명이 작업할 수 있습니다
✅ 이슈마다 작성해야 하는 코드양이 적기 때문에 빠르게 작업하고 PR을 올릴 수 있습니다
✅ 코드 리뷰어가 리뷰해야 하는 코드가 적기 때문에 빠르고 정확하게 리뷰를 할 수 있습니다
✅ 리뷰사항을 반영해야 하는 사항도 적어지므로 리뷰 반영사항으로 인한 코드 변경도 적어집니다
✅ 코드 리뷰가 끝날때까지 기다리지 않고 다른 작업을 수행할 수 있습니다
[GitHub 템플릿으로 PR내용 규격화]
개발자마다 코딩방법이 다른것처럼 PR을 만들때도 PR을 작성하는 방식도 제각각입니다. 그렇기 때문에 PR도 코딩컨벤션처럼 규칙을 정할 필요가 있습니다.
이때 사용하기 좋은게 GitHub의 템플릿 기능입니다.
Issue and Pull Request templates - The GitHub Blog It's hard to solve a problem when important details are missing. Now project maintainers can add templates for Issues…github.blog
PR을 작성할때 필요한 순서, 내용 등 기본 규칙을 정합니다.
예시)
## 개요
## 작업사항
## 변경로직
### 변경전 ### 변경후
## 사용방법
## 기타
2. GitHub Repository에 템플릿 파일들을 추가합니다
3. PR을 만들때 이 템플릿이 자동으로 반영되서 작성됩니다.
물론 기본으로 작성된 템플릿에서 필요 없는 내용은 빼고 필요한 내용을 추가해서 만들면 됩니다.
PR템플릿을 만들어서 운영하면 코딩컨벤션과 마찬가지의 효과를 경험할 수 있습니다.
PR작성자가 어떤 내용을 써야 할지 명확하게 알 수 있습니다.
어떤 PR을 코드리뷰해도 동일한 패턴의 PR내용으로 구성되어 있기 때문에 리뷰어가 읽기 쉽습니다
[라벨 활용하기]
PR의 상태를 확인하려면 해당 PR을 직접 들어가야만 확인할 수 있었습니다.
GitHub의 라벨을 활용하여 각각의 PR의 상태를 효율적으로 관리합니다
라벨을 사용하면 아래와 같은 효과가 있습니다.
현재 PR목록들의 전체 상태를 파악 가능
내가 코드 리뷰해야하는 PR들이 어떤 것들이 있는지 파악 가능
내가 리뷰사항 반영해야 하는 PR들이 어떤어떤 것들이 있는지 파악 가능
헤이딜러 안드로이드팀에서 사용하고 있는 라벨의 예시입니다.
Review Needed: PR을 올렸을때, 피드백을 수정했을때 리뷰어가 리뷰해주어야 하는경우
Answer Needed: 리뷰어가 리뷰를 완료해서 PR을 올린 담당자가 코드를 수정하거나 답변을 해주어야 하는 경우
In Review: 리뷰어가 리뷰를 시작했을때
In QA: 해당 피쳐가 QA중일때
Merge Needed: 리뷰어가 리뷰를 완료하고 Approve해주어 merge해도 문제가 없을때
Simple: 간단한 코드수정으로 리뷰어가 빠른게 리뷰할 수 있을 경우
Base Change Needed: 실제 merge되어야 하는곳은 develop이지만 의존성 때문에 branch-aa-111 을 현재 target branch를 해두었고 나중에 이를 다시 develop 으로 변경해야 하는 경우
리뷰어 이름: 리뷰어의 라벨을 추가해서 해당 리뷰어가 PR의 리뷰어임을 명시
기타 등등
위의 라벨들을 적용하면 PR목록에서 아래와 같이 한눈에 쉽게 파악할 수 있습니다.
PR의 상태가 변경될때마다 변경된 상태에 맞게 라벨을 변경해주면 됩니다
하지만 PR상태에 따라 그때그때 라벨 을바꿔주는게 번거롭고(귀찮고) 실수의 여지가 있습니다. 그래서 이 라벨도 PR의 상태에 따라서 알아서 자동으로 변경되도록 최적화 해두었습니다.
[리뷰어가 빌드 성공여부/코딩컨벤션 확인하지 않기]
당연히 PR이 빌드되는지 확인하고 코딩컨벤션이 잘 지켜졌는지 확인해야 합니다.
하지만 그런사항들을 리뷰어가 하나하나 확인할 필요는 없습니다.
빌드확인
빌드를 확인할 수 있는 도구들은 Jenkins, Travis CI, Circle CI 등 다양하게 존재합니다.
저희 팀은 Jenkins를 사용해서 PR마다 빌드하고 테스트를 수행합니다.
성공: GitHub의 해당 PR의 상태를 pass 처리
실패: Slack의 관련 채널로 실패했음을 알림
2. 코딩컨벤션 확인하기
코드 리뷰어의 시간은 아주 소중합니다. 리뷰어가 사소한 것들을 확인하느라 시간을 뺏기는일은 최소화 해야 합니다.
- 불필요한 import는 빼야 하는데.. - 사용하지 않는 변수인데 왜 들어갔지? - 접근자를 public -> private으로 변경해도 될거 같은데 - 이런 경우에는 if문보다는 switch문을 사용하기로 했는데 컨벤션대로 지키지 않았네
이러한 사소한 것들에 대한 리뷰는 정적분석툴인 SonarQube가 대신 해줍니다.
코드중 반영해야할 사항들이 있다면 코멘트로 리뷰사항을 남겨줍니다
해당 PR에 대해서 종합적으로 리뷰사항을 정리해서 남겨줍니다
SonarQube는 프로그램을 실제 실행하지않고 코드를 분석합니다.
보통은 PMD, CheckStyle, Findbugs등을 사용하지만 SonarQube에 별도의 PRND way rule을 만들어서 우리팀에서 정한 rule에 맞는 코딩스타일대로 코드를 리뷰합니다.
3. 빌드/정적분석을 통과해야 Merge가능하도록 설정하기
위의 2가지(Jenkins, SonarQube)를 활용해서 PR을 Merge하기 위해서는 아래와 같은 조건이 모두 충족되어야 합니다.
최소1명의 리뷰어 approved
Jenkins 빌드 success
SonarQube 리뷰결과 pass
최종 Merge가 가능한 상태라면 위와같은 화면을 보게 될것입니다.
[코드리뷰 내용 반영할때마다 커밋 id남기기]
코드리뷰를 남기고 리뷰사항에 대해서 작업자가 작업을 하고나면, 리뷰어가 해당 사항들이 잘 반영되었는지 다시 확인을 해야 합니다.
이때 코드 리뷰 사항마다 반영된 작업의 커밋id를 남겨두고 리뷰어가 편하게 반영사항을 확인할 수 있도록 해두면 좋습니다
지금까지 언급드렸던 사항들에 대해서 다시한번 정리해보겠습니다.
1. 코딩 규칙 정하기 2. Branch와 커밋이름에 이슈번호 prefix로 적기 3. PR과 커밋은 최대한 작은 단위로 쪼개기 4. GitHub 템플릿으로 PR내용 규격화 5. 라벨 활용하기 6. 리뷰어가 빌드 성공여부/코딩컨벤션 확인하지 않기 7. 코드리뷰 내용 반영할때마다 커밋 id남기기
현재 본인의 개발 팀에서는 몇가지를 사용하고 계신가요?
위의 사항들만 적용하셔도 우리 팀의 개발 효율이 굉장히 많이 올라가는것을 경험하실 수 있을겁니다.
그외에 본인들의 팀에서 사용하고 계신 노하우가 있다면 댓글에 남겨주세요
끝까지 읽어주셔서 감사합니다.
저희와 함께 헤이딜러 서비스를 발전 시켜나가실 분들을 기다리고 있습니다.
https://prnd.co.kr/hiring
위의 채용링크로 많은 지원부탁드립니다.
감사합니다.
가입하기
