지속 가능한 sw 개발을 위한 코드리뷰 후기

개요

---

 평소에 코드리뷰에 관심이 많아서 강의를 보게 되었다. 이전에 코드숨을 수강하면서 johnrib님의 코드리뷰가 많이 기억이 났다. 배민 출신이시다보니 문화적으로 비슷한 느낌이 많았다. 답을 알려주시기 보다 과정을 알려주셨고 굉장히 친절하고 상냥하게 리뷰를 해주셨다. 또한 프로젝트 시에는 짧은 단위로 PR을 날리라고 많은 조언을 해주셨다.

 

 

https://www.youtube.com/watch?v=ssDMIcPBqUE 

 

<한두 등급만 코드 레벨을 올리는 것을 목표>
효율적인 리뷰 방법

D 등급의 PR을 받으면 저자가 C나 B등급을 받도록 도와라
완전하지는 않아도 충분히 좋은 코드가 되도록 한다

피드백 방법
<절대 '너'라고 하지 마라>
I message 대화법 : 행동 - 결과 - 감정
~하는 것을 제안합니다. ~ 하는게 어떨까요?
->> 물어보면 대답한다. 안한다고 대답해도 된다.


<건설적인 피드백>
동료들간에 경쟁유발이 아닌 생산성을 높이는 것이 목표이다.
코드 리뷰를 자신의 코드에 대해 비판이 아니라 학습과정을 ㅗ인지한다

<진정한 칭찬>
대부분의 리뷰어가 잘못에만 집중하지만...
오 이런 API가 있나요 정말 유용하네요
정말 좋은 해결책이네요 생각도 못했네요


<피드백은 명령이 아니라 요청>
명령 : 12번 테이블이 비었네요 우리 가족은 저기에 앉을거에요
요청 : 네 명 앉을자리 부탁합니다
의견이 아니라 원칙 기반 피드백
반복적인 패턴은 피드백을 제한하라

클래스는 별도의 파일로 분리하라
-> 클래스가 너무 커지는 것 같은데 괜찮을까요?

<교착상태 시>
너무 논쟁이 길어지면 테크리더에게 문의하거나,
다른 리뷰어를 할당하거나, 아주 심각하지 않다면 그냥 인정하고 좋은관계로 협업하자

개발 생산성 vs 개발품질
- 버그 수정 비용은 개발 라이프싸이클 후반으로 갈수록 기하급수적으로 커진다
- 품질이 높으면 라이프싸이클의 후반으로 갈 수록 시간이 절약된다
다음번 변경에도 계속적으로 절약을 시킨다


너무 기법/절차에 의지하지 말라
- 코드리뷰는 너무 기법과 절차에 의지하지 말아야 한다.
툴(bitbucket) ? 일단 사람의 눈에 잘 읽히는 코드인지가 중요하다

 

주기 : 짧게 자주, 그러니 PR 사이즈 작게

 

꾸준히 코드리뷰를 하는데, 추후에 장애로 발견되는 사례가 많다
- 리뷰를 한다고 100% 버그를 사전에 잡을 수는 없다, 수학이 아니라 과학이다
누적되면 조직의 버그 사전 탐지율이 높아진다

 

상사를 어떻게 설득하나?
측정을 해서 개선효과를 보여야 한다.
ACCELERATE
변경 실패율, 장애복구시간, 빈도, 리드타임 등
의사결정권자들에게 TDD가 중요한 것이 아니다, 이해와 신뢰를 구축하는 것이다

 

깃허브로 리뷰를 진행하는데 리뷰어의 응답을 기다리다가 지체되는 현상
- 리뷰가 반나절, 1일 이상 지나도 답변이 없다면 그냥 배포한다
만약 그럴 경우에는 팀 전체가 책임을 진다
리뷰를 못받는 이유중 하나는 너무 큰 PR이기 때문이다
예를 들어 5일동안 작업내용을 한번에 올리면 안된다. 잘게 쪼개서 올린다

 

경험하신 코드리뷰중 가장 좋았던 경험, 가장 나빴던 경험
- 사내강의를 했을 때 좋은 내용을 바로 적용해 본 코드리뷰가 최고의 경험이다
가장 나쁜 것은 업무시간에 일을 안하고 책을 본다. 내가 부족한 것은
업무시간 이외에 공부해야 한다

 

코드구현시 주석을 어느정도까지 써야 할까? 변수명을 짓는 법은?
디렉터리 구조를 어떤 식으로 가져가는 것인가?
- "의도를 드러내도록 해야한다"를 가장 큰 맥락으로 간다
디렉터리 구조는 각 프로젝트에 맞게 하는 것이 맞다 정답은 없다

 

코드리뷰의 성과를 측정할 수 있는 방법은 있을까요?
(상급자에게 성과보고를 하면 더 많은 지원을 받기 위함)
- 정량적으로 성과를 보여주어야 한다. "리팩토링을 하면 다음번에는
시간이 단축될거에요" 라고 말하면, 실제로 그렇게 되도록 해야한다

 

한개의 PR에 대해 리뷰할 때 평균 어느정도 시간이 소요되나요?
- 1분, 10분, 등등... 9개를 30분 안에 리뷰해야한다면?
리뷰할 때 오래걸린다는 의미는 PR이 너무 크거나, 복잡하게 설계한 경우이다
보통 한 리뷰당 수분이고 정말 길 때 10분이다

 

PR을 어떤 기준으로 나누어야 하는지 궁금합니다
- 예를 들어 line 수를 200개로 제한한다

 

PR을 짧게 자주하라고 하는데, 어떻게 해야하나요?
1개의 기능에 대해서 PR을 1번에 해야한다는 생각을 보통 한다
하지만 중간중간 의미가 있다면 여러개의 기능을 나눌 수 있다
만약에 1개의 기능만 한다면 커밋을 정말 잘 만들어야 한다

 

피어리뷰를 할 때, 남의 코드를 맘대로 고치면 기분 나빠하지 않을까요?
- 서로 협업이 중요하다. 만약에 상대방이 원하지 않으면 안하면 된다

 

리뷰 받은 내용이 오히려 코드를 읽기 난해하게 하는 등 퀄리티를 낮추는 것이여서
그것의 이유를 상대방에게 설명했는데 말을 듣지 않는다면?
- 팀장님에게 부탁을 하거나, 한번 져줄 수 있다.

 

 

짝코딩을 시도했는데 상대 개발자분이 라이브코딩으로 하는 것에 부담을 느낀다면?
- 상대방에게 너무 많은 것을 조언했다면 10마디를 할 수 있을 때 한가지만 말해준다
한번에 너무 많이 하면 압도당하므로 과하게 하지 않도록 한다.

 

회사나 팀에 지원할 때, 정말로 코드리뷰나 공유 등 문화에 신경을 쓰는구나 알아보는 방법은?
- 기술블로그, 세미나, 블라인드, 지인들을 통해서 물어본다


*내가 만나고 싶은 사수
-> 내가 고민하는 문제에 대해 답을 제시해도 좋지만, 답에 도달할 수 있도록
과정을 코칭해주는 사수

 

* 추가 참고 영상

백명석 강연자분은 okky 에서도 코드 리뷰에 관해서 강연을 하셨다. 비슷한 주제로 하신것 같으므로 같이 봐도 좋을 것 같다.

 

https://www.youtube.com/watch?v=TAPviNhFuSg