Why Is Code Review Necessary?

Why Is Code Review Necessary?

2023. 4. 4. 16:04ㆍComputer Science

728x90

1. Google이 일하는 방식

1) Test Driven Development

테스트가 기본이다.
구현해야 할 요구사항과 구현체를 분리해서 구현하기 전에 테스트를 먼저 작성한다.
엣지 케이스, 코너 케이스 등을 생각해서 테스트를 작성한다.
테스트를 먼저 작성하는 이유: 코딩을 먼저 하면 내 코드에 맞는 테스트만 떠올리게 되기 때문에, 테스트를 먼저 작성하고 코딩을 한다.
테스트는 실행 가능한 문서라고 하는데,
comment는 테스트해볼 수도 없고 내 코드와 맞는지 확인할 수 없는 반면, 테스트는 코드와 동기화가 될 수 밖에 없기 때문이다.
구글은 테스트가 없으면 커밋조차 할 수 없다.

2) Short iterations

자잘하게 빨리 빨리 많이 커밋을 해놔야 문제가 생겼을 때 파악하기 쉽다.

3) Pair programming

제일 빠르게 배우는 것은 선배 어깨 너머로 배우는 것이다.
나란히 앉아서 컴퓨터 한 대로 코딩하면 굉장히 빠르게 배울 수 있다.

4) Code review

이것이 오늘의 주제 🌟

2. 코드리뷰란?

소프트웨어 개발 흐름에서 꼭 필요한 한 단계이다. 선택 사항이 아니다. 필쑤!
동료로부터 코드에 대해 피드백을 받는 것이다.
❌ 소프트웨어 설계에 대한 고민 혹은 요구사항/기능에 대한 계획이 아니다.

3. Code Review Workflow

Step 1: A software engineer (SWE) implements a CL(change list).

소프트웨어 엔지니어(SWE)가 CL(Change List)를 만든다.

Step 2: The CL owner sends the CL to his/her colleagues for comments.

동료들에게 CL을 보낸다.

Step 3: The designated colleagues leave comments on the received CL.

지목 받은 동료가 코멘트를 남긴다.
(최근 구글에서는 적합한 리뷰어를 추천해주는 봇을 활용하기도 한다.)

Step 4: The CL owner changes his/her CL based on the received comments and iterates Steps 2 & 3 until the owner gets LGTM (Looks Good To Me).

CL 오너가 LGTM이 될 때까지 수정한다.
LGTM: 내가 보기엔 좋아보여요.👍 라는 의미이다.

Step 5: When all reviewers say LGTM, the CL owner submits the CL to the repository.

리뷰는 적어도 두명이 해준다. 리뷰어 모두가 LGTM이 될 때 넘어가는 것이다.

4. Why Is Code Review Necessary?

나의 CL을 이해하기 쉽게 만든다.
내 동료가 내 코드를 이해할 수 있어야 한다. (한 달 후에 내가 내 코드를 보고도 기억이 안 나서 동료의 입장이 될 수도 있다. 🫣)
내 CL에 동료가 남긴 의견으로부터 tips & lessons를 배울 수 있다.
숙련된 개발자로부터 코딩 스타일과 팁을 배울 수 있다.
팀이 공통된 코딩 스타일을 공유할 수 있다.
결함을 줄일 수 있다.
Coding Decision에 대한 개발 역사를 보관할 수 있다.
코드 리뷰를 하면 해당 기능에 대해 알고 있는 사람이 한두명 더 있게 되는 것이다. (공석 대비 가능)
동료의 의견은 코드 설계와 결정 사항을 이해하는 데 매우 큰 도움이 된다.
새로 온 개발자는 committed logs와 의견으로부터 코드의 구조와 결정 사항을 이해할 수 있다.
내 코드에 일관적인 코딩 스타일을 유지할 수 있다.
새로 온 개발자가 기존의 코딩 스타일을 따를 수 있도록 도와준다.
일관적인 코딩 스타일은 이후에 코드를 refactoring하거나 디버깅할 때 큰 도움이 된다.

5. Possible Downsides of Code Review

거칠고 무례한 의견 때문에 SWE가 위축될 수 있다. 👉 건설적인 피드백을 해야 한다.
리뷰가 늦어지면 개발 기간이 늦어진다.
코드 리뷰를 제대로 하려면 시간이 걸린다.
경험이 부족한 개발자의 잘못된 CL을 리뷰하느라 숙련된 개발자의 시간이 허비될 수 있다.
코드 리뷰를 위해서는 어느정도 숙련된 개발자가 필요하다.

