현재의 팀에서는 아직 PR 에 대한 문화나 규칙 등이 완전히 설립되지는 않았는데, Pull Request를 받거나 요청하면서, 코드 리뷰를 하다 보면 참 많은 고민 지점이 생기는 것 같다.
깊게 몰입해서 하면, 1시간 ~ 2시간은 금방이고 의견과 피드백을 작성하 기 위해 그때 그때 다른 레퍼런스를 보다 보면, 반나절에서 하루 종일 PR 만 봤던 적도 있던 것 같다. (물론 각잡고 학습하자느니 뭐니 혼자 계획하고 설치는 것 보다, 그 순간 리뷰를 위해 특정 부분을 빠르게 학습하는 것 또한 효율적이였던 것 같기도)
그러던 중 다음의 '아주 사적인 코드 리뷰 생각' 이라는 정말 좋은 아티클을 보게 되었고, 많은 공감을 하게 되었던 것 같다.
(본인이 주니어거나 코드 리뷰에 무언가 고민이 있다면 꼭 읽어보아도 좋을 것 같다)
이후 글들의 대주제는 위 기고문의 대주제와 일치하며, 본인이 읽으며 느낀 개인의 생각을 덧붙인 것입니다.
코드는 타이밍이다.
개요
- 타이밍이란 제품 기능 데드라인 + 리뷰를 기다리는 사람의 인내력 등을 의미
- 내가 만든 코드에 대한 리뷰가 한없이 늦어지거나, 그로 인해 다음 기능으로 넘어가지 못하고 정체 되어 있는 것에 대한 짜증 등
경험
- 실제로 본인이 맡았던 (급박한?) 기능 구현에 몰두 해있다 보니, PR 요청에 대한 확인이 우선순위에서 미뤄졌던 경우가 있었던 것 같다.
- '코드 리뷰를 시작했음'에 대한 표현?을 개인적으로는 눈동자 이모지(👀)로 표현하는데, 확인을 미루다 보니 (리뷰 시작 상태 x) 본의 아니게 동료의 PR요청을 무반응?으로 오래 있게 했었다.
- 나중에 생각 해보니, 본의 아니게 감정을 상하게 했을 수도 있다라고 생각도 들었구, 역으로 반대 상황으로 내가 작성한 코드에 대한 아무 반응 조차 없다면 많이 서운할지도.
결론
- 위 글에서는 본의든 본의가 아니든 이렇게 '타이밍을 놓친 코드' 가 되는 것에 대해 경계하고
- 리뷰어도 의식적으로 빠르게 확인하려 하고, 혹은 선 댓글로 "현재 잠깐 바빠서 확인을 못하고 있는데, 최대한 빠르게 리뷰 하도록 하겠습니다~" 등의 인지 하고 있음에 대한 액션을 남겨주는 것들을 강조하고 있다.
- 여튼 해당 글에서는 타이밍이 좋으면 (동료가 PR을 올렸는데, 내가 마침 기능이 다 끝남!) 어떤 부가적인 액션 없이 서로가 좋은 코드 리뷰경험이 되었을 것이다를 말하고 싶었던 것 같고, 그것이 현실적으로는 조금 이루기 어려울 수 있으니 좋은 코드 리뷰 경험을 위해, 리뷰어의 의식적인 빠른 리뷰 + 선댓글 등의 방법으로 보완하자 가 아닐 까 싶다.
완벽한 코드는 없고, 우리에게 시간은 많다.
개요
- 요구사항 대로 동작하는 코드가 있지만 리뷰어(나)가 더 나은 (or 선호하는, 괜찮은) 방법에 대해 알고 있다.
- 리뷰어는 "아 꼭 고쳐야 하는 것은 아닌데.. 주저리주저리" 등의 말로, 리뷰를 남긴다
- 리뷰 의견 + approve 를 남기지만, 이번에 리뷰 내용을 적용할지, 말지는 전적으로 작업자의 선택을 따른다.
경험
- 리뷰어로써 코드를 살펴보던 중, 요구사항을 구현하기 위해 새로운 c라는 함수가 탄생하였음을 발견하였다.
- 하지만 기존에 만들어둔 a, b라는 함수가 있었고, 리뷰어인 나는 이 두 함수를 조금 더 확장 하거나 잘 활용 하면 재사용성을 높여 구현할 수 있지 않을까? 라는 생각에 리뷰를 남기려 했는데, c라는 함수 자체도 충분히 잘 쓰면 재사용성이 높아 보였다.
- 그래서 결론적으로는 "c와 비슷한 역할을 하는 a, b 라는 함수도 있습니다~" 의 정보 전달 느낌의 리뷰만 남기고, 넘어갔다.
결론
- 사실 최종 a, b, c의 함수를 공존시키게 되면서 굉장한 찝찝함이 남았었는데,
- 그렇다고 a, b로 바꾸는 것을 요청하자니, c 보다 a,b 가 낫다는 것에 대해 공감을 얻고, 동료를 납득 시킬만한 근거도 부족하다고 느꼈던 것 같다.
- 그런 부분에 있어, 위 글이 나름의 '위로'를 해주었던 것 같다. 나는 항상 좋은 코드, 완벽한 코드 만을 남기며 가려 했지만, 사실상 의도한 대로도 동작 잘 되고, 이번 리뷰에서 고쳐져야 하는게 아니라면 바꾸지 않아도 된다고. 그 코드를 오랫동안 다 같이 물고 뜯을 것이니까 오히려 그런 고민을 계속 할 수 있다는 점에서도 괜찮은 것이라고 (정말 별로면 또 고치러 올 것이라는 것)
리뷰어의 시간은 내 시간이 아니다.
코드 리뷰는 요청자 입장에서 다른 사람(리뷰어)의 리소스를 사용하는 것이므로, 요청자는 할 수 있는 최선을 다한 코드인지, 어떤 테스트나, 생각이 어떠했는지 등의 의견을 꼼꼼히 정리해 놓자.
가끔은 TMI 남발
본 글의 위 주제는 나와 성향이 너무 비슷해서 ㅋㅋㅋ 많은 공감이 됬다. 근데 사실 이런 성향의 사람은 '가끔'이 아니로 '빈번하게' 일 확률이 높을 것 같은데 (개인생각)
맨 뒤에 '허허' 와 같은 더공유하고싶음+공유하며공부하니신남+부담보다는가볍게도움이되었으면좋겠음+이런것이은근뻘쭘함+겸손 에 느낌의 워딩은 필수 인 것 같기도
내 고민을 나눌 수 있는 믿음
개인적으로 가장 좋았던 파트였던 것 같다.
본문 중 글
...
결론
코드 리뷰를 하며 서로를 배려하고 존중하면서 작은 세세한 부분이나 특정 잘못 등에 얽혀있기 보다는, 앞으로 나아갈 수 있는 방향을 같이 찾고, 공감하고 그런 팀문화와 동료들과의 합을 얻는 것을 목표하는 것.
시작은 '개인'의 코드 지만, 궁극적으로는 '우리' 라는 주어 하에 같이 앞으로 쭉쭉 나아가는 것
이런 이상을 가지는 것이 너무 좋은 것 같다.
'소프트웨어 개발자 > 좋은 개발자 되기' 카테고리의 다른 글
| [테스트 코드]에 대한 가이드라인 및 항목 정리 (feat. Python) (2) | 2024.09.22 |
|---|