1. 코드 리뷰란?
•
코드 리뷰는 동료가 작성한 코드를 점검하고 피드백을 교환하는 과정이다.
•
구성원 모두가 책임감을 가지고 새로 추가하거나 변경하는 코드를 검토하는 중요한 활동이다.
2. 코드 리뷰 기본 원칙
•
머지는 코드 리뷰를 마친 후에 한다.
•
혼자가 아닌 함께 하는 일이기에 코드 리뷰에 책임감을 가져야 한다.
•
최소 2명을 필수 리뷰어(assigner)로 팀은 리뷰어(reviewer)로 지정한다.
⇒ 최소 본인은 assigner에 포함시킨다.
•
2명의 필수 리뷰어가 PR을 승인해야 머지할 수 있다.
•
인프라 작업이나 릴리즈 PR은 리뷰를 생략할 수 있음, 단 review skip 라벨을 붙여, 리뷰 시간에 일괄 검토한다.
⇒ 이 리뷰 시간이란 팀별로 정한 특정 타임인 듯하다.
•
PR을 받았다면 하루 안에 답변을 하고, 답변이 없다면 재촉한다.
•
리뷰하기에 양이 많다면 오프라인 리뷰를 요청한다.
•
특별히 주의가 필요한 리뷰 포인트는 코멘트를 작성한다.
•
자신의 취향을 강요하기보단 사실과 데이터를 가지고 의견을 남겨 주어야 한다.
3. 코드 리뷰를 요청할 때, 주의할 점
•
코드 리뷰는 풀 리퀘스트를 만드는 것부터 시작한다.
•
다음과 같은 규칙을 잘 따르는 풀 리퀘스트는 리뷰어가 더 정확하고 신속한 리뷰를 할 수 있도록 돕는다.
◦
변경한 내용에 대한 충분한 정보를 제공하기
▪
PR의 목적을 잘 전달하기 위해서는 충분한 정보를 동료에게 전달해야 한다.
▪
코드 리뷰를 하는 동료는 내가 아는 것들을 모른다는 것을 가정하고 작성해야 한다.
•
커밋 메시지 충실하게 작성하기
◦
커밋 메시지의 제목만 봐도 어떤 작업을 했는지 유추할 수 있어야 한다.
◦
제목은 글자수 제한이 있기 때문에 어떤 작업을 했는지 설명하기가 어려울 수 있다. 이럴 때 제목에 간략히 작업 내용을 요약해서 적고 상세 내용을 본문에 작성하자.
•
본문을 충실하게 작성하기
◦
본문에도 PR을 작성한 계기, 수정 방향, 관련 이슈 등을 충실하게 작성해야 한다.
◦
작은 PR 만들기
▪
PR을 작게.. 만들어 보아요
•
왜 작은 PR이어야 할까?
◦
변경한 코드의 양이 적을수록 리뷰를 하기가 더 쉽다.
◦
변경한 코드의 양이 적을수록 버그가 있을 확률이 더 낮다.
◦
동료가 더 짧은 시간동안에 더 집중해서 리뷰를 할 수 있다.
◦
코드 리뷰에서 받은 피드백을 적용하기가 수월하다.
•
작은 PR의 조건
◦
하나의 PR에는 하나의 작업만 담겨 있어야 함, 하나의 PR에 여러 작업이 포함되면 리뷰를 하기가 어려워진다.
◦
주석, 커밋, PR 본문 등 리뷰를 하는 데에 필요한 모든 정보를 충실하게 제공해야 한다.
◦
새로운 함수나 API를 추가할 때에는 해당 API 또는 함수를 사용하는 코드도 PR에 포함한다.
4. 코드 리뷰를 해줄 때, 주의할 점
1.
코드 리뷰를 할 때 보아야 할 것
•
설계
◦
사내 애플리케이션 설계 원칙과 일반적인 프로그래밍 설계 지침에 맞춰서 코드가 작성되어 있는지
•
비즈니스 로직을 몰라도 리뷰를 할 수 있는 사항들
◦
팀원 모두가 같은 도메인에서 작업하지 않기 때문에 도메인의 비즈니스 로직에 대해서는 리뷰가 어렵다.
◦
코드 그 자체를 리뷰할 때 중요하게 보아야할 부분에 대한 정보다.
유지보수성
재사용성
안정성
확장성
테스트
2.
리뷰중인 코드 보는 법
•
코드 리뷰는 다음과 같은 단계로 하자.
◦
전체 코드를 훑어보기
▪
코드 전체에서 일어나는 변경을 가볍게 훑어보기
▪
의미가 없는 변경점이나 변경이 일어나서는 안 되는 곳이 있는지 확인
◦
PR의 주안점 확인
▪
리뷰를 받는 사람이 제시한 주요 변경사항을 확인
▪
주안점이 제시되어 있지 않다면 PR 작성자에게 설명을 요구
▪
구조를 변경한 PR은 빠르게 피드백을 전달하고 동료에게 전파
◦
놓치는 파일이 없도록 모든 부분을 꼼꼼하게
•
잘한 점이 있다면 칭찬!
•
리뷰를 해야할 코드의 양이 너무 많다면 오프라인으로 리뷰를 요청!
3. 언제 코드 리뷰를 하면 좋을까
•
코드 리뷰는 요청을 받는 즉시 하는 것이 원칙
•
PR을 받았으면 하루 안에는 답변을, 답변이 없다면 상대방을 재촉
•
자리에 앉아서 다른 업무를 시작하기 전에 코드 리뷰를 하는 습관을 들이자
◦
출근 직후
◦
점심 먹고 자리에 앉았을 때
◦
회의나 화장실에 갔다가 돌아와서 업무를 시작하기 전에
5. 커뮤니케이션 매너
•
코드 리뷰 시 의견을 작성할 때는 커뮤니케이션에 특히 신경을 써야한다.
•
대부분의 리뷰를 텍스트로 진행하므로 자칫 오해가 생기기 쉬우니 정확한 사실을 전달할 수 있도록 하자.
1. 동료의 능력을 존중하자
•
동료가 작성한 코드는 나와 다른 관점에서 작성하므로 리뷰를 하기 전에 작성한 의도를 물어보고 의도를 이해하자
2.
코드는 팀의 자산임을 기억하자
•
우리는 팀으로 협업하는데, 우리가 작성하는 모든 코드는 팀의 자산이다. 자신의 취향을 관철시키기보단 협업을 하기에 좋은 코드를 찾자
3.
객관적인 자료를 제시하자
•
권장 사례를 설명한 문서나 공식 문서를 활용해서 의견에 근거를 제시하자
◦
좋지 않은 예
▪
이 함수는 이렇게 사용하면 안 됩니다. rendering 메소드를 이용하세요.
◦
좋은 예
▪
이 부분은 본래 함수의 의도랑 다르게 쓰인 것 같습니다.
▪
https://reactjs.org/docs/testing-recipes.html#rendering 이 문서에서 설명하는 rendering 메소드를 사용하는 것은 어떨까요?
4.
텍스트는 작성자의 의도를 읽이 어렵다.
•
텍스트는 딱딱하기 때문에 읽는 사람이 쉽게 오해할 수 있다.
•
평소에 본인이 사용하는 것보다 훨씬 부드러운 언어를 구사하자, 어렵다면 이모티콘이나 움짤을 담자.
◦
아쉬운 예
▪
변수 이름을 분명하게 정의하는 것이 좋다는 건 저도 알고 있습니다.
▪
다만 이 부분을 어떻게 바꿔야 할지 잘 모르겠습니다. 아이디어가 있다면 제시해주세요.
◦
좀 더 나은 예
▪
변수 이름을 분명하게 정의하는 것이 좋다는 데에는 저도 공감을 합니다.
▪
다만 이 부분을 어떻게 바꿔야 할지 좋은 아이디어가 떠오르지를 않네요 ㅠ-ㅠ. 좋은 생각이 있으신가요? :)
5.
상대를 비난하지 않도록 주의하자
•
비난보다는 제안을 먼저, 평상시 대화할때보다 조금 더 조심스럽게
◦
아쉬운 예
▪
왜 이렇게 작성을 하셨죠? 코드가 너무 복잡해져서 읽기가 어렵네요.
◦
좀 더 나은 예
▪
useEffect의 clean-up function을 사용하면 코드를 더 간결하게 만들 수 있을 것 같아요!
6.
정확하게 요구하자
•
질문이나 요청을 할 때는 요구하는 내용을 구체적으로, 모호한 질문은 모호한 답변을 받는다.
◦
아쉬운 예
▪
이 부분을 잘 모르겠습니다.
◦
좀 더 나은 예
▪
useMemo의 deps에 변수 하나가 빠져있는 것 같은데, 일부러 이렇게 하신 걸까요?
그 외
•
수용적인 시각과 비판적인 시각을 가져라
◦
무조건 너의 코드 리뷰가 옳다, 무조건 나의 코드가 맞다는 절대 안 된다.
◦
코드 리뷰에 대해 스스로 생각을 해보고 내 코드가 맞다면 합당한 근거를 코드 리뷰가 맞다면 그 리뷰에 대한 근거를 내걸로 만들자
•
코드 리뷰를 진행할 때는 하나의 기능만 올려라
◦
너무 많은 기능을 코드 리뷰 요청하면 읽어야하는 코드의 길이도 길어지므로 좋지 않다.
◦
테스트를 진행하고 올려라, 진짜 혼나기 싫으면!
