인간처럼 코드 리뷰하는 방법 (1편)
원문은 Michael Lynch님이 에 게재했습니다. 이 블로그 구독하기
최근 코드 리뷰 모범 사례에 관한 글들을 읽고 있다. 그런데 이런 글들은 리뷰의 다른 요소는 거의 모두 제쳐두고 버그 찾기에만 집중한다. 발견한 문제를 건설적이고 전문적인 방식으로 전달하는 법? 중요하지 않다! 그냥 버그만 전부 찾아내면 나머지는 알아서 해결된다는 식이다.
그래서 문득 깨달았다. 이게 코드에는 통한다면 연애에는 왜 통하지 않겠는가? 그래서 개발자들의 연애를 돕기 위한 신간 전자책을 발표한다:
이 혁신적인 전자책은 파트너에게서 최대한 많은 결점을 찾아내는 검증된 기법을 가르쳐준다. 단, 이 전자책에서는 다음 내용을 다루지 않는다:
- 공감과 이해를 담아 파트너에게 문제를 전달하는 방법.
- 파트너가 자신의 약점을 개선하도록 돕는 방법.
코드 리뷰 관련 글을 읽어본 바로는, 연애에서 그런 부분은 너무나 당연해서 논의할 가치조차 없다고 한다.
이 전자책이 괜찮아 보이는가? 아마 “아니, 아니, 절대 아니!”라고 외쳤을 것이다.
그렇다면 우리는 왜 코드 리뷰에 대해서는 그런 식으로 이야기하는 걸까?
내가 읽은 글들은 모든 개발자가 로봇인 미래에서 온 것이라고밖에 생각할 수 없다. 그런 세상에서는 무심하게 던진 코드 비판도 동료들이 반갑게 맞이할 것이다. 그런 정보를 처리하는 것이 차가운 로봇 심장을 따뜻하게 해주니까.
나는 과감하게도 당신이 로봇이 아닌 인간 동료들과 함께하는 현재의 코드 리뷰를 개선하고 싶어 한다고 가정하려 한다. 더 과감하게는, 동료와의 좋은 관계 그 자체가 목적이며 결함당 비용을 최소화하기 위해 조정하는 변수 정도가 아니라고 가정하겠다. 이런 전제라면 당신의 리뷰 방식은 어떻게 달라질까?
이 글에서는 코드 리뷰를 기술적인 과정일 뿐만 아니라 사회적 과정으로도 다루는 기법을 이야기한다.
코드 리뷰란 무엇인가?
“코드 리뷰”라는 용어는 동료 어깨 너머로 코드를 슥 훑어보는 것부터 20명이 모여 한 줄 한 줄 뜯어보는 회의까지 다양한 활동을 가리킬 수 있다. 이 글에서는 코드 리뷰를 격식을 갖추고 문서화된 과정이지만, 대면 코드 인스펙션 회의를 여러 번 여는 것처럼 무거운 방식은 아닌 것으로 정의한다.
코드 리뷰의 참여자는 코드를 작성해 리뷰를 요청하는 저자와, 코드를 읽고 팀 코드베이스에 병합할 준비가 되었는지 판단하는 리뷰어다. 리뷰에는 여러 명의 리뷰어가 참여할 수 있지만, 여기서는 단순화를 위해 당신이 유일한 리뷰어라고 가정한다.
코드 리뷰가 시작되기 전에 저자는 체인지리스트를 만들어야 한다. 이는 저자가 팀 코드베이스에 병합하고자 하는 소스 코드 변경 사항의 묶음이다.
리뷰는 저자가 체인지리스트를 리뷰어에게 보내면 시작된다. 코드 리뷰는 라운드 단위로 진행된다. 한 라운드는 저자와 리뷰어 사이의 완전한 왕복 과정이다. 저자가 변경 사항을 보내면 리뷰어가 그에 대해 서면 피드백으로 응답한다. 모든 코드 리뷰는 한 번 이상의 라운드로 이루어진다.
리뷰는 리뷰어가 변경 사항을 승인하면 끝난다. 이를 흔히 LGTM, 즉 “looks good to me(좋아 보인다)”를 준다고 표현한다.
왜 어려울까?
프로그래머가 자신이 멋지다고 생각하는 체인지리스트를 보내왔는데, 당신이 그것이 왜 그렇지 않은지에 대한 긴 목록을 써서 보낸다면, 그 메시지를 전하는 일은 꽤나 민감하다.
그것이 내가 IT가 그립지 않은 이유 중 하나다. 프로그래머들은 정말 호감 가기 어려운 사람들이기 때문이다… 예를 들어 항공 분야에서는 자신의 실력을 크게 과대평가하는 사람들은 모두 죽는다.
-Philip Greenspun, ArsDigita 공동 창업자, Founders at Work에서 발췌
저자는 자신의 코드에 대한 비판을 자신이 무능한 프로그래머라는 뜻으로 받아들이기 쉽다. 코드 리뷰는 지식을 공유하고 정보에 기반한 엔지니어링 결정을 내릴 기회다. 하지만 저자가 논의를 개인적인 공격으로 받아들이면 그런 일은 일어날 수 없다.
이것만으로도 충분히 어려운데, 오해의 위험이 더 큰 글로 생각을 전달해야 하는 어려움까지 더해진다. 저자는 당신의 목소리 톤을 들을 수도, 몸짓을 볼 수도 없으므로 피드백을 더욱 신중하게 표현하는 것이 중요하다. 방어적인 상태에 있는 저자에게 “파일 핸들을 닫는 걸 잊으셨네요.” 같은 무해한 코멘트도 “파일 핸들 닫는 걸 잊다니 믿을 수가 없네! 당신은 정말 바보군요.”처럼 들릴 수 있다.
기법
- 지루한 일은 컴퓨터에 맡기기
- 스타일 논쟁은 스타일 가이드로 끝내기
- 즉시 리뷰 시작하기
- 큰 그림부터 시작해 세부로 내려가기
- 코드 예시는 아낌없이 제공하기
- 절대 “you”라고 말하지 않기
- 피드백은 명령이 아닌 요청으로 표현하기
- 코멘트는 의견이 아닌 원칙에 근거하기
지루한 일은 컴퓨터에 맡기기
회의와 이메일 같은 방해 요소들 사이에서 코드에 집중할 수 있는 시간은 부족하다. 정신적 체력은 더욱 부족하다. 동료의 코드를 읽는 일은 인지적으로 부담이 크고 높은 집중력을 요구한다. 컴퓨터가 할 수 있는 일, 특히 컴퓨터가 더 잘할 수 있는 일에 이런 자원을 낭비하지 말자.
공백 오류가 대표적인 예다. 사람이 들여쓰기 실수를 찾아 저자와 함께 고치는 데 드는 노력과, 자동 포매팅 도구를 쓰는 경우를 비교해 보자:
| 사람 리뷰어가 필요로 하는 노력 | 포매팅 도구로 필요로 하는 노력 |
|---|---|
| 없음! |
오른쪽이 비어 있는 이유는 저자가 “Save”를 누를 때마다 공백을 자동으로 정리해 주는 코드 에디터를 사용하기 때문이다. 최악의 경우에도 저자가 리뷰를 위해 코드를 보내면 지속적 통합 솔루션에서 공백이 잘못되었다고 알려준다. 리뷰어가 신경 쓸 필요도 없이 저자가 스스로 문제를 고친다.
코드 리뷰에서 자동화할 수 있는 기계적인 작업이 있는지 찾아보자. 흔한 예시는 다음과 같다:
| 작업 | 자동화 솔루션 |
|---|---|
| 코드가 빌드되는지 확인 | Travis나 CircleCI 같은 지속적 통합 솔루션. |
| 자동화 테스트 통과 여부 확인 | Travis나 CircleCI 같은 지속적 통합 솔루션. |
| 코드 공백이 팀 스타일에 맞는지 확인 | ClangFormat(C/C++ 포매터)이나 gofmt(Go 포매터) 같은 코드 포매터. |
| 사용하지 않는 import나 변수 식별 | pyflakes(Python 린터)나 JSLint(JavaScript 린터) 같은 코드 린터. |
자동화는 리뷰어로서 더 의미 있는 기여를 할 수 있게 돕는다. imports 순서나 소스 파일명 네이밍 규칙 같은 특정 부류의 문제를 신경 쓰지 않아도 되면, 기능적 오류나 가독성 약점 같은 더 흥미로운 문제에 집중할 수 있다.
자동화는 저자에게도 이득이다. 몇 시간이 걸릴 실수를 몇 초 만에 발견할 수 있게 해준다. 즉각적인 피드백 덕분에 아직 관련 맥락이 머릿속에 남아 있을 때 배우고 수정하기가 더 쉽고 비용도 적게 든다. 게다가 어리석은 실수에 대해 지적을 들어야 한다면, 당신에게서 듣는 것보다 컴퓨터에게서 듣는 편이 자존심 상할 일이 훨씬 적다.
팀과 협력해 이러한 자동 검사를 코드 리뷰 워크플로에 직접 통합하자(예: Git의 pre-commit hook이나 GitHub의 webhook). 리뷰 과정에서 저자가 이런 검사를 수동으로 실행해야 한다면 그 효과 대부분을 잃게 된다. 저자는 어쩔 수 없이 가끔 이를 잊어버리고, 결국 자동화가 처리해야 할 단순한 문제들을 당신이 계속 리뷰해야 하게 된다.
스타일 논쟁은 스타일 가이드로 끝내기
스타일에 대한 논쟁은 리뷰에서 시간 낭비다. 일관된 스타일은 분명 중요하지만, 코드 리뷰는 중괄호를 어디에 둘지 다투는 자리가 아니다. 리뷰에서 스타일 논쟁을 없애는 가장 좋은 방법은 스타일 가이드를 유지하는 것이다.
좋은 스타일 가이드는 네이밍 규칙이나 공백 규칙 같은 표면적인 요소뿐만 아니라, 해당 프로그래밍 언어의 기능을 어떻게 사용할지도 정의한다. 예를 들어 JavaScript와 Perl은 기능이 매우 풍부해서 같은 로직을 구현하는 방법이 여러 가지다. 스타일 가이드는 일을 처리하는 ‘유일한 정답’을 정의해, 팀 절반은 한 가지 언어 기능을 쓰고 나머지 절반은 전혀 다른 기능을 쓰는 상황을 막아준다.
스타일 가이드가 있으면 누구의 네이밍 규칙이 더 좋은지 저자와 논쟁하며 리뷰 라운드를 낭비할 필요가 없다. 그냥 스타일 가이드를 따르면 된다. 스타일 가이드에 특정 이슈에 대한 규칙이 명시되어 있지 않다면, 대체로 논쟁할 가치가 없다. 가이드에 없는 스타일 이슈를 마주했는데 논의할 만큼 중요하다면 팀과 함께 결론을 내자. 그리고 그 결정을 스타일 가이드에 기록해 다시는 같은 논의를 반복하지 않도록 하자.
선택지 1: 기존 스타일 가이드 채택하기
온라인에서 검색하면 바로 가져다 쓸 수 있는 공개된 스타일 가이드를 찾을 수 있다. Google의 스타일 가이드가 가장 잘 알려져 있지만, 맞지 않는다면 다른 가이드를 찾아도 된다. 기존 가이드를 채택하면 처음부터 만드는 데 드는 상당한 비용 없이 스타일 가이드의 이점을 그대로 누릴 수 있다.
단점은 각 조직이 자신의 특수한 필요에 맞춰 스타일 가이드를 최적화한다는 점이다. 예를 들어 Google의 스타일 가이드는 새로운 언어 기능 사용에 보수적이다. 가정용 라우터부터 최신 iPhone까지 모든 환경에서 동작해야 하는 방대한 코드베이스를 갖고 있기 때문이다. 단일 제품을 만드는 4명짜리 스타트업이라면 최첨단 언어 기능이나 확장 기능을 더 적극적으로 사용하는 쪽을 선택할 수도 있다.
선택지 2: 점진적으로 직접 스타일 가이드 만들기
기존 가이드를 채택하고 싶지 않다면 직접 만들 수도 있다. 코드 리뷰 중에 스타일 논쟁이 생길 때마다 팀 전체에 문제를 제기해 공식 규칙을 정하도록 하자. 합의에 도달하면 그 결정을 스타일 가이드에 명문화하자.
나는 팀 스타일 가이드를 소스 관리 하에 Markdown으로 유지하는 것을 선호한다(예: GitHub Pages). 이렇게 하면 스타일 가이드 변경 사항도 일반적인 리뷰 과정을 거치게 된다. 누군가 변경을 명시적으로 승인해야 하고, 팀원 모두가 우려를 제기할 기회를 갖는다. 위키나 Google Docs도 괜찮은 선택지다.
선택지 3: 혼합 접근법
선택지 1과 2를 결합해 기존 스타일 가이드를 기반으로 채택한 뒤, 이를 확장하거나 재정의하는 로컬 스타일 가이드를 유지할 수도 있다. 좋은 예가 Chromium C++ 스타일 가이드다. Google의 C++ 스타일 가이드를 기반으로 하면서 그 위에 자체적인 변경과 추가 사항을 덧붙인 형태다.
즉시 리뷰 시작하기
코드 리뷰를 최우선으로 다루자. 실제로 코드를 읽고 피드백을 줄 때는 시간을 들여도 되지만, 리뷰는 즉시 시작하자. 이상적으로는 몇 분 안에.
동료가 체인지리스트를 보냈다면, 당신의 리뷰가 끝날 때까지 다른 작업을 진행하지 못하고 막혀 있다는 뜻일 가능성이 크다. 이론상으로는 소스 관리 시스템을 이용해 저자가 브랜치를 만들어 작업을 계속한 뒤, 리뷰에서 나온 변경 사항을 새 브랜치에 forward-merge할 수 있다. 하지만 실제로 이를 효율적으로 할 수 있는 개발자는 네 명 정도에 불과하다. 나머지에게는 3-way diff를 풀어내는 데 너무 오래 걸려 리뷰를 기다리는 동안 이룬 진전이 상쇄될 수 있다.
리뷰를 즉시 시작하면 선순환이 만들어진다. 리뷰 처리 시간이 전적으로 저자 체인지리스트의 크기와 복잡도에 따라 결정되게 된다. 이는 저자가 작고 범위가 좁은 체인지리스트를 보내도록 유도한다. 그런 체인지리스트는 리뷰하기가 더 쉽고 부담이 적으므로 더 빨리 리뷰하게 되고, 선순환은 계속된다.
동료가 1,000줄의 코드 변경이 필요한 새 기능을 구현한다고 상상해 보자. 당신이 200줄짜리 체인지리스트를 약 2시간 안에 리뷰할 수 있다는 것을 안다면, 기능을 200줄씩 나눠 보내 하루 이틀 안에 전체 기능을 체크인할 수 있다. 하지만 크기에 상관없이 모든 코드 리뷰에 하루가 걸린다면, 그 기능을 체크인하는 데 일주일이 걸린다. 동료는 일주일을 그냥 앉아 기다리고 싶지 않으므로 500~600줄짜리 더 큰 코드 리뷰를 보내게 된다. 이런 리뷰는 검토 비용이 더 많이 들고 피드백의 질도 떨어진다. 200줄 변경보다 600줄 변경에서 맥락을 유지하기가 훨씬 어렵기 때문이다.
한 라운드 리뷰의 최대 처리 시간은 1영업일을 넘지 않아야 한다. 더 우선순위가 높은 문제로 하루 안에 리뷰 한 라운드를 마칠 수 없다면 동료에게 알리고 다른 사람에게 재할당할 기회를 주자. 한 달에 한 번 이상 리뷰를 거절해야 한다면, 팀이 온전한 개발 관행을 유지할 수 있도록 속도를 늦춰야 한다는 신호일 가능성이 크다.
큰 그림부터 시작해 세부로 내려가기
한 리뷰 라운드에서 코멘트를 많이 쓸수록 저자가 압도감을 느낄 위험이 커진다. 정확한 한계는 개발자마다 다르지만, 일반적으로 한 라운드에 20~50개 정도부터가 위험 구간이다.
저자가 코멘트 홍수에 빠질까 걱정된다면, 초반 라운드에서는 상위 수준의 피드백으로 제한하자. 클래스 인터페이스 재설계나 복잡한 함수 분할 같은 문제에 집중하자. 이런 문제가 해결된 뒤에 변수 네이밍이나 코드 주석의 명확성 같은 하위 수준 문제를 다루자.
저자가 상위 수준 피드백을 반영하고 나면 하위 수준 코멘트는 무의미해질 수 있다. 이를 다음 라운드로 미루면 신중하게 표현된 코멘트를 작성하는 적지 않은 수고를 덜 수 있고, 저자도 불필요한 코멘트를 처리하지 않아도 된다. 이 기법은 리뷰에서 집중하는 추상화 계층을 구분해, 당신과 저자가 체인지리스트를 명확하고 체계적으로 검토하도록 돕는다.
코드 예시는 아낌없이 제공하기
이상적인 세상이라면 코드 저자는 받는 모든 리뷰에 감사할 것이다. 배우는 기회이고 실수로부터 보호받을 수 있기 때문이다. 현실에서는 저자가 리뷰를 부정적으로 받아들이고 코멘트를 준 당신을 원망하게 만드는 외부 요인이 많다. 마감 압박에 시달리고 있어 즉각적인 형식적 승인 외에는 무엇이든 방해로 느껴질 수도 있다. 함께 일한 적이 많지 않아 당신의 피드백이 선의에서 비롯되었다고 신뢰하지 못할 수도 있다.
저자가 리뷰 과정을 긍정적으로 느끼게 만드는 좋은 방법은 리뷰 중에 선물을 줄 기회를 찾는 것이다. 그리고 모든 개발자가 받고 싶어 하는 선물은 무엇일까? 바로 코드 예시다.
당신이 제안하는 변경 사항 중 일부를 직접 코드로 작성해 저자의 부담을 덜어주면, 리뷰어로서 시간을 아낌없이 쓰고 있다는 것을 보여줄 수 있다.
예를 들어 Python의 리스트 컴프리헨션 기능에 익숙하지 않은 동료가 있다고 하자. 그 동료가 다음 코드가 포함된 리뷰를 보냈다고 하자:
urls = []
for path in paths:
url = 'https://'
url += domain
url += path
urls.append(url)“리스트 컴프리헨션으로 단순화할 수 있을까요?”라고 답하면 동료는 짜증이 날 것이다. 한 번도 써본 적 없는 것을 조사하는 데 20분을 써야 하기 때문이다.
다음과 같은 코멘트를 받으면 훨씬 기뻐할 것이다:
다음과 같이 리스트 컴프리헨션으로 단순화하는 것을 고려해 보세요:
urls = ['https://' + domain + path for path in paths]
이 기법은 한 줄짜리 예시에만 국한되지 않는다. 나는 종종 코드에서 직접 브랜치를 만들어 큰 함수를 나누거나 추가 엣지 케이스를 다루는 단위 테스트를 추가하는 등, 대규모 개념 증명을 저자에게 보여주기도 한다.
이 기법은 명확하고 논란의 여지가 없는 개선에만 사용하자. 위 리스트 컴프리헨션 예시에서 코드 줄 수를 83% 줄이는 것을 반대할 개발자는 거의 없다. 반면, 개인 취향에 따라 “더 낫다”고 여기는 변경(예: 스타일 변경)을 보여주기 위해 긴 예시를 작성하면, 코드 예시는 관대함이 아니라 강압적으로 보일 수 있다.
한 리뷰 라운드당 코드 예시는 두세 개로 제한하자. 저자의 체인지리스트 전체를 대신 작성하기 시작하면, 저자가 스스로 코드를 작성할 능력이 없다고 생각한다는 신호를 주게 된다.
절대 “you”라고 말하지 않기
이건 좀 이상하게 들릴 수도 있지만, 끝까지 들어보자. 코드 리뷰에서는 절대 “you”라는 단어를 쓰지 말자.
리뷰에서 내리는 결정은 누가 아이디어를 냈는지가 아니라 무엇이 코드를 더 좋게 만드는지에 기반해야 한다. 동료는 체인지리스트에 상당한 노력을 들였고, 자신이 한 일을 자랑스러워할 가능성이 크다. 자신의 작업에 대한 비판을 들었을 때 방어적이고 보호하려는 반응을 보이는 것은 자연스러운 일이다.
동료의 방어심을 자극할 위험을 최소화하도록 피드백을 표현하자. 당신이 비판하는 대상은 코드이지 사람이 아니라는 점을 분명히 하자. 저자가 코멘트에서 “you”를 보면 초점이 코드에서 자신에게로 옮겨간다. 그러면 비판을 개인적으로 받아들일 위험이 커진다.
다음과 같은 무해해 보이는 코멘트를 생각해 보자:
You misspelled ‘successfully.’
저자는 이 코멘트를 두 가지 전혀 다른 방식으로 해석할 수 있다:
- 해석 1: 야, 친구! You misspelled ‘successfully.’ 그래도 넌 똑똑하다고 생각해! 아마 그냥 오타겠지.
- 해석 2: You misspelled ‘successfully,’ dumbass.
“you”를 생략한 코멘트와 비교해 보자:
sucessfully -> successfully
후자는 단순한 수정일 뿐 저자에 대한 평가가 아니다.
다행히 피드백을 “you” 없이 다시 쓰는 것은 쉽다.
선택지 1: ‘you’를 ‘we’로 바꾸기
Can you rename this variable to something more descriptive, like
seconds_remaining?
는 다음과 같이 바뀐다:
Can we rename this variable to something more descriptive, like
seconds_remaining?
“we”는 코드에 대한 팀의 공동 책임을 강조한다. 저자가 다른 회사로 옮길 수도 있고 당신도 그럴 수 있지만, 이 코드를 소유한 팀은 어떤 형태로든 남는다. 명백히 저자가 직접 해야 할 일에 “we”라고 말하면 어색하게 들릴 수 있지만, 어색한 것이 비난조보다 낫다.
선택지 2: 문장에서 주어 생략하기
“you”를 피하는 또 다른 방법은 문장에서 주어를 생략하는 간결한 표현을 쓰는 것이다:
Suggest renaming to something more descriptive, like
seconds_remaining.
수동태를 써서 비슷한 효과를 낼 수도 있다. 나는 기술 문서에서 수동태를 극도로 기피하지만, “you”를 피하기 위한 방법으로는 유용할 수 있다:
This variable should be renamed to something more descriptive, like
seconds_remaining.
또 다른 방법은 “what about…”이나 “how about…”으로 시작하는 질문 형태로 표현하는 것이다:
What about renaming this variable to something more descriptive, like
seconds_remaining?
피드백은 명령이 아닌 요청으로 표현하기
코드 리뷰는 논의가 개인적인 논쟁으로 흐를 위험이 높기 때문에 평소보다 더 세심하고 배려 있는 소통이 필요하다. 리뷰어는 리뷰에서 더 공손해질 것이라 기대하겠지만, 이상하게도 나는 그 반대로 가는 경우를 많이 봤다. 보통 사람들은 동료에게 “스테이플러 좀 줘, 그리고 탄산음료 하나 가져와.”라고 말하지 않는다. 하지만 나는 “이 클래스를 별도 파일로 옮기세요.”처럼 비슷하게 강압적인 명령으로 피드백을 표현하는 리뷰어를 수없이 봤다.
피드백에서는 지나치다 싶을 정도로 부드럽게 표현하는 쪽을 택하자. 코멘트를 명령이 아닌 요청이나 제안으로 표현하자.
같은 코멘트를 두 가지 다른 방식으로 표현한 경우를 비교해 보자:
| 명령으로 표현한 피드백 | 요청으로 표현한 피드백 |
|---|---|
Move the Foo class to a separate file. | Can we move the Foo class to a separate file? |
사람들은 자신의 작업에 대해 통제권을 갖고 있다고 느끼고 싶어 한다. 저자에게 요청하는 방식은 그에게 자율성을 느끼게 해준다.
요청은 저자가 정중하게 반박하기도 더 쉽게 만든다. 저자 나름의 타당한 이유가 있을 수도 있다. 피드백을 명령으로 표현하면 저자의 반박은 불복종처럼 보인다. 요청이나 질문으로 표현하면 저자는 단순히 답하면 된다.
리뷰어가 첫 코멘트를 어떻게 표현하느냐에 따라 대화가 얼마나 대립적으로 보이는지 비교해 보자:
| 명령으로 표현한 피드백 (대립적) | 요청으로 표현한 피드백 (협력적) |
|---|---|
리뷰어: Move the Foo class to a separate file.저자: I don’t want to do that because then it’s far away from the Bar class. Clients will almost always use the two together. | 리뷰어: Can we move the Foo class to a separate file?저자: We could, but then it’s far away from the Bar class, and clients will generally use these two classes together. What do you think? |
코멘트를 명령 대신 요청으로 표현할 때 대화가 얼마나 더 주장을 뒷받침하려고 가상의 대화를 꾸며내는 문명화되는지 보이시나요?
코멘트는 의견이 아닌 원칙에 근거하기
저자에게 코멘트를 남길 때는 제안하는 변경 사항과 그 이유를 함께 설명하자. “이 클래스를 둘로 나누는 게 좋겠습니다.”라고 말하는 대신, “지금 이 클래스는 파일 다운로드와 파싱을 모두 담당하고 있습니다. 단일 책임 원칙에 따라 다운로더 클래스와 파싱 클래스로 나누는 게 좋겠습니다.”라고 말하는 편이 낫다.
코멘트를 원칙에 근거하면 논의가 건설적인 방향으로 흘러간다. “클래스의 공개 인터페이스를 최소화하기 위해 이 함수를 private으로 만드는 게 좋겠습니다.”처럼 구체적인 이유를 들면, 저자는 “아니요, 저는 제 방식이 좋습니다.”라고 단순히 답할 수 없다. 물론 답할 수는 있지만, 당신이 변경이 어떻게 목표를 달성하는지 보여줬는데 저자는 단지 선호를 말한 것이므로 어리석어 보일 것이다.
소프트웨어 개발은 예술이자 과학이다. 코드의 무엇이 잘못되었는지를 확립된 원칙으로 항상 명확히 설명할 수 있는 것은 아니다. 때로는 코드가 그냥 지저분하거나 직관적이지 않아서 이유를 짚어내기 어렵다. 이런 경우에는 설명할 수 있는 만큼 설명하되, 객관성을 유지하자. “제가 이해하기 어려웠습니다.”라고 말하는 것은 최소한 객관적인 진술이다. 반면 “이건 혼란스럽습니다.”는 가치 판단이며 모든 사람에게 해당하지 않을 수도 있다.
가능하면 링크 형태로 뒷받침 증거를 제공하자. 팀 스타일 가이드의 관련 섹션이 제공할 수 있는 가장 좋은 링크다. 언어 나 라이브러리 문서로 링크할 수도 있다. 추천을 많이 받은 StackOverflow 답변도 괜찮지만, 공신력 있는 문서에서 멀어질수록 근거는 약해진다.
2편
이 글이 마음에 들었다면, 리뷰를 불쾌한 충돌 없이 성공적으로 마무리하는 데 초점을 맞춘 이 글의 후반부를 확인해 보자. 여기에는 다음을 위한 기법이 포함된다:
- 지나치게 큰 코드 리뷰 다루기,
- 칭찬할 기회 알아보기,
- 리뷰 범위 존중하기,
- 교착 상태 완화하기.
인간처럼 코드 리뷰하는 방법 (2편)
편집: Samantha Mason. 일러스트: Loraine Yow. 이 글의 초안에 귀중한 피드백을 제공해 준 @global4g에게 감사드립니다.
댓글
로그인하고 댓글 남기기