국경넘은 코드리뷰 Pull Request ( PR )

211119 코드리뷰 등 개발자 소통에 관한 세미나

📒  원격 코드리뷰 : 작성자와 리뷰어

⚠️N사를 거쳐서 글로벌 기업에서 재직중인 배영 개발자님⚠️
⚠️실제 업무에서 목격한 사례를 바탕으로 제작하신 강의를 듣고 정리합니다.⚠️
⚠️그 중 핵심인 원격 코드리뷰 : 작성자와 리뷰어, 네번제 세션을 따로 정리해보았어요⚠️

 

코드 리뷰

- 두 시각에서 살펴보기
- 작성자 vs. 리뷰어 
+ 저장소 CI/CD 파이프라인
입장 불문 공통 키워드 : 배려

👩‍🏫 작성자

= PR길이가 가장 중요하다
- 짧은 경우 문제는 거의 없다
> 베스트 : 한 줄 변경

 

출처 : https://github.com/hammerjs/hammer.js/pull/982

📔 길이가 길 경우 중요한코드에 적절한 코멘트 달기

     * 커밋 링크 공유 기능 활용하기
        ✍ "### 커밋에 이 내용을 포함했으니 참고 부탁드려요"
        [참고] Github Autolinked references 

 

Commit SHAs

이렇게

📔 내가 작업한 내용 소개는 어떻게 해야할까?

📔 PR 템플릿 잘 채우기

✍"여백이 부족하여 적지 않겠다"하면 안됨., 다른 사람들이 내 PR을 봤을 때 페르마의 정리를 본 수학자의 마음이 들지 않게

📔 여러 템플릿 사례 참고하여 나의 팀에 맞추기

Configuring issue templates for your repository

stevemao / github-issue-templates

 

📔 딱히 템플릿 마련 계획이 없다면, 관련 이슈 번호만 간단히 링크해서 이슈와 PR관리 잘해주기

- 장점 : 이슈 내용 정리가 잘 된 경우, PR본문을 또 적을 필요가 없다.
[참고] Github Autolinked references 

Fixes #<이슈번호>

출처

✍ 이슈내용이 미리미리 정리가 잘 되어야한다.

 

📔 미리미리 Draft PR을 통해 진행현황 공유하기 

Draft PR이 올라오기전에는 어떤 단계인지 모른다. 현황 공유하는 용도로 사용.

'완벽히 개발하고 공유해야지' 쉽지 않다.

완벽주의 가지고 있음. 로컬에서 다 하고 올린다고 한다. 하지만 어차피 완벽히 개발할 수 없으므로, 맘편하게 그냥 얼른 리뷰를 받아서 차근차근 개선해나가는 편이 낫다. 서로에게 시간도 절약되는 방법

draft:

wip:

[참고] Github Draft pull requests

 

📔 코드리뷰를 받고 싶다면? 

- 먼저 가서 리뷰 해주기    : 다른 PR이 먼저 올라와있는데 코멘트가 없다면 먼저 리뷰 시도를 해본다.
- 먼저 주위 사람에게 요청하기   : 적당한 리뷰어가 누군지 모를 경우 먼저 행동해야한다. 나는 했다면 직접 요청을 해본다. '직접 해주실래요?~' 등 몇 번 주고받다보면 품앗이가 진행됨

 

 

 

👩‍🏫 리뷰어

📔 좋은 질문 하기

-  formatting같은 질문 계속 나오면 좋은 신호는 아니다.
✍ Git hooks, 혹은 저장소 CI/CD 파이프라인이 해결할 수 있는일인데 계속 질문하고 있다면 손을 떼고 개발 플로우를 점검하기
[참고]  훅으로 Git에 훅 들어가기   
[참고] GitHub Actions

출처 : https://lgtm.com/

✍LGTM 커밋이 이루어질때마다 ... 얘가 댓글로 달아준다. PR이 머지되면 다음 부분이 고쳐진다고 알려주고, 분석해주고 있다.

출처

 

- '나는 이 댓글에 대해 얼만큼 책임질 수 있는가?'
- 받는 사람의 작업 피로도를 고려해주기
- "이거 꼭 지금 안해도 되니까~"라고 운을 띄워주기

✍ 이 PR 무리하게 질문을 많이하고있는 건 아닌지 적절한선에서 마무리를 짓는 것도 필요하다 아니면 질문마니할 것이면 시간분배를 많이 해서 막바지에 몰아치게하지않도록! 시간이 많이 있는건 프로젝트 중간 가끔밖에 없다. 비판적인 사고가 중요하다고 하는데 저는 바쁜 상황이라면, 그런 비팑거인 사고도 상황에 따라 살짝만 접고 들어가는 자세도 필요하다

 

I am fine to create a separate ticket as well.

✍ 버그 발생했는데, 따로 티켓 만들어서 나중에 진행하자 등 PR작성자의 부담을 덜어주는 배려!

 

📔 말로만 하지 말고 코드로 말해요!

- 원하는 수정 방향이 확고할 때는 수정 제안 기능
- 혹은 상대방의 PR을 바탕으로 시연용 쉬운 PR 만들어 의견 피력하기
[참고] Incorporating feedback in your pull request

✍ 딱히 코드로 개선할 수 있는 답이 없는데 그냥 비판적인사고로 딴지거는 것은 피해야한다.

✍ 수정하고 싶은 코드 라인 선택하면 된다.  내 PR도 에디터 열고 하기 귀찮을때 GITHUB에서 수정하기도 한다.

