우아한형제들 - 코드 리뷰

2022/05/05
7-minute read

코드 리뷰 Youtube

코드 리뷰의 필요에 대해 고민하는 중, 위와 같은 내용을 확인하고, 정리해보려고 한다.

우리가 살고 있는 세상은 VUCA와 같은 시대

V (Volatile, 변동성)
U (Uncertainty, 불확실성)
C (Complexity, 복잡성)
A (Ambiguity, 모호성)

이와 같은 시대에서, 이에 맞춰가기 위해 필요한 시스템 중 하나가 바로, Code Review

Tech 관련 된 산업은 이제 막 Digital Transformation을 시작하였으며, 필요한 개발자 수의 증가 속도가 매우 빠르게 증가

DRFR (Deliver SW Rapidly, Frequently and more Reliably)

코드 리소스의 증가에 비해, 코드의 생산성은 점차 수렴하는 현상을 볼 수 있음, 그리고 라인 당 개발 비용은 점차 증가하는 현상이 발생

SW 공학

설계 + 빌드
설계는 완전한 소스 코드, SW 빌드는 컴파일
SW에서는 설계가 매우 중요!
SW는 유지보수가 전체의 80% 이상
작성보다 이해에 더 많은 시간과 노력이 필요
SW는 가격와 품질이 비례하지 않음!
향후 수정 가능 여부 등도 가격에 적용 되므로, 무조건 비싼게 현재 품질이 좋다고 할 순 없음!

SW 장인 정신

SW가 발전하기 위해서는 서로 학교에서 어떤 내용을 배우는 것 보다, 개발자 간 상호 내용을 공유하고, 학습하는 것이 중요

Code Review

품질 상승을 위해, 향후 변경 비용 개선을 위해, 상호 간의 지식 공유를 위해 진행
동기부여 및 하드스킬, 소프트 스킬을 배울 수 있음
하드 스킬 : 실질적인 업무에 필요한 기술
소프트 스킬 : 직접적인 연관은 없지만, 필요한 기술 (커뮤니케이션 방법 등)

Why?

상호 책임감, 설계 개선 제안, 개발 문화 개선 등

Procedure

3가지 요소 (저자, 리뷰어, 변경 내역)
저자 : 리뷰어의 시간을 SAVE하기 위해, 상세한 내용으로 설명, 리뷰어의 입장에서 필요한 내용을 설명해야 함!

어려운 이유?

기술에 대한 비판을 사람에 대한 비판으로 받아들이기 때문에, 리뷰가 어렵다! (오해 ㄴ)
생각을 글로 전달하는 것이 어렵다.
말을 공격적이지 않게 하는 것이 중요 (소프트 스킬 필요)

Code Review를 받아들이는 방법

Code를 기반으로 하는 SNS 활동으로 생각하면 좋다!

효율적인 PR 방법

지루한 작업은 컴퓨터로 처리
스타일 가이드를 꼭 따를 것! (없으면 만들어서!)
PR 올릴 때 꼭 주석 달기!
모든 사람을 포함할 것
의미있는 단위로 분리해서 나눌 것!

지루한 작업

컴퓨터가 더 잘하는 일에 노력을 사용하지 말 것!
Formatting Tool 등을 잘 이용
Formatting을 할 경우에는 다른 커밋 또는 PR로 분리할 것!
ex) 특정 Warning을 Error로 바꾸도록 설정해서 (IntelliJ inspection 활용) 쉽게 인지할 수 있도록 하는 방법 –> 툴을 잘 다루면, 본질에 집중할 수 있게 된다.

Style Guide

좋은 가이드를 찾아서 그냥 쓰기
새로운 스타일 가이드를 점점 만들어 가기
두 가지를 합쳐서 사용하기

PR 올릴 때 꼭 주석 달기!

PR을 본인이 먼저 읽어보고, 커멘트를 달아서, 리뷰어의 시간을 아껴줄 것
모든 사람을 포함해서, 더 많은 버그를 찾아낼 수 있도록
여러 명이 볼 수록 더 잘하려는 경향이 있으므로

의미있는 커밋으로 분리

혼자하더라도, 꽤나 상세하게 의미있게 분리할 것

효율적인 리뷰 방법

리뷰는 지금 당장 시작
고수준 –> 저수준 순으로
예제 코드 제공에 관대하라
리뷰의 범위를 존중하라
태그를 활용하라
한 두 등급만 코드 레벨을 올리는 것을 목표로 하라

리뷰는 즉시 시작

