코드 리뷰 관련 질문!!
첫술에 배부를 수 없다
작년 패스트캠퍼스 레드에 "개발자의 성장, 코드 리뷰, 레거시, TDD" 등에 대해서 최범균 님과 함께 강의를 했다.
https://fastcampus.co.kr/dev_red_bcr
이후 코드 리뷰에 대한 강연 요청이 꽤 있어서 몇 곳에서 추가로 강연을 했다. 패스트캠퍼스 강연은 슬랙을 통해서, 다른 강연의 경우 사전 질문, 실시간 질문 등을 받았는데 가장 많이 나오는 질문이 오늘도 나와서 브런치 글을 작성하여 공유하려고 한다.
다들 예상하겠지만 가장 많이 나오는 질문은
코드 리뷰 좋은지 알겠는데, 시간이 없다. 리뷰 말고도 할 일이 많다.
이다.
이에 대한 내 생각을 정리해 본다.
1. 코드 리뷰에 최소의 시간이 소요되도록 저자(PR을 작성자)가 노력하자
PR을 적은 크기로 올려서 빠르게 리뷰될 수 있도록 하자
PR에서 꼭 의견을 받았으면 하는 중요한 부분이나, 리뷰어들이 코드만 보고 이해하기 어려운 부분이 있다면 그 부분에 저자가 먼저 코멘트를 남겨서 리뷰어들을 도와라
기계가 더 잘하는 부분을 사람이 검토하지 않게 노력하자(intellij의 inspection, sonarLint 등을 활용한 정적 분석, 소스 코드 포맷팅, 테스트, 빌드 등)
2. 매일 아침 10분 정도 스탠드업 미팅을 하듯 오전 30분, 점심 식사 후 30분 정도 정해진 리뷰 시간을 갖자
30분 안에 팀에 올라온 PR을 리뷰할 수 있도록 작은 단위로 리뷰를 받자(30분은 예시적 숫자임)
3. 품질과 생산성
개발 라이프 사이클 후반에 결함이 발생하면 결함 수정 비용이 라이프 사이클 전반에 비해 엄청 비쌈
또한 아래와 같은 재작업(rework) 비용이 발생함
- 버그 관련 회의 시간
- 시간이 지난 후 버그 재현에 소요되는 시간
- 버그로 인한 고객 응대에 소요되는 시간 등
라이프 사이클 초반에 코드 리뷰 등을 통해 품질을 위해 투자를 하면 라이프 사이클 후반에 발생 가능한 비용을 현저히 낮출 수 있음
게다가 좋은 품질의 코드는 향후 변경 비용을 낮춰서 새로운 기능 추가나 변경 시 생산성 향상으로 이어져 서비스의 성공에 기여할 수 있음
4. 기타
시간이 부족하다면 버그, 장애 등 치명적인 부분만이라도 리뷰하는 것으로 시작해서 점차 확대해 나가자
리뷰에 들이는 노력을 조직에서 성과로 인정하자
- 당신이 '개인 기여(코드 작성)'로만 평가를 받고 있다면, 팀을 돕기 위해 수행하는 모든 일(코드 리뷰, 공유 등)은 시간 낭비처럼 보일 수 있음. 이러한 활동이 성과로 인정받아야 함
- 이것은 리뷰를 하는 것의 문제라기보다는 조직적인 문제임
"고통의 계곡"이 존재함
- 초기 투자는 혜택을 가져오지 못하고 오히려 퇴보를 가져옴(익숙하지 않으니)
- 지속적인 노력을 일정 시간 투자해야 진정한 혜택이 기하급수적으로 나타남
- 이 혜택을 얻기까지 초기에 나타나는 난관은 불가피
“If it hurts, do it more often” - Continuous Delivery
코드 리뷰를 한다고 결함이 100% 제거되지 않음
- 꾸준히 코드 리뷰를 진행함에도 불구하고 조기에 발견될 수 있는 오류가 추후에 장애로 발견될 수 있음
- 리뷰를 한다고 100% 버그를 사전에 잡을 수는 없음. SW 개발은 수학이 아니라 과학임
- 수학은 참임을 증명할 수 있는 학문이지만, 과학은 반증 가능성(falsifiable)을 통해 틀리지 않았음을 증명하는 학문임
- 테스트가 아무리 많아도 오류는 있을 수 있고, 리뷰를 많이 하더라도 오류는 있을 수 있음
- 하지만 테스트, 리뷰 항목이 누적되면 조직의 버그 사전 탐지율이 높아질 것임
마무리
코드 리뷰 자체가 성취하고자 하는 목적은 아니다. 코드 리뷰를 통해
- 버그, 장애 등이 결함을 최소화하고
- 우리 팀에서 일어나는 업무에 대해서 공유하고
- 학교에서는 배울 수 없는, 현업에서 업무 수행을 과정에서 상호 간의 공유를 통한 학습을 통해 함께 성장하는 것
이 우리가 만들어가는 서비스의 성공에 기여한다고 생각한다.
지금 당장 우리가 행할 수 있는 성장을 위한 공유 활동, 품질 향상을 통해 생산성 향상을 위한 수단으로 코드 리뷰를 수행했으면 한다.
처음에 도입하면 위의 "고통의 계곡"에서도 설명되었지만 여러 가지 어려움이 있을 것이다. 처음부터 완벽하게 잘하려고 하지 말고 한 번에 도입할 수 있는 코드 리뷰를 10번 아니 100번의 단계로 나눠서 점진적으로 도입한다는 마음으로 임했으면 한다. 그러다 보면 어느새 꽤 잘하고 있는 우리를 발견할 수 있을 것이다.
