출처 [LIVE] 지속가능한 SW 개발을 위한 코드리뷰 :: 4월 우아한테크세미나

📕 코드리뷰가 필요한 이유

✍ 백명석 개발자님

자기혼자 잘할 수 있다. 하지만 협력을 했을 때의 결과물과 뛰어난 한사람이 내는 결과물의 차이가 크다. 그래서 협력을 할 때 더 좋은 결과물을 내기 위한 과정으로 코드리뷰를 잘 하는 것도 중요하다고 생각한다.

✍ 우리가 살고 있는 시대

📄 시장(VUCA)

V Volatility (변동성) - 변화의 속도가 빠르고 다양하게 전개된다.
U Uncertainty (불확실성) - 미래 상황을 예측하기 어렵다.
C Complexity (복잡성) - 인과관계가 단순하지 않고 더욱 복잡해질 것이다.
A Ambiguity (모호성) - 뚜렷한 현상이 없어 판별하기 어려울 것이다.

우리가 살고 있는 시대의 시장은 앞으로 더 불확실하고 복잡하고 모호하며 변화가 많아질 것이다.

📄 비지니스

시장에 맞춰 더 빠른 혁신이 필요함

📄 개발 DRFR

Deliver SW Rapidly, Frequently and mor Reliably
소프트웨어를 더 빠르고 더 자주 더 안정적으로 출시해야한다.

즉 테스트는 더 자주 더 많이 빠르게 이뤄져야한다.

✍ 생산성

📄 제품을 생산함에 대해

우리는 제품을 최초에 생상한 때의 생산성은 100프로부터 시작한다. 새로운 기능을 구현하고 만들어냄에 따라 바로 바로 적용하기 때문이다.

하지만 Release가 계속되고 코드가 쌓이다보면 생산성은 점점 줄어들어 심지어 0에 수렴하기까지한다. 그 이유는 코드를 생산하기 위해 기존의 코드를 이해하고 분석하는데 더 많은 시간을 소요하게 되고 코드를 수정함에 따라 버그를 만들어내지 않는데 더 많은 시간을 사용하기 때문이다.

그렇기 때문에 프로젝트가 오래될 수록 개발자의 수는 점점 증가하지만 오히려 생산성은 점점 줄어들 수 밖에 없는 상황이 된다.

✍ SW 공학적 관점

SW 공학은 건축 공학에 쉽게 비교되곤 한다.

공학 = 설계 + 빌드 로 구분할 수 있다고 치자.

📄 설계

두 공학 모두 설계를 잘할 수록 생산성이 증대되고 중요한 업무를 차지한다.

건축 공학 설계도
SW 공학 설계를 위한 도구로는 UML, DB 명세서 등 다양한 도구들이 있지만 직접적으로 빌드에 관여하는 도구는 사실 코드 이다.

📄 빌드

건축 공학 빌드 비용이 가장 크게 비용을 차지한다.
SW 공학 빌드의 비용은 거의 무료에 가깝다.

📄 유지보수

건축 공학 온공 이후에 특별히 큰 일이 없는 이상 거의 유지보수하지 않는다.
SW 공학 빌드한 이후부터 계속되는 유지보수 시작

📄 두 공학의 차이점

위 내용을 봤을 때 두 공학은 비슷한 점이 있지만 사실 가장 중요한 설계와 빌드에서 큰 차이점이 있다. 비용이 발생하는 부분인데 건축 공학의 경우 빌드에서 가장 큰 비용이 발생하고 그 이후에는 비용이 발생하지 않는데 비해

SW 공학의 경우 빌드 이후 유지보수하는데 가장 큰 비용이 들어가게 된다.

📄 클린 코드의 중요성

우리의 가장 큰 비용은 유지보수이다. 그렇기 때문에 우리는 코드를 생산하기 보다 남의 코드를 읽어보며 수정하는 일이 더 많다.

코드를 한번 작성하면 해당 코드는 다른 개발자들에 의해서 10번 이상 읽히며, 해당 개발자들은 해당 코드를 이해하기 위해 10배 이상의 노력이 필요해진다.
이 말은 즉 나는 아무 생각 없이 새로운 코드를 1분만에 짜서 쉽고 빠르게 적용해서 좋은 개발자 같았지만 사실상 내가 만든 1분으로 다른 개발자들은 100분의 노력을 필요로 하게 만들 수 있다는 것이다.

이러한 SW 특징을 봤을 때 우리는 남의 코드를 이해하려고 분석하는 시간을 줄이는 것이 생산성을 높이는데 가장 큰 기여를 할 수 있을 것이라는 결과가 나온다.

📄 SW 개발의 단순 진리

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

clean code의 저자인 마틴에 의하면 SW 개발에서 가장 빠른 길은 잘 가는 것이다. 라는 말인데. 이 말은 이번만 그냥 이렇게 할게라는 행동은 우리의 생산성을 낮추고 결국 나의 발목을 잡는 코드를 만드는 일이 된다는 것이다.