코드 리뷰의 우선 순위는 높아야함!
–> 요청자는 리뷰를 받기 전까지 대기함
리뷰를 바로 시작하면 선순환이 가능
리뷰의 최대 기간은 하루
–> 1일 내 불가하면 다른 리뷰어로 변경
–> 월 1회 이상 재지정을 해야한다면, 개발 속도를 줄일 필요가 있음
리뷰가 싫으면, 더 많이 해서 익숙해져라
PR에 너무 많은 내용이 들어가지 않도록
리뷰 자체를 업무 성과로 인정하고, 조직적인 문화로 받아들여라

고수준 –> 저수준 순으로

초기에는 고수준 피드팩으로 제한 (버그, 장애, 성능, 보안 등)
고수준 완료 후 저수준으로
–> 설계 개선, 변수명 변경, 주석 등

예제 코드 제공

리뷰 중 선물 주기 (예제 코드)
너무 긴 예제 말고, 짧게…
라운드 당 2 ~ 3개 코드 예제로
너무 많이하면 자존심 상함ㅠ

리뷰의 범위 존중

PR 범위 밖의 코드에 대해 수정 요청하지 말 것
PR에 포함되지 않은 라인은 리뷰 범위가 아님을 명심
PR이 둘러싼 다른 코드에 영향을 미칠 때는 예외

태그를 활용

팀에서 활용하는 태그를 사용
–> Nit : 고치면 좋지만 아니어도 그만임

한 두 등급만 코드 레벨을 올릴 수 있도록

D등급의 PR은 C or B만 받도록 도울 것
완전할 필요는 없지만, 충분히 좋기만 하면 됨
F 등급 : 기능적으로 틀림, 너무 복잡

피드백 방법

너라고 하지 마라
건설적인 피드백
진정한 칭찬
피드백은 명령이 아니라 요청으로 표현
의견이 아니라, 원칙에 기반하여 피드백
반복적인 패턴에 대해서 피드백은 제한

너라고 하지 마라

비판의 대상이 사람이면 안됨.
I Message 대화법 : 행동 - 결과 - 감정 순서로 말할 것
~ 하는게 어떨까요? 로 말할 것

건설적인 피드백

목적이 생산성을 높이는 것임을 잊지 말 것
실수를 받아들이고, 동기부여할 것
건설적인 피드백을 못할 것 같으면, 차라리 말하지 마라

진정한 칭찬

잘 못된 부분 외에도 좋은 부분은 칭찬할 것
팀워크가 좋아질 수 있음

의견이 아니라 원칙에 기반

제안하는 변경과, 이유를 모두 설명할 것
객관적으로 설명할 것
–> 이 코드는 혼란스럽네요 X
–> 제가 이 코드를 이해하기가 힘드네요 O

반복적인 패턴에 대한 피드백 제한

10개가 있어도, 2~3개만 얘기해도 이해할 것임

교착 상태 해결 방법

만나서 얘기하는게 좋음
인정하거나 EScalate 하라 (윗 사람에게 토스)
다른 리뷰어 할당
설계 리뷰를 고려해라
아주 심각하지 않다면, 협업이 더 중요하다.

코드 리뷰하는 좋은 방법

PR한 사람과 서로 짝 프로그래밍
그 다음 갑자기 Revert ㅋㅋㅋㅋㅋㅋㅋㅋ
자 이제 니가 해봐ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
이 과정 속에서 2시간 동안 스스로 고민하며, 배움

추가적인 사례

결정은 저자가 한다.
–> 완벽한 설계가 아닌, 할 수 있는 최고의 설계
–> 팀의 협업 능력이 더 중요하므로, 불완전한 해결책도 어느정도 받아들일 것
–> 모든 설계 결험이 꼭 문제가 되진 않음
코드 리뷰의 목적은 비난하는 것이 아니라 배우는 것
리뷰하려는 코드가 그냥 나쁠 수도 있음
–> 상황을 이해하려는 시도도 필요 (그 사람의 현재 상태 등)
–> 분위기를 부드럽게 이어갈 것

코드 리뷰의 핵심

저자가 노력해서, 리뷰어의 시간을 아껴줘야 함
리더의 관심과 의지가 중요!
–> 가끔, 그러나 매우 자세히 할 것
코드 비난에 대한 두려움을 내려놓을 것
멋있어 보여야 한다! (다른 사람이 하고 싶어 지게!)

코드 리뷰 문화 정착의 어려움을 극복하는 방법