But, 숙련된 개발자도 코드리뷰를 통해 자신의 생각을 말로 바꾸면서 많이 배우게 된다.

6. Code Reviews Are Cultural

동료를 존중해야 한다.
건설적인 피드백을 해야 한다.
코드리뷰를 하면 코드가 건강해지고 확장 가능한 코드가 된다.
(코드가 투명해질 수밖에 없다. 리뷰어가 이해하지 못하면 LGTM를 하지 않으니까!)
타 팀 간 코드리뷰를 하게 되면 같이 일하게 되어 협력이 늘어난다.
코드의 표준이 점점 올라간다. (수준 격차가 좁혀진다.)
코드 리뷰는 팀워크다.

7. Style Guide

1) Google Style Guide Goal

구글 코딩 가이드라인의 목표

코딩 가이드라인을 지켜야 한다. (예외는 있다.)
해당 언어의 전문가(readability)와 프로젝트 오너(ownership)는 반드시 포함하여 코드리뷰를 해야 한다.
코드 리뷰는 작성자를 위한 것이 아니라 읽는 사람을 위한 것이다.
이미 있는 코드의 룰에 맞춰야 한다.
새로운 기능은 테스트가 충분하지 않아 잘못됐을 가능성도 있고, 해당 기능을 모르는 사람도 있으니 욕심을 버리고 기본에 충실하는 것이 좋다.
코드 리뷰의 피드백으로 인하여 속도가 느려진다면, 속도(최적화)를 우선시한다.

2) How to Enforce the Style Guide

스타일 가이드를 적용하는 방법

코드리뷰를 하면서 리뷰어가 확인한다.
사람 대신 도구가 확인한다.

3)Rules

General Naming Rule : 변수명

이해하기 쉽게 짓는다.
약어를 사용하지 않는다.

조건문

조건문 괄호 사이에 빈 칸을 추가해라 하지 말아라 등의 기준은 나름의 유행이 있다. 종종 바뀐다. 기계에게 맡기자

함수🌟

아주 중요하다. 함수는 작게 짜라! 한 번에 한 놈만 패라!
하는 일이 무엇인지 명확해야 하고 이름에서 드러나야 한다.
잘게 쪼개야 디버깅할 때도 편하다.

요약

모두 따르지 않아도 된다. 중요한 것은 팀에서는 일관된 스타일이 있는 것이 좋다.
가이드라인은 시간이 갈수록 발전할 수 있고, 언제나 예외가 있을 수 있다.

8. Testing

1) Why Is Testing So Important?

Testing Rocks! Debug Sucks!

디버깅은 보통 문제를 찾는 데 시간이 굉장히 오래 걸린다.
테스팅은 새로 작성한 코드에서도 결함을 검출할 수 있다.
유지보수 부담을 줄인다.

Project Scalability

새로 온 개발자도 테스트 코드를 잘 작성해서 프로젝트에 기여할 수 있다.
동료나 외부 기여자에게서 도움을 받기에 가장 적합하다.

2) Testing Types

Unit Testing

제일 많이 한다.
단위 하나(함수 하나씩) 테스트하는 것

Integration Testing

함수가 어디서 쓰이느냐에 따라 다를 수 있기 때문에 Unit Testing만으로는 충분하지 않다.
내가 짠 함수는 내가 가정한 상황에서만 쓰이는 것이 보장되지 않는다.
어디서든 쓰일 수 있으므로 전체 Integration에서 테스팅해봐야 한다.

Regression Testing

과거에 예상했던 동작을 새 코드도 유지하는지 확인한다.

End-to-End (E2E) Testing

9. Code Refactoring

Refactoring은 SW의 동작을 바꾸지 않으면서 내부 구조를 개선하는 것이다.
즉, 코드의 구조를 잘 정해진 규정대로 수정하는 기술이다.
SW를 더 이해하기 쉽게 만들고 수정하는 비용을 줄인다.
꽤 오랫동안 숙련된 개발자들 사이에 전해 내려오는 노하우로, 정돈되지 않고 일관적이지 않다.
Refactoring is an overhead activity.

Why Refactor?

Refactoring이 없으면 프로그램의 설계는 낡아진다.(항상 새로운 것이 나오니까!)
설계가 좋지 않은 코드는 보통 같은 일을 하는데 코드가 길고, 같은 일을 여러 곳에서 한다.
코드가 이해하기 쉬워진다.
결함을 검출할 수 있다.
프로그램 속도가 향상된다.(프로그램에 대해 더 잘 이해하기 때문)