코드리뷰

본 글은 백명석님의 [LIVE] 지속가능한 SW 개발을 위한 코드리뷰 :: 4월 우아한테크세미나를 보고 정리한 것입니다.

 

 

1. 코드리뷰의 중요성

Software is eating the world

시장 :VUCA 
Volatility 변동성
Uncertainty 불확실성
Complexity 복잡성
Ambiguity 모호성
불확실하고 복잡하고 모호하며 변화가 많은 세상

개발 조직의 성능(생성성)이 중요해짐

-출시별 개발 리소스 증가
기존코드(레거씨) 파악에 따른 생산성 저하
좋은 코드는 생산성이 45도. 나쁜 코드는 초기에는 생산성이 좋으나 점점 낮아짐. 두개 만나는 지점 지나면 좋은 설계가 더 생산성이 좋음.

SW의 진정한 비용 = 유지보수(전체의 80% 이상)

The only way to go fast is to go well  -Robert C. Martin


2.코드리뷰 목적

1) 품질 문제 검수(버그 ,장애)
2) 더나은 코드 품질: 아키텍처 속성 개선을 위한 코드 개선(향후 변경 비용 개선)
3) 학습 및 지식 전달
-공유 :리뷰어드들도  리뷰 과정에서 지식 얻게됨(하드스킬,소프트 스킬-어떻게 주니어를 대해야겠구나)
-동기부여(잘하고 싶은마음)


3.코드 리뷰 오너의 자세 

1)PR 올릴때 주석달기 
저자가 고생해서 리뷰어의 시간을
아껴줘야함 

2)의미있는 커밋으로 분리
그래야 리뷰어도 쉽게 리뷰해줄 수 있다.
(ex 변경라인이 200라인 이하)


3.)내가 틀릴수 있구나라는 생각을 가져야
코드에 대한 비판을 자신 비판으로 받지 말아야



4.코드 리뷰어의 자세 


1.)리뷰는 즉시 시작

오전 30분, 오후 30분 팀에서 정할 수 있다.
코드리뷰 올렸는데 아무도 신경 안써서 배포됬다. 팀 전체의 책임


pull requests vs pair programming

트레이드 오프: latency(페어는 빠르다) or throughput(코드리뷰는 많은 사람들이 볼 수 있다)
내향:코드리뷰
외향: 짝 프로그래밍


2)고수준으로 시작(버그,장애,성능 보안) 저수준으로 내려가라(선택적 설계 개선,변수명, 주석)
크리티컬한거 먼저, 한번에 너무 많이 x

3)예제 코드 제공에 관대하라

4)리뷰의 범위를 존중하라

PR 근처의 코드를 보고 수정 요청
PR에 포함되지 않은 라인은 리뷰 범위가 아님(cf: PR이 둘러싼 코드에 영향을 미칠때)

5)태그를 활용
고치면 좋지만 아니어도 그만이란 태그 만들어서 제공


6)한두 등급만 코드 레벨을 올리는 것을 목표로
D등급 ->C,B 등급까지만 계단식으로 올려주는 방식 취하기.

리뷰를 잘 해주는사람을 시간이 남는 사람이 아니라 개인 기여로 평가해줘라

7)피드백 방법

너라 하지 마라(너는 왜 맨날)
건설적인 피드백을 하라 (경쟁유발x, 팀의 생산성 높이는것)
진정한 칭찬을 해라
피드백은 명령이 아니라 요청으로 표현해라
의견이 아니라 원칙에 기반하여 피드백하라(제안하는 변경+ 변경의 이유)
반복적인 패턴에 대해서 피드백을 제한하라( 실수 동일패턴이면 2~3개만 언급)
교착상태를 적극적으로 처리해라(완전 의견 불일치시  크리티컬아니면 일단 승인)


I message
~하는 것을 제안합니다. 
~하는게 어떨까요?
~ 괜찮을까요?
~할 수 있을까요?
저는 이 코드가 이해하기 어렵네요

-기타-
처우조건으로 이직 하려하지말고
현재 성장할 수 있는곳에 있나? 그럼 이직하지 마라
나혼자도 할 수 있다. 내가 배우고 싶은게 다른곳에 있다라고 할때 이직하는게 맞다.
회사의 네임밸류가 내 네임밸류가 아니다.
개발자는 주말에 일을 하면 워커홀릭이지만 주말에 공부를 안하면 불안해야한다.