항상 털릴 준비를 해라…. (좌절ㅠ)
내가 원한다고, 다른 사람에게 영감을 줄 순 없다
영감은 부산물이고, 이를 위해 내가 모범이 되어야 한다.
모범이 되어라
–> 지각하지말 것, 업무에 기여할 것, 긍정적으로 할 것, 사람들에게 잘 대할 것
–> 기술적 훈련을 위해서는 고도로 숙달될 것
–> 키보드로 코딩할 때는 사람들이 경악하도록 할 것

새로운 것을 도입할 때는, 늘 약간의 고통이 수반된다.
포기 하지 않고, 버텨서 꾸준히 좋아질 때 까지 해라

코드 리뷰의 효과

예상치 못한 버그를 타 프로젝트에서 발견
선플이 늘어나기 시작함 (시간이 좀 지나면)
PR 전에 한 번 더 코드를 다듬게 된다.
좋은 설계, 아키텍처, 클린코드, TDD 등에 대한 공감대/열정 형성 (잘하는 동료를 따라하고 싶어짐)

코드 리뷰를 위해 필요한 기술

리팩터링
–> 결과의 변경 없이, 코드의 구조만 재조정
–> 가독성이 좋게 또는 유지보수가 편하게
매일 리팩터링
–> Continuous Renaming
–> Composed Method (Extract Method)
–> 응집도 높이기
–> Discover Value Object
Legacy Code 다루기
–> 의존성 관리 : Subclass & Override Method
–> 테스트 추가 : Characterization Test
–> 새로운 코드빠르게 추가 : Sprout/Wrap Method/Class
–> 레거시 분석
legacy code (코드의 가독성, 규약, 결합도, 땜빵 코드 등으로 인해, 화석처럼 굳어진 코드…, 수정이나 개선이 힘든 코드를 의미)
TDD, Clean Code 등

FAQ

코드 리뷰 자체라기 보단, 코드에 대한 논의 및 공유를 할 수 있는 문화가 중요
개발 생산성 vs 개발 품질 사이의 Trade off
필요한 대상을 찾아가서 물어봐도 좋다 (잘 아는 사람)
꼭 리뷰만이 방법은 아님, 여러 가지 방법을 시도
어떤 것이 중요한지, 우선순위를 정해서 할 것
주기를 짧게 자주, PR을 자주 작게 할 것
리뷰가 버그를 100% 잡을 수 있는 것은 아님, 누적하면 할 수록 사전 탐지율이 높아질 것
상사 설득 방법
–> 측정 항목을 정해서, 개선 효과 측정
–> 의사 결정권자들에게 중요한 것을 이해 및 신뢰 관계
–> 작은 단위로 올바른 방향으로 갈 수 있는 기회 찾기
–> 허가가 필요한가? 노, 필요없다 그냥 필요한 내용을 수행하면 된다. (자동화 테스트, 리팩터링, 코드 리뷰, 페어프로그래밍 등)
코드 리뷰 강의
–> 패캠 The RED
–> sudo : CTO’s Tech Talk 2022 Conference

QNA

Notion으로 코드 리뷰하는 분
–> 코드를 과거와 현재를 비교할 수 있게 두고 보는 방식으로 하는 것이 제일 좋음 (Notion 비추…)
Non-tech 기업에서 Code review 방법
–> 우선은 쉬운 것부터 시작하자.
리뷰가 너무 오래 걸릴 때?
–> 리뷰 관련 규칙을 정해놓고 할 것
코드 구현시, 주석의 정도?, 변수명 짓는 법?, 디렉토리 구조?
–> 의도를 드러내게 지을 것.
–> Clean 코드에 어느정도 있음
코드 리뷰 성과 측정 방법?
–> 수치적인 요소
리뷰의 내용이 좋지 못한 것 같아서, 받아들이지 못한다면?
–> Escalation (상사에게 전달)
짝코딩 잘하는 방법?
–> 한 번에 너무 많은 것을 하지 말 것
회사 문화를 알아보는 방법?
–> 테크 세미나? 블라인드? 주변 지인 등을 통해

내용을 전체를 다 확인해보니, 코드 리뷰의 필요성에 대해서는 원래도 알고 있었던 것 같지만, 더 빠른 적용이 필요할 것으로 생각된다.
회사의 형태에 따라, 적용하는 형태가 조금씩 달라야되므로… 우리 회사에 적용하는데는 또 새로운 방법이 필요하겠지만 꼭 적응해볼 수 있기를 바라며..