그동안 또 블로그 포스팅이 뜸했다...
메모하고 정리한 내용은 많은데, 보통 나만 알아보기 편하게 적어서 최근 프로젝트로 바빴는데 이걸 기존 포스팅 처럼 블로그에 올릴 수 있는 문체로 바꾸고 다듬으려니 엄두가 나지 않더라ㅋㅋㅋ
그래서 이 문제를 다시 차차 극복하기 위해 '우선 가공되지 않은 글일지라도 먼저 올리고 차차 수정해나가는 식으로 라도 하는게 낫지 않을까'라는 생각이 들어 앞으로는 원본 날 메모에서 약간 소스만 친 1차 가공 내용도 올려보고자 한다.
그 첫번째는 9월 1일 참석한 '코드 품질 향상을 위한 Code Review' 세미나의 정리 내용이다.
꼭 필요한 과정. 하지만 처음 도입하는 과정이라면 굉장히 어렵다…
코드 리뷰를 하는 리뷰어 입장과 받는 입장을 모두 알아보겠다
코드 리뷰가 개발 과정의 병목이라는 주장
“리뷰 하나씩 다 보고 있으면 티켓 처리가 느려진다.”
“지금은 과하고, 나중에 문제 있을 때 수정하자.”
코드 외적인 요인으으로 유야무야 되버리는 리뷰들
“혹시 이걸 지적하면 상대가 마음 상하지 않을까?”
“나보다 경력자인데 내가 리뷰를 하는게 맞을까? 이상한 걸 짚었다고 생각하지 않을까?”
“나 말고도 다른 사람들이 봐주겠지…”
리뷰 안에 상대방에 대한 비난이나 공격이 포함되는 경우
제발 꼽 주는 방식으로 말하지 말자. 이렇게 되면 상대는 당연히 방어적이되고 반발이 나올 수 밖에 없다.
A : “습관적으로 이렇게 짜시던데, 옳지 않은 것 같아요.”
B : ”그건 상황에 따라 다른거 아닌가요? 취향 차이의 문제이지 옳고 그름의 문제는 아닌 것 같아요.”
리뷰받을 준비를 잘 하는 것이 리뷰 자체보다 더 중요
⇒ 코드 리뷰의 부담은 줄이고, 효율성은 높이고
깃을 관리하는 방법을 조직적으로 약속하고 관리
어떤 코드가 어디에 있을 것인지 직관적으로 알 수 있게 한다.
리뷰어가 리뷰를 시작하기 전에 Context를 빠르게 이해하고 준비하도록 돕는다.
팀 내 Branch 관리 전략 준수
Commit Convention
TYPE: SUBJECT
[BODY]
[FOOTER]
리뷰어의 시간은 소중하다. 당연하게 여기지 말자.
CI 파이프라인 통과
개인의 코드가 인정받기 위한 최소 조건이자, 리뷰어가 굳이 보지 않아도 될 당연한 문제들을 없애주는 역할
PR의 크기를 조절하자
File Changed가 너무 많으면 리뷰를 보는 사람이 너무 피곤함
프로젝트 다 끝나고 코드를 한번에 올리는 문제
충분히 고민할 수 있는 문제도 대충 넘기게 됨
적당한 크기의 PR을 세팅하고 꼼꼼하게 리뷰 받자!
Self-review
리뷰 보내기 전에 내가 먼저 리뷰하자
코드를 작성할 때 고민했던 다른 대안, 내가 생각하는 문제점 등을 미리 코멘트로 달아 전달하자.
고민을 먼저 제시하여 더욱 효율적이고 풍부한 리뷰 가능
“코드만” 리뷰하는 것이 아니다.
코드 리뷰의 진정한 가치를 뜰어올리는 3가지 제안
풀고자 하는 이슈를 잘 해결했는지?
내 지식은 공유, 책임은 서로 나눈다.
Request Change
를 두려워하면 안된다.
사람이 아닌 코드와 현상을 비판한다는 합의를 전재한다.
지적 사항이 없을 때도 찾아서 쓰려고 하지는 말자
서로 존중하고 칭찬하는 문화를 유지하자
나 혼자 해서는 안되고, 팀 전체가 그에 맞게 이해하고 움직여야만 잘 할 수 있다.
그렇기에 서로 다른 팀은 서로 다른 문화를 지닌다.
우리 팀에 맞는 방법을 먼저 찾아서 제안해보자
코드 리뷰를 위한 문서 정리 예시
만약 코드 리뷰를 할 수 있는 팀원이 없는 상황이라면
셀프 리뷰를 생활화 하고
내 로컬에 CI 파이프라인을 구축해서 돌려보자.
혼자라도 문화를 확립해보자. 이런 문화를 만들어 나가다 팀원이 합류하면 같이 이어나가면 되고, 만약 팀원 합류가 안되더라도 내 이력서에 한 줄 추가할 내용이 되지 않겠는가?