인트로
우테코과정을 겪으면서 팀프로젝트와 근로활동 두 가지를 번갈아가면서 작업하기가 정말 쉽지 않았습니다.
가끔 채용공고를 보다 보면..
일의 멀티태스킹이 가능한 사람을 찾는 공고를 볼 수 있습니다.
여러팀의 업무를 한명이 하는 경우도 있다고 하고,
프론트엔드가 보통 백엔드보다 적어서 더 많은 기능에 참여할 가능성이 높긴 하다고 합니다.
어린시절 어떻게 수학시간에 영어를 풀면서도 두 과목 다 성적을 유지했는지 참...
중간부터는 땡쿠 프로젝트와, 지원사이트 개발 두 팀에 팀문화를 적용해서 각 팀마다 협업을 위한 장치를 마련했습니다.
협업을 잘 하기 위해서 팀, 개인적으로 적용했던 방법을 소개하려고 합니다.
협업에서 중요한 것
혼자 개발하는 1인 개발자가 아니라면 타인이 작성한 코드를 보게 될 거 입니다.
문제가 생길만한 여지가 있으면 상호감지하고, 피드백을 줌으로써 서로 이해하기 쉽고 품질좋은 코드를 작성하는 것이 중요합니다.
팀원이 API를 TS로 마이그레이션 하는 PR에 코드리뷰를 하면서 오류가 없어 approve를 했었습니다.
후에 해당 API를 수정할 일이 있어 확인했더니 axios resonse는 error일때만 message를 포함한 타입으로 작성했어야 한다는 것을 깨달았습니다.
문제가 생길만한 여지가 있으면 상호 감지하는 것!
피드백을 줌으로써 서로 이해하기 쉽고, 품질좋은 코드를 작성하는 것이 중요하다.
각자가 분업을 하는 것이 아닌 협업을 통해 '우리'의 프로젝트를 진행하는 것이 중요하다고 생각합니다.
코드리뷰 잘하기
코드를 보는 관점은 사람마다 다르다. 영화한편을 봐도 느끼는 것이 다 다른것처럼 같은 코드에도 사람들이 느끼는 바가 다 다릅니다.
언젠가 PR로 리뷰를 작성했는데 코멘트가 160개정도 달린 후에야 머지 된 경험이 있었습니다.
많은 코멘트가 달리면 그만큼 의견교환이 활발하다는 반증일수도 있지만..
경험한 바로는 집중력이 떨어지고 너무많은 코멘트에 어디를 봐야할지 잡기 힘든 경우가 많고, 가장 큰 문제는 렉이 많이 걸린다..
PR단위로 많은 의견을 교환하기 전에 너무 많은 코멘트를 줄이고 양질의 코멘트만 남겨 PR의 유지보수성을 높이고 원활한 협업을 할 수 잇을까 고민하게됐습니다.
1. RCA룰
팀에서 첫번째로 적용한 방식입니다.
Request, Comment, Approve 3가지를 코멘트 앞에 다는 방식이었습니다.
마치 Styled Component 앞에 S를 붙이는 컨벤션(내가 애용한다)처럼 코멘트만 보더라도 이걸 수정해야하는지 단순 의견교환정도인지 알 수 있습니다.
의미있는 코드상의 수정이 아닌 단순 스타일과같은 경우에도 코멘트가 너무 많이 달리는 것을 막아줬고, 꼭 바꿔야하는 r이 아닌경우에는 유도리있게 진행해서 PR이 머지되는 시기를 앞당길 수 있었습니다.
그리고 추가적으로 코멘트를 달 때 최대한 approve와 request change만을 사용해 진행하였습니다.
2. 코딩컨벤션 문서화
코드스타일의 경우 내가 읽기 불편한 코드가 남에게는 편할 수 있습니다.
이런 의견차이를 미리 정하고 일관성 있는 코드를 작성해서 가독성을 높일 수 있었습니다.
여기저기서 color 를 마구잡이로 선언하는 경우나, props에 타입을 다는 방식등에 적용했었는데요
결과적으로 모두가 만족할 수 잇는 코드의 최소한의 요구사항을 갖게 됐습니다.
게다가 컨벤션 문서도 살아있는 문서로써 지속적으로 의견을 주고받아 업데이트를 수정하는 것이 중요합니다.
그때는 맞고 지금은 틀릴 수 있으니까요.
이벤트 스토밍
한가지 이름을 여러가지로 대응하면 서로 정확히 어떤 것을 말하는지 알기 힘들 때가 있습니다.
땡쿠 프로젝트를 진행할때 유저입장에서는 단순히 '쿠폰을 보내야 해' 라고 하면 도메인 내부에서는 receiver의 정보와 sender의 정보를 백엔드로 전송하고 쿠폰을 생성하게 됩니다.
쿠폰으로 약속을 생성하는 행위도 promise, event, meeting등 다양한 이름으로 불리고 있었습니다.
이벤트 스토밍을 통해서 각자 다르게 쓰고 있던 도메인 용어를 정리시키고 각 서비스에 대한 의존관계와 순서를 정립할 수 있었습니다.
실제로 해보니 재밌었습니다. Miro와 같은 협업툴도 써봤지만 직접하는게 더 낫더군요 :)
진행방법은 강의를 참조하였습니다.
실제로 바뀐 점...
팀에 어떤 영향을 줫을까요?
컴포넌트 설계단계에서 동일한 양식을 유지했기 때문에 이해하기 훨씬 쉬워졌고,
어떤 의도로 작성했는지 파악하는데 더 유리해졌습니다.
또 단순히 어떤 코드를 작성했는가 뿐 아니라 어디에 중점을 두고 변경해야 하는지를 명시해줘서 리뷰시간이 단축되고 불필요한 코멘트가 줄어들었습니다.
불필요한 코멘트가 줄어서 압박감이 줄고 pr단위당 집중력이 올라간 것은 덤 입니다.
그래서 여기서 해피엔딩인가요..?
아닙니다. 아직도 문제가 있었습니다.
pr의 단위가 충분히 작지 않았을 때는 여전히 거대한 pr이 생성이 됐고 같은 문제가 반복됐습니다.
또 pr작성자의 안내에 너무 의존하게 되면 작성자가 파악하지 못한 작은 문제들을 리뷰어들도 못보고 지나치는 경우가 많아질 수 있었습니다.
개선해야 할 점이 남아있지만 팀적으로 코드리뷰 문화를 정착시키면서 리뷰효율성이 많이 증가했다고 느낍니다.
정답은 없겠지만 다양한 코드리뷰 도구들이 소개됐으면 하고,
저희 팀의 방식이 좋은 선례가 되어 제가 다른팀에서 일하게 될 때 그 팀에 긍정적 영향을 줄 수 있었으면 좋겠습니다.
'프로그래밍 공부내용 > Git & Tools' 카테고리의 다른 글
| pull을 통해서 페어가 작업한 내용 가져오기 (0) | 2022.05.04 |
|---|---|
| clone 에 관하여 (0) | 2022.04.25 |
| 깃 pr merge 이후 (0) | 2022.04.02 |
| 1. Git 기본 개념 (0) | 2021.11.15 |
