PR 리뷰어로써 필요한 판단력

갑자기 쓰고 싶어 두서없이 적는 글인 점을 이해해주시기 바랍니다.

 

---

 

회사에서 개발직무 수행시 깃과 깃허브를 많이 이용한다.
이런 버전관리 툴이 없으면 사실상 협업 업무는 불가하다고 보면 된다.

 

1. 각 팀원들이 Repository를 Pull받아 로컬환경에서 각자 맡은 부분를 개발한다.
2. 개발 완료 후, 기본적인 테스트로 코드상의 오류가 없는지 확인한다.
3. 작업이 담긴 브랜치에 대해 Pull Request를 생성한다.
4. 팀원들이 PR에 리뷰(피드백)을 남긴다.
5. 코드 주인이 리뷰를 확인하고 수정이 필요한 부분은 반영한다.
6. 모든 리뷰가 해결되면 PR을 승인한다.

 

많은 회사에서 대강 이런 식으로 협업이 진행되지 않을까 싶다. 적어도 내가 속한 팀은 이렇게 업무를 하고 있다.

4~5번이 팀원들과 커뮤니케이션이 이루어지는 구간이다.
리뷰어는 코드의 문제점이 있다고 판단되거나, 코드에 대해 궁금한 점이 있다면 댓글(코멘트)를 남긴다.

내가 이야기의 포커스를 잡으려는 부분은 코드 문제점에 대한 코멘트를 남길 때다.
이때 판단력이 필요하다. '이 코멘트를 남기는 게 맞는지'

 

나의 판단 기준은 현재 대략 3가지가 있다.

 

1. 내 의견이 절대적으로 옳은가?

사람마다의 생각은 다르다. 내가 코드를 작성하는 방식과 남이 코드를 작성하는 방식도 당연히 다르다.

어떠한 상황에서 A라는 함수를 사용하는 것이 적절하다고 내가 느낄지라도, 다른 사람은 B라는 함수를 사용하는게 더 적절하다고 생각할 수 있다.

물론 내가 제시하는 코드가 효율성이 더 높다면 코멘트를 하는 것이 맞다.

그러나 두 코드의 성능이 비슷하다면, 내 의견을 코멘트하기 전에 작성자의 입장도 생각해보는 것이 좋다.

혹은 그럴 필요도 없다. 문제가 있는 코드가 아니니까. '이 분의 코딩 스타일은 이러하구나!' 하고 생각하는 것으로도 충분하다.

여기서 내가 사용하는 방식을 제안할 수야 있겠지만, 어쩌면 협업중인 코드에 내 방식만 가져가고 싶다는 고집으로 보일지도 모르겠고.

결론은 내 의견이 옳다고만 생각해선 절대 안된다. 협업의 기본 자세다.

남의 코드를 보다보면 내가 몰랐던 방법, 더 나은 방법을 새로 알게 되는 경우가 많다.

 

2. 객관적인 시선에선 너무 사소한 내용인가?

내 눈엔 개선이 필요해 보이는 부분이, 다른 대부분의 사람들에겐 얼마나 중요해보일지 생각해야한다.

수정하나 안하나 로직 동작에는 변화가 없고, 당장 수정하지 않는다고 문제가 생기는 것도 아닌 부분들 말이다.

잠깐! 초보개발자에겐 이런 작은 피드백도 필요하므로 6개월 차 미만의 개발자에겐 사소한 내용도 코멘트하는 것이 도움이 된다는 것을 참고 부탁한다.

 

모두 각자의 맡은 바를 개발하느라 바쁘다. PR은 마구마구 생겨난다.

내 입장에선, '여길 이렇게 수정하면 더 완벽한 코드가 될 것 같아요.' 정도로 남긴 코멘트가, 코드 주인에겐 '바쁜 와중에 수정하기엔 너무 사소한 부분'으로 느껴질 수 있다. 심해지면 나를 '귀찮은 사람', '사소한걸로 트집잡는 사람'으로 오해할 수도 있다.

대표적인 예시로 변수/클래스/메서드명 개선, 들여쓰기 개선, description 주석 내용 수정 등이 있다.

어쩌면 코드 주인도 이미 의식하고 있을지도 모른다. 나중에 개선될 가능성이 있다고, 코드 주인에게 신뢰와 믿음을 갖자. 혹은 로직 동작에 영향이 없는 범위이므로 나중에 내가 직접 수정해도 되니, 조급하지 말자.

 

3. 정확한 내용인가?

어떠한 정보를 가져다가 해당 부분이 잘못되었다는 것을 코멘트할 땐, 먼저 그 내용이 정확한건지 확인해야 한다. 해당 내용이 확실한지 헷갈린다면 코멘트를 남기기 전에 반드시 정확성을 검증한다.

코드 리뷰는 코드 주인만 보는 게 아니라 팀원 모두가 볼 수 있어서, 잘못된 내용을 남겼다가는 여러 사람에게 혼란을 줄 수 있다.

 

내가 이 코드를 제대로 이해하고 코멘트를 하고 있는 건지도 확인해야 한다. 코드를 대강 훑어만 보고 이해하지 않은 채 코멘트를 하면, 뚱딴지같은 리뷰가 될 수 있다. 어찌보면 코드 주인에게 무례한 행동일 수 있다. 대충하면 안하느니만 못하다.

코드를 제대로 이해하려면 직접 브랜치를 checkout받아 에디터에서 코드를 읽어보는게 좋다. 에디터의 네비게이션 기능 덕에 코드를 훨씬 빠르게 이해할 수 있기 때문이다.

 

코드 수정 제안 코멘트라면 내가 제안한 코드로도 로직이 문제없이 동작하는지 반드시 확인해보자.

나는 그래서 변경사항이 많은 PR을 리뷰할때면 해당 브랜치를 checkout 받은 뒤, 로컬 환경에서 직접 코드를 수정해보고(컴파일 오류 확인), 빌드도 돌려본다(런타임 오류 확인).

종종 빌드조차 실패하는 경우가 있다. 아마도 코드 주인이 바빠서 빌드조차 돌려보지 못한 경우일테다. 그리고 에디터로 코드를 확인하면 깃허브에선 찾지 못할 컴파일 오류를 발견하기 쉽다.

---

 

나도 아직 많이 부족한 리뷰어기에 이러한 나만의 기준을 나름 세워본 것이다.

코드 리뷰에는 생각보다 훨씬 많은 시간과 집중력이 소요된다.

그래서 내가 정성을 쏟아 리뷰를 했는데, 코드 주인의 답변이 성의가 없다면 내심 속상한 마음이 든다.

리뷰 자체도 커뮤니케이션이다. 내가 코드 주인일때는 리뷰에 담긴 정성만큼 나도 보답한다는 마음으로 답변을 단다.

모두 행복한 개발자 생활하자!

끝.