동료 PR 하려고 라이브러리 문서보는데,,,,,, 사용법이 문서와 동료가 한 부분이 다르다. 이왕이면 문서를 따르는게 좋다? 코드로 직접 보여주면 좋겠어서 제안용 PR을 만든 부분

<redesign> → 내 피알 브랜치이름은 <i18n-suggestion>으로 붙힘. 동료에게 마음에 들면 merge하고 마음에 들지않으면 참고라도 하면 좋겠어 하고 올렸다고 이야기함. ok하고 내꺼에 merge한다.

 

📒 정리

📔 소프트 스킬 

- 문화의 차이를 넘어서 만국 공통 중요
 출신 국가는 한 배경일뿐, 일잘러들은 결국 관계없는 공통점이 있지 않을까?
 글로벌 팀 구성이어도 문화 차이는 한 벽 LAYER에 불과하고 벗기면 만국 공통

✍ 내 성향.. 파악하고 나랑 다른 사람 이해해보려고 노력하는 자세 필요하다

📔 코드리뷰는 개발 업무 사이클의 아주 일부분

- 먼저 업무 단계들 ( 일정 수립, 리뷰, 회고 등)이 하나의 파이프라인으로 잘 정립돼야 코드리뷰가 의미있다.
- 그렇지 않다면 굳이 시간 들여서 개발은 왜 할까요?

📔 코드리뷰가 헛되지 않도록 먼저 확인해야 하는 것들

- 업무 흐름이 잘 만들어져 있나

- 내가 만드는 기능이 정말 제품에 가치를 더하는가

📔 나의 코드를 읽는(보는) 주체

- '저장소 CI 파이프라인 + 감정을 가진 사람'이라는 것 기억하기

 

✍ 초년생때 개발자 회이하는 거 싫어한다면서요? 하고 편견-> 쓸데없는 회의 싫어한다지만 필요한 회의는 마다할 사람이 없다. 체력이 좋아야 좋은 토론을 할 수 있다. 생각할 여유가 생긴다.

코드리뷰 정의

 

좋은 작성자와 좋은 리뷰어

📔 번역을 하면서 느낀 점

- 개발은 글쓰기와 비슷함
- 내 코드는 나의 것이 아니다
- 어떻게 보면 리뷰를 받는 순간부터가 진짜 과정일 수도

 

📔 상처 받지 말자!

- 비난과 비판을 구분하는 눈 기르기
- 비난은 무시, 비판은 겸허히

✍ 나는 누구의 피드백이든 받고 싶어서. 도움되는 이야기해주면 너무 감사할 것 같다. 어차피 내 코드는 내가 아닌걸!

 

🎈TIP🎈 입사했는데 소스 코드가 너무 막막하다면, 첫 페이지의 첫 번째 PR을 보기.

 

부록 : 자주 쓰는 영어 표현

📔  질문

Q1 : 코드리뷰 활발하지 않은 조직에서 리딩하는 법

활발하지않은 조직에서 리딩하는 법 : 내가 나서는 수밖엥 없다 누가해주길 바라다가는 1년 2년이 지난다.

제일 먼저 리딩할때, 팀원중에 나랑 FIT이 맞는 코드리뷰 짝꿍을 한명이라도 확보를 해야한다.

메일이 활발하게 주고받는다.! 그럼 들여댜보게되고 페이스메이커가 되어서, 참여도 끌어내는 힘이 된다. 모두 해를 종용하지말고 한명이라도 확보하면 좋다.

외국에서 코드리뷰할때, 코멘트 주는 부분... → 다르지않다 같은 개발일하는 사람들이니 , 가끔 물어보는 부분이 이게진짜 지금해야하는건지,,, 나중에 해도 되는건지 우선순위를 많이 따진다 한국보다는! 개발적으론 급한일인데 이번 계획한내용 아니자나 이번 스프린트 아니자나~ 하고 뒤로 미루는 경향이 있다 그럼 지금 계획한일을 먼저 하자 그런 것들

우선순위가 낮아 그럼 주목을 못받게 된다. 그런 점이 다른 점이다.

 

Q2 : 좋은 코멘트 노하우, 타이트한 스케줄에서 코드 품질을 깊이 생각 못한다 이런 프로젝트에서 지키는 원칙, 

• 다른 사람코드 잘 리뷰하는 법. 조은 코멘트 노하우, 나와 상대의 실력차를 파악해야한다. 내가 못하는데 비판적으로 사고해봤자, 좋은 말도 아닌 것 같고 그럼 그냥 학습의 자세로 배운다는 자세로 선생님에게 질문하듯 질문 달아보고 맞춰보려한다.
• 내가 경력이 많고 주니어면 - 알고있는 지식...을 ? 수정제안을 적극적으로 하는데, 내 방법일 수도 있으니 그렇기떄문에 학생의 자세... 를 가지는게 제일 좋다.
• 책이나 평소공부법 : UDA CITY 시간 되어서 수강하면서 알던내용 복습함. 업무에서 했던 내용이 가르치는 부분이랑 뭐가다른지 공부하면서 재미이썼다. 자바스크립트 테스트와 관련된 책 번역하면서 공부하고있다
• 잘 모르겠는 키워드 노트에 적어놓고 나중에 공부하는 것 ! 바로 시간내기가 힘들다면
• 시간없엉서 이때 하기로했잖아 하고 스프린트 플래닝할때 꼭 이야기하는편
• 다 따라 잡으려고 하지않는다