Why Is Code Review Necessary?

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이 없으면 프로그램의 설계는 낡아진다.(항상 새로운 것이 나오니까!)

• 설계가 좋지 않은 코드는 보통 같은 일을 하는데 코드가 길고, 같은 일을 여러 곳에서 한다.

• 코드가 이해하기 쉬워진다.

• 결함을 검출할 수 있다.

• 프로그램 속도가 향상된다.(프로그램에 대해 더 잘 이해하기 때문)