생산성 있는 Review 문화가 되기까지
(engineering.ab180.co)- Review 문화가 자리 잡게 된 배경
- Code Review를 통해 실수 줄이기
- Approve를 통해 follow up 확인하기
- Tech Spec도 Review 하자!
- Review를 더 많이 하다보니 생긴 문제들
- 업무량 증가: 특히 오래된 팀원들의 review 업무량이 과도해짐
- 느려진 속도: 다음 단계로 넘어가기 위해 review를 기다려야 하므로 속도가 느려짐
- 예상할 수 없는 일정: review가 언제 완료될 지 모르기 때문에 일정을 예측하기 어려워짐
- (AB180에서의) 문제 해결하기
- 의도적인 Review 분산: 새로운 팀원들도 review를 하면서 context를 가져가고 최종적으로는 위임시켜야 함
- 일정을 예상 가능하게 만들기: review 시간 규칙 등을 활용해서 review cycle을 예측 가능하게 만들어야 함
- Review 요청을 자율적으로 판단하게 하기: review가 무의미한 경우 형식적인 review는 지양
- 얻은 교훈들
- Code Review로 실수를 막을 생각을 하지 말 것
- 규칙에 얽메이지 말 것
- 일정을 예상 가능하게 만들 것
대부분의 상황에서 리뷰에 대한 인식때문에 문제가 발생한다고 생각합니다.
-
업무량이 많아진다: 중요도가 자신의 업무 > 리뷰 라는 인식에서 발생. 팀으로써 코드리뷰는 개발만큼 중요함. 그래서 '코드리뷰 때문에' 업무가 많아진다는 말은 잘못되었다고 생각. 그냥 업무가 많은거..
-
리뷰에서 실수를 발견하지 못함: 절대로 100% 문제를 잡을수는 없음. 하지만 리뷰를 통해서 리뷰어도 실수에 대한 책임을 나누게 됨. 이는 작업자의 부담도 덜고, 리뷰의 책임감도 키울 수 있는 문화로 적용될 수 있음.
이전에 코드리뷰가 없는 회사에서 코드리뷰를 도입할 때 가장 강조했던 부분이 코드리뷰는 개발만큼 중요한 업무라는 것이었습니다. 코드리뷰는 다른사람의 코드를 도와주는 문화가 아니고, 팀전체에 컨텍스트를 전파하는, 작업자의 코드를 '팀'의 코드로 만드는 일이라는 이야기를 많이 했습니다.
이 글에도 나오지만, 저 역시 code review로 안정성을 올리려고 리뷰어를 2명으로 두자고 주장했었습니다. '주말에 개선하고 싶은 코드가 있어서 리팩토링을 해도 리뷰가 힘드니 별로 하고 싶지 않아진다'라는 피드백을 듣고 아차 싶었죠. 좋은 의도가 좋은 결과로 이어지지 않는다는 것을 다시금 깨닫게 된 순간이었습니다.
2022 프로그래머스 개발자 설문 결과를 보면 개발자들이 가장 원하는 개발 문화는 코드 리뷰라고 합니다. 코드 리뷰를 통해서 오류를 발견하고 더 나은 퀄리티의 코드를 함께 만드는 모습을 상상하곤 하죠. 다만 코드 리뷰가 모든 것을 해결해 주는 은탄환은 아닙니다. 조직의 상황에 맞춰서 룰은 유연하게 가져가야 하고 필요하다면 과감히 바꿔야 할 줄 알아야 더 건강한 조직 문화를 만들 수 있지 않을까 생각합니다.