코드 작성자와 리뷰어로써 올바른 자세.
코드 리뷰를 하다보면, 코드 스타일에 대한 이야기를 많이 하기도 한다. 변수 할당 순서나 네이밍, 줄바꿈과 들여쓰기 등. 팀이 과도기적 단계에 있다면 이러한 이야기들로 인해 리뷰가 지연되곤 한다. 그러다 보면 내 리뷰가 비효율 적인 것은 아닌지, 너무 사소한 내용으로 리뷰를 하는 것은 아닌지 의구심이 든다. 이런 상황이 계속되면 마음이 지치고, 코드 리뷰에 대한 부정적인 느낌이 스며든다.
그러나 이런 죄악감은 덜어도 되겠다.
2021 공개SW 페스티벌 기조강연 1 "리눅스 Guru를 만나다.- Greg Kroah-Hartman" - 14:02
2021 한국 공개SW 페스티벌에 Greg Kroah-Hartman이 기조강연 했다.
그는 리눅스 커널 개발자인데, 리눅스 패치에 대한 리뷰를 많이 요청 받는다.
다음은 그의 인터뷰 중 코드 스타일에 대한 일부다.
Q. 코드 리뷰어로서 당신이 확인하려 하는 가장 중요한 점은 무엇인가요?
A. 기본적인 문제가 몇 가지 있는데 올바른 코딩 스타일을 따르느냐 입니다.
우리의 코딩 스타일이 완벽하거나 훌륭해서는 아닙니다.
그것은 여러분의 두뇌 때문인데요.
두뇌는 일치하는 부분들에서 어떤 패턴을 봅니다.
그래서 모든 코드를 항상 같은 포맷으로 넣으면 포맷이 사라지고 코드가 의미하는 바를 볼 수 있습니다.
그래서 그렇게 하는 목적은 여러분이 적합한 코딩 스타일을 갖추는 것입니다.
우리는 그것을 확인할 수 있는 도구를 가지고 있습니다. (코드를) 보내기 전에 이 툴에 맡기면 모든 작업이 정상적으로 수행될 것입니다.
(생략)
그런 다음, 적절한 형식을 따라서 만드세요. 코드에 주석을 엄청나게 잘 붙일 필요는 없다는 것을 명심하세요.
코드 자체를 이해하기 쉽고 읽기 쉽게 만들면 됩니다.
코드 스타일 규칙을 지켜서 일관적인 코드가 되면, 리뷰어는 중요한 로직에 집중할 수 있게된다. 매번 스타일에 대한 리뷰를 할 수 없으니 도구에 맡겨서 자동화하라고 한다.
사소한 것이라고 생각하지 말고, 적극적으로 하자. 그리고 도구를 이용해서 자동화해서 직접 리뷰하는 상황을 줄이자. 내 팀에서는 EditorConfig를 사용한다. 많은 에디터에서 지원하고, 코드 저장 시 자동 포매팅을 지원한다.
내 생각에 자동화가 중요하기 보다는, 스타일 정책의 코드화로 협업자간 합의를 기록하는 것이라고 생각한다.
.editorconfig 파일을 코드베이스에 포함하면서 일종의 증명서로써 동작하는 것이다.
구두로 협의만 한다면 잊어버리고, 반복되기 마련이다.
구글은 Critique라는 코드 리뷰 도구를 이용해서 리뷰 경험을 개선한다고 한다.
도구 뿐 아니라 가이드라인도 당연히 있는데, 눈여겨 볼만한 부분은 24시간 이내 코드 변경 사항 검토.
Critique는 ML 기반 제안을 통해서 생산성을 높여준다고 한다.
개인적으로 리뷰 요청을 받으면 최대한 빠르게 응답하려고 노력한다. 간단한 변경사항은 PR 메일 수신 후 확인하고 최대한 바로 승인한다. 빠른 피드백이 코드리뷰의 가장 중요한 덕목같다. 대부분 변경사항 반영이 리뷰로 인해서 며칠이상 지연된다면 건강하지 않는 문화로 자리잡은 것이다.
변경사항이 많다면, 리뷰를 지체하지 말고 중요도에 따라 먼저 반영하는 것도 좋은 방법 같다. 기능 추가라면 배포되더라도 사용하지 않으면 되니 좀 더 안전하므로 반영 리스크가 적다. 요청자도 개발 환경에서 확인할테고, 스테이징환경이 있다면 시험해볼 수 있도록 빠르게 확인할 수 있는 프로세스를 만드는게 좋겠다.
사실 작업량이 많을수록 리뷰 단계에서 문제점을 찾기는 어려워진다.
김박사넷에 올라온 다음 글은, 리뷰어가 지적하지 않은 부분까지 대폭 수정해서 걱정이라는 내용이다.
https://phdkim.net/board/free/58719
실험 내용을 더 추가하고 논문의 대부분을 다시 쓰게되었고, 리뷰어가 더 명확하게 정의하라고 코멘트한 부분이 내용 수정하면서 아예 사라졌다고.
댓글은 좋지 않은 인상을 줄 수 있다는 반응이다.
댓글 내용이 코드 리뷰하면서 겪었던 경험과 비슷해서 공감된다.
새로운 파일이나 함수가 새 커밋에 포함되면 다시 해석해야 하고, 코드 작성자의 시점으로 돌아가 하나하나 봐야 한다.
코드 작성자는 직접 수정하면서 내용을 이해했겠지만, 리뷰어는 변경된 지점과 아닌 점을 파악해야 한다.
이럴때 이전 코드와 같다고 생각했지만, 사실은 수정된 코드였다면 더욱 문제다.
놓친 상태로 병합되거나, 다른 지점에서 나비 효과를 모른채 리뷰하고, 작성자는 답변하고 핑퐁하면서 피로가 더해진다.
IDE가 아닌 웹에서 변경 사항을 찾는 것은 더욱 어렵다.
이런 문제를 해결하기 위해서는, 코드 작성자의 배려가 가장 중요하다.
개인적으로 부정적으로 느끼는 순간은, 코드 작성자가 댓글 없이 변경 사항을 반영했을 때다.
변경 사항이 있다면 댓글로 알려주면 편하다.
간단한 수정이더라도 리뷰어가 댓글단 곳은 반드시 피드백 답변을 달고, 리뷰하지 않은 부분의 변경 사항에는 댓글로 알려주자.
그래야 변경 사항을 반영해서 outdated comment가 되었는지 아닌지 알고 리뷰어가 다시 확인할 수 있고,
리뷰하지 않은 지점을 리뷰어가 놓치지 않는다.
리뷰어 입장에서는 저장소 서비스의 기능을 잘 사용하는 수 밖에 없는 것 같다.
bitbucket은 2023년 10월이
되어서야 Viewed 기능을 추가했는데(실화?), 이 기능을 사용하면 변경 사항을 업데이트하면 Viewed 표시가 사라진다.
그래서 리뷰어가 재수정 사항을 확인할 수 있다.
그리고 또 bitbucket은 2024년 6월이 되어서야 PR의 커밋 히스토리를 보여주는 기능을 추가했는데(두 기능 모두 GitHub는 한참전에 제공했다.), 이 기능을 사용하면 변경 사항 간 diff를 볼 수 있다. 마지막 리뷰 지점을 잘 기억한다면, 변경 사항간의 diff를 보는 편이 편리할 때도 있다.
리뷰 요청자로써 어떻게 하면 상대가 편하게 리뷰할 수 있을지 고민해야 한다. 그냥 코드를 던져 놓는 것은 상대에게 좋지 않은 인상을 줄 수 밖에 없다. 변경 사항이 지저분해서 미안하다는 언급만 줘도 좀 더 너그러워지는 거 같다.