왜 코드 리뷰를 해야 할까?
우리는 개발 조직의 성능(생산성)이 매우 중요한 시대에 살고 있다.
요즘 꼭 IT 회사가 아니더라도 자영업을 하려고 해도 IT는 떼래야 뗄 수 없고 개발자는 반드시 필요하다.
하지만 어떠한 프로그램을 개발할 때 개발자 수가 많아진다고 해서 속도 즉 생산성이 빨라지는 것이 아니다.
[출처: 클린코드 - 링크 아래 참고란 첨부]
출시 초기에는 기술 부채가 전혀 없다. 하지만 시간이 흐르고 릴리스가 계속될수록 기술 부채는 쌓이기 마련이다.
프로젝트가 커질수록 개발자는 생산적인 새로운 기능에 대해 고민하는 것이 아니라, 기존 코드를 파악 아도 어떻게 필요한 기능을 잘 붙일 수 있을지 고민하는 시간이 많아진다.
[출처: 클린코드 강의 - 링크 아래 참고란 첨부]
일정 시간까지는 설계 품질이 나쁘더라도 개발 속도가 빠를 수 있다. 하지만 일정 시간이 흐른 이후에는 좋지 않은 설계는 생산성이 빠르게 수렴되는것을 볼 수 있다.
즉, 일정이 급하다는 이유로 설계를 희생시킬 수 있으니 프로젝트가 점점 커지고 장기적으로 봤을 때 이는 극명한 차이를 드러낸다.
SW 공학의 특성
공학 = 설계 + 빌드
- 설계는 예측하기 힘들고 급여가 비싼 창의적인 사람들이 필요하다.
- 빌드는 예측하기가 상대적으로 쉽다.
빌드 비용은 비싸고 설계와 빌드에서 설계가 차지하는 비중은 90%이다. 반면 유지 보수 비용은 상대적으로 저렴하다.
빌드 할 수 있는 어떠한 문서가 제대로 되어있다면 어느 누구라도 그 문서대로 빌드 한다면 동일한 결과물을 보장해야 한다.
클린 코드의 중요성
- 개발자는 보통 신규 코드를 작성하는 일보다 다른 사람의 코드를 읽는 경우가 더 많다.
- 한번 작성된 코드는 본인 또는 누군가에 의해 최소 10번 이상 읽힌다. 즉 작성하는 시간보다 읽히는데 노력이 10배 더 소요된다.
- 내가 작성한 코드도 시간이 지나면 읽기 어려운 경우가 많다. 다른 사람이 작성한 코드는 더욱 읽기 어려울 것이다.
코드 리뷰란 ?
그렇다면 코드 리뷰란 무엇일까?
- 개발자가 당장 할 수 있는 공유 활동이다
- code를 사용한 SNS 활동이다.
- 배움을 주고 받으며 지속 가능한 SW 개발자가 될 수 있는 방법이다.
코드 리뷰의 목적
코드 리뷰는 어떤걸 목적으로 할까?
- 품질 문제 검수 (버그, 장애 등)
- 더 나은 코드 품질 (아키텍처 개선을 위한 코드 개선)
- 학습 및 지식 전달
- 코드 해결책 등과 관련된 공유에 기여한다.
- 공유 (주고받는 학습)를 통해 역량 증대 및 성장
- 리뷰어들 또한 리뷰 과정에서 지식을 얻을 수 있다. (하드 스킬, 소프트스킬)
- 동기부여
- 잘하는 사람을 보며 더 잘하고 싶다는 생각이 든다.
- 상호 책임감 증대
- 집단 코드 오너십 및 결속 증대
- 내가 만든 코드를 나 혼자 배포하게 되면 업무 공유도 어렵고 장애에 대한 책임도 혼자 져야 함
- 내가 하고 있는 일에 대한 관심
- 팀에서 일어나는 업무에 대한 자연스러운 공유 (내 동료는 무엇을 하나)
- 설계 개선 제안
- 개발 문화 개선
- 코드 리뷰는 지식, 공학적 결정을 공유하는 기회이다.
- 공유를 통해 서로의 지식/경험을 나누어 상호 학습을 통한 역량 증대 수단이다.
왜 코드 리뷰는 어려울까?
- 저자는 본인 생각이 멋지다고 생각하는 PR을 보낼 것이다.
- 리뷰어는 왜 멋지지 않은지에 대한 장황한 이유를 코멘트한다.
- 코드에 대한 비판을 자신에 대한 비판으로 오해한다.
- 코드에 대한 지적을 본인에 대한 지적과 분리해서 생각해야 한다.
- 생각을 글로 전달하는 것이 대한 어려움이 있다.
- 피드백을 조심스럽게 표현하는 것이 어렵다.
- 구성원들이 리뷰할 시간이 없다고 느낀다.
- 당신이 개인 기여(코드를 병합 여부)로 만 평가를 받고 있다면, 팀을 돕기 위해 수행하는 모든 일들에 대해 시간 낭비로 보일 수 있다.
- 다른 사람의 코드를 리뷰해 주는 것 역시 업무로 보아야 하고 시간 낭비라고 생각하지 않아야 한다.
- 이것은 리뷰를 하는 것의 문제라기보다는 조직의 문제이다.
효율적인 코드 리뷰
- 저자 (리뷰위)는 리뷰어의 시간을 아껴주어야 한다.
- PR을 올릴 때 최대한 자세한 내용을 작성한다.
- 모든 문서는 소비자 (리뷰어)를 위한 것이다.
- 생산자는 소비자의 시간을 아끼기 위해 충분한 내용을 설명해야 한다.
- 스타일 가이드를 확립하고 논쟁을 최소화한다.
- PR 올릴 때 주석 또는 코멘트를 추가한다.
- 저자가 먼저 읽어보고 코멘트를 추가하여 리뷰어의 시간을 절약할 수 있도록 하라.
- 리뷰어는 특정 사람만 포함하지 않고 모든 사람을 포함한다.
- 더 많은 리뷰어는 더 많은 버그를 잡을 가능성을 높여준다.
- 더 많은 리뷰어에 대해 작성자는 대게 더 좋은 코드를 작성하려는 경향이 있다.
- PR에 변경된 내용을 최소화하라.
- 의미있는 커밋으로 분리하여 PR한다.
- 변경된 코드는 200줄 이내로 빠르게 읽고 이해할 수 있는 수준으로 분리하라.
건설적인 피드백을 하자
- 잘못된 부분의 지적뿐 아니라 잘 된 부분에 대해서도 칭찬을 아끼지 말자.
- 저자가 주니어 혹은 신규 입사자라면 리뷰에 대해 더 민감하고 방어적일 수 있다.
- 진심 어린 칭찬은 리뷰어가 잔인한 감시자가 아니라 도와주려는 팀 동료라는 인신을 줄 수 있다.
- 제안하는 변경과 이유를 함께 설명하라.
- 이 클래스는 2개로 분리해야 해요 (X)
- 이 클래스는 다운로드와 파싱 두 가지 일을 처리하고 있어요. SRP 준수를 위해 분리하는 게 어떨까요? (O)
- SW는 과학인 동시에 예술이다.
- 항상 원칙에 기반하여 무엇이 잘못되었는지 설명할 수 있는 것은 아니다.
- 이럴 경우 무엇을 할 수 있는지 객관적으로 설명하라.
- 이 코드는 혼란스럽네요… (X)
저는
이 코드가 잘 이해되지 않네요 (O)
- 반복적인 피드백에 대해서 모든 상황을 언급하지 마라.
- 개발 모든 사례가 아니라 특정 패턴에 대해 지적하라.
교착 상태는 적극적으로 처리하자
- 코멘트의 톤이 공격적이고 코멘트가 계속 많아진다면 주의하자.
- 한 PR에서 코멘트가 가능한 한 50개가 넘지 않도록 하자
- 최악의 경우엔 교착상태에 빠지게 된다.
- 리뷰어는 코멘트를 반영하지 않아 PR을 거부하거나, 리뷰위는 코멘트를 거절한다.
- 화상 혹은 만나서 (가능한 한 표정과 분위기를 느낄 수 있는 오프라인을 추천한다) 교착상태를 적극적으로 처리해라.
본인의 구성원들은 지금은 프로젝트가 바빠서 코드 리뷰 할 시간이 없다고 생각하는가?
- 우리는 시간이 정해진 시험에서 성적을 받는 것이다.
- 때문에 지금은 시간이 없기 때문에 코드 리뷰를 패스하자라고 결정할 수 있다
- 하지만 지금 시간이 없다고 나중에 시간이 생기는 것은 아니다.
- 시간을 아끼는 가장 좋은 노력은 저자 (리뷰위)의 노력이다.
- PR 주기를 짧게 하고 사이즈를 적게 하라.
- 코드는 짧고 명확하게 200줄을 넘지 않도록 한다.
- PR 주기는 반나절 정도 업무 한 내용, 작은 기능의 단위로 나누어 PR 하라
참고 링크