지금 급하다고 개발하는 코드를 clean하지 않게 개발한다면 지금은 빨라 보일 수 있지만 실제로 우리가 빨리 갈수 있는 길이 아니게 된다.

📄 SW 장인 정신

SW 장인 정신이란 도서가 있는데 해당 도서에서는 개발자들 간의 공유활동을 중요시한다. 그럼 우리가 지금부터 당장 할 수 있는 공유활동이 무엇이 있을까? 개발자들 간의 스터디? 후임 or 후배들을 위한 문서작성이나 강의 활동?

가장 쉽고 지금부터 당장 할 수 있는 행동은 코드 리뷰이다. 코드 리뷰는 Code를 통해 SNS와 같이 서로 댓글로 지식을 공유할 수 있으며 배움을 주고 받으며 지속 가능한 SW 개발자가 될 수 있는 가장 쉬운 실천 방법이다.

✍ 목적

📄 품질검수

버그나 장애를 사전에 검수할 수 있음

📄 더 나은 코드 품질

아키텍처 개선을 위한 코드 개선 (향후 변경 비용 개선)

📄 학습 및 지식 전달

• 코드, 해결책 등과 관련된 지식 공유에 서로 기여할 수 있음
• 리뷰어들도 리뷰를 하는 과정 속에서 지식을 습득하게 되는 경우가 많음
  • 주니어는 기술적인 부분을 학습할 수 있다
  • 시니어의 경우 기술적인 부분을 주니어에게 더 효율적으로 설명하는 방법 등을 학습할 수 있다.
• 리뷰를 통해 개선됨을 실질적으로 확인할 수 있어 프로젝트에 기여함을 느낄 수 있음
• 더 좋은 코드를 작성하는 개발자들을 보며 나도 더 좋은 코드를 생상하고 싶은 동기부여를 발생시킬 수 있다.

📄 상호 책임감 증대

코드를 한사람이 짜서 올리는 것이 끝이 아니라 하나의 코드를 팀원들이 모두 함께 공유하며 적용시키기 때문에 팀원 간의 결속력과 증대시킬 수 있다.

또한 해당 프로젝트의 애정과 책임감을 갖게 한다.

📄 개선점을 제안하기 쉬움

📄 개발 문화의 개선

📘 코드 리뷰란

✍ 코드 리뷰의 절차

📄 좋은 Pull Request

저자가 고생해서 리뷰어의 시간을 아껴주어야 함.

PR(Pull Request)를 만들 때 어떠한 기능을 어떻게 실행해서 확인할 수 있는지에 대해 자세한 설명으로 리뷰어의 시간을 아껴주는 것이 좋은 PR이 된다.

출처 [LIVE] 지속가능한 SW 개발을 위한 코드리뷰 :: 4월 우아한테크세미나

✍ 코드 리뷰가 어려운 이유

1. 코드에 대한 비판을 자신에 대한 비판으로 오해
2. 글로만 소통하기 때문에 오해가 발생할 수 있음
3. 피드백을 조심스럽게 표현하는게 중요 (부드러운 톤으로)
4. 피드백을 할땐 당연히 알것이란 생각으로 전달하면 리뷰를 받는 입장에서는 이해가 되지않는 어려운 용어들 투성이일 수 있다.

✍ 효율적인 PR 방법

📄 컴퓨터가 할일은 컴퓨터에게

패키지를 이동시킨다던지 특정 변수명을 한번에 replcaAll 하는 것은 사람이 하는 것보다 컴퓨터가 더 효율적으로 처리할 수 있다. 컴퓨터가 할 일은 컴퓨터에게 시키자.

📄 리뷰를 해야할 코드와 안해도 될 코드를 분리

띄어쓰기나 들여쓰기 같은 것을 수정한 코드는 리뷰어가 따로 볼 필요가 없다. 리뷰가 필요 없는 PR은 표시를 해주어 리뷰어가 시간을 들이지 않도록 하자!

📄 스타일 가이드를 통해 스타일 규칙을 맞추는것도 중요

예를 들어 if() 같은 경우 한줄이면 {}를 생략해도 되는데 그게 싫은 사람들도 있을 수 있다.
PR을 올릴 때 가장 먼저 주석을 달아주기

📄 더 많은 리뷰어를 두자

많은 사람이 볼수록 버그를 더 잘 찾아내며 PR을 올리는 사람도 더 좋은 코드를 짜려고 노력한다.
혼자 하는 것이라도 의미있는 PR을 만들어두면 2주 뒤에 내가 코드를 이해하는데 큰 도움이 된다.

📄 리뷰는 즉시 시작

리뷰를 할 시간을 따로 정하지 않고 PR이 생성된다면 리뷰를 바로 시작하는 것이 좋다. 특히 리뷰어는 자신의 업무 중에 높은 순위로 코드 리뷰를 해주는 것이 팀원에 가장 도움이 된다.

리뷰를 빨리 끝내야 PR을 요청한 개발자가 빠르게 피드백을 받고 다시 PR 순환시킬 수 있다.

