상호 존중하는 PR 만들기

본 게시글은 주인공들의 이야기, 이한결님과의 인터뷰 내용을 참고하여 작성했습니다.
https://youtu.be/CQj797uQw1U?si=PmCScDRERUUNVmSI

Full Video

도입

최근 팀원에게 아래와 같은 코멘트를 받았습니다.

하나의 PR에 코드가 너무 많아요.
다음에는 조금 작은 단위로 PR을 만들어주세요.

이한결님과의 인터뷰에는 아래와 같은 답이 있었습니다.

• 가독성 좋은 PR을 만드는 방법
• 가독성 좋은 Commit을 만드는 방법

무엇이 상호 존중하는 PR인가?

무엇이 좋은 PR일까요? 예를 들면 "이거 바로 Approve해도 되겠는데?"라는 말이 나올만한 PR이 좋다고 할 수 있겠습니다.
좋은 PR을 글쓰기로 비유하면 PR은 문단, Commit은 문장이라고 생각해볼 수 있습니다. 가독성 좋은 글은 하나의 문단에는 하나의 주제, 하나의 문장에는 하나의 내용 만으로 구성됩니다. 글쓰기라고 생각하시면 아래 내용을 이해하기 편할 것입니다. 다시 말하면 문단(주제)이기에 Refactor PR과 Feature PR은 분리하는 것이 좋은 PR입니다.

커밋에 흐름 만들기

작업에 들어가기 전에 항상 체크포인트를 만들어야 합니다. 이 작업에 약 2000줄의 코드 변경이 필요하다고 가정했을 때 100줄 단위로 나누었을 때 어떤 흐름이 가장 안전하고 자연스러운지를 미리 설계하는 것이 중요합니다. 나뉜 커밋(작업)들 하나하나가 각 체크포인트라고 부를 수 있겠습니다.
팀원이 쌓인 커밋들을 봤을 때 곧바로 이해할 수 있도록 가독성 좋게 구성합니다.

하나의 커밋도 읽기 쉽게

한결님은 이를 약 400-500줄 정도로 유지하려고 하십니다. 융통성 있게 하면됩니다. 1000줄 이하라면 더 커지더라도 큰 문제는 없습니다.
하지만, 테스트코드는 필수적입니다. 한결님이 작성하신 500줄의 코드 변경은 아래와 같이 구성됩니다.

• 100줄(20%): 기능 변경
• 400줄(80%): (최대한 많은) 테스트 코드

이러면 외부 클래스/함수 의존성 때문에 테스트가 실패하지 않나요?

(영상에서는 간략하게 언급하고 지나갔지만) 기능없는 빈 메서드를 만들고, '이후 기능이 구현되었을 때 이러한 모습이겠지.' 를 생각하고 테스트를 작성합니다.

상호 존중하지 않는 PR은 Moloco 수석 개발자도 어려워한다.

1,000줄의 코드를 한결님에게 보낸다면 한결님은 다음과 같이 말씀하신다고 합니다.

나는 너의 코드를 보고 문제없다고 말할 자신이 없다..
너무 많은 Change를 한번에 넣었기 때문에.

Unit Test가 이미 많이 작성되어 있다면 이를 쪼개서 보내달라고 부탁합니다.

팀을 위한 좋은 습관

• 장주영: "상대의 시간을 존중하는 좋은 습관같다."
• 이한결: "그것도 맞지만, 이는 상호 존중이다. 내가 상대를 존중했을 때 이 존중이 나에게 돌아올 확률이 크다."

마치며

주인공들의 이야기는 학생 개발자로서 배워가기 좋은 채널이다. 누구나 잘하고 싶은 욕구가 있지만 경험없이 노력만으로는 잘하기 힘든 것들이 있다. 프로 개발자들에게 이러한 경험을 배워갈 수 있다는 것 자체가 축복받은 사회다.