또한 PR은 하루 이상 넘어가지 않도록 하는게 좋다.

📄 리뷰가 시간 낭비가 아니라고 느끼게 하자

코드를 작성해서 기능을 만든 사람도 프로젝트에 기여를 한것이지만, 코드를 리뷰해준 리뷰어 또한 자신의 시간을 들여 코드를 리뷰한 사람으로써 프로젝트에 기여한 것으로 팀자체 적으로 평가해주어야 한다.

📄 고수준에서 시작해서 저수준으로 내려가라

리뷰를 받을 때 너무 많은 피드백은 PR 요청자가 당황할 수 있다. 수정할 의견이 많더라도 초기에는 고수준의 피드백부터 시작하여 저수준의 피드백으로 내려가며 이슈를 처리할 수 있도록 하자.

고수준 아키텍처 문제, 디자인 패턴, 버그, 장애, 성능, 보안 이슈 등
저수준 변수명, 주석, 코드 스타일 등

📄 예제 코드를 제공하자

코드를 수정함에 있어 필요하다면 예제 코드를 제공하는 것도 좋은 방법이다.
하지만 예제가 너무 길거나 모든 코드를 바꿔버리면 PR 요청자 입장에서는 억압적으로 보인다.

📄 리뷰 범위를 지켜줘라

리뷰 범위 이외에 코드가 변경해야될 것이라고 생각하여 PR 요청자에게 리뷰를 요청한 범위 이외에 코드 수정을 요청하는 것은 좋은 리뷰가 아닐 확률이 높다.

📄 팀원끼리 키워드를 정하는 것도 좋다

예시로 [Nit] 고쳐도 그만 아니여도 그만 과 같은 팀원들 끼리 키워드를 정하면 리뷰어들끼리 민감한 언어를 좀 더 편하게 주고 받을 수 있다.

📄 한~두 등급만 코드 레벨을 올리는 것을 목표로 리뷰

PR 요청자가 D등급 코드를 짰다고 해서 리뷰어의 실력만큼 코드를 변경하는 것으로 피드백을 하면 안된다. D 등급의 PR을 C, B 등급으로 올릴 수 있도록 돕는 것이지 PR 요청자를 A 등급 코드를 짜도록 만드는 것이 아니다.

✍ 피드백 방법

📄 너라고 하지마라 (너는 왜 맨날 ...)

리뷰는 잘못을 밝혀내는 것이 아닌 코드를 더 좋게 만드는 것이다. 비판의 대상은 항상 코드이지 코드를 작성한 사람이 아니다.

📄 건설적인 피드백을 하라

1. 동료간의 코드리뷰는 서로 누가 잘하냐 경쟁이 아니다.

2. 서로간의 비판이 아닌 서로 지식을 공유하고 학습하는 과정으로 받아들여야한다.

3. 누구든 실수할 수 있고 그 실수에서 배우고 역량을 증대하는 것이 목적이다.

4. 건설적인 패드백을 하지 못할 바에는 하지마라

📄 진정한 칭찬을 해라

1. 잘못된 코드만 찾지마라
2. 좋은 변경점이 있다면 칭찬을 해주는 것이 중요하다.

📄 명령이 아닌 요청으로 표현해라

일상에서 동료간 명령을 하지 않지만 글로써 작성하다 보면 강압적인 명령문을 사용할 때가 있다. 이 점을 조심하자.

📄 의견이 아니라 원칙에 기반하여 피드백해라

의견 저는 이 코드가 잘 이해가 안돼요! 좀더 클린하게 바꿔주실 수 있나요?
원칙 이 코드는 SRP를 준수하지 않은거 같아요! 클래스를 2개로 분리해서 다시 작성해주실 수 있을까요?

📄 반복적인 패턴에 대해서 피드백을 제한하라

예를 들어 String을 trim() 해야하는데 몇군데를 하지 않았다면 2~3군데만 언급해라. 모든 경우를 다 언급하면 PR 요청자의 실수를 모두 꼬집는 행위 같아진다. 대부분 2~3군데만 언급해주어도 모두 수정한다.

✍ 교착 상태 (코드 리뷰 도중 싸워)

코드 리뷰의 최악의 결과는 교착 상태에 빠질 경우다 이럴 경우는 만나서 서로 대화로 해결하자

👏 마치며...

코드리뷰는 서로 동일한 능력의 기술자를 만드는 것이 아닌 모두가 다 함께 프로젝트에 기여하고 프로젝트의 코드를 최상의 상태로 유지하려고 노력하는 행위이다. 또한 가르침의 시간이 아닌 서로 지식을 공유하고 학습을 하는 시간이라는 것을 배웠다.

코드 리뷰를 진행할 때 특별한 규칙을 따라야하는 것은 아니지만 위 내용들을 근거로 자신들의 프로젝트나 주변 상황에 맞게 적용시키는 것이 중요할 것 같다.

이러한 문화를 정착시키고 발전시키는 것은 쉽지 않은 일이지만 만들 수 있다면 좋겠다!