밑바닥 부터 시작하는 CodeReview
- 처음 현재 근무중인 스타트업 입사때만해도 경력직 3명으로 이루어진 곳에서 코드 리뷰를 하기 좋은 조건이였지만 진행을 할 수가 없었다.
첫번째로 1인 1프로젝트
개발자 한명이 풀스텍으로 nodejs, react.js 전부 다 하고 있고 혼자 프로젝트를 진행 하고 있어서 코드리뷰를 할 이유도 없었다.
두번째로 마음 가짐
코드 리뷰를 진행할때에는 마음가짐이 가장 중요한것 같다. 팀원 누구든 코드 리뷰를 진행하는데 받아들이는 마인드가 부정적이여서 도입 할 수가 없었다.(그 부정적인 부분을 설득과 노력하는 기여가 너무나도 상당하기때문) - 하지만 이제는 이런 상황들이 모두가 해결이 되었고 팀내 새로운 사람들도 오시고 팀뿐만 아니라 다른 팀과의 코드리뷰를 진행하기 위해 코드 리뷰를 사내에 다시 도입하기로 마음 먹었다.
- 크게 코드 리뷰를 도입하기 위해서 4가지 과정에 걸쳐서 도입할 생각이다.
정의 - 도입기 - 성숙기 - 안정기 그 중 이번 글은 코드 리뷰에 대한 정의에 대한 내용이며 코드리뷰를 하기 위해서 각각의 팀원들 팀장들은 어떻게 해야 할지에 대해서 정리 할 것이다.
코드리뷰란
- 개발자가 작성한 코드를 다른 사람들이 검토하고 피드백을 전달하며, 다시 작성자가 반영하는 과정을 말한다.
이 과정을 통해 서비스의 기술적인 구현 부분에 대해 공유 및 습득 할 수 있으며, 일관된 아키텍처를 유지하고, 문제를 해결할 수 있는 새로운 관점을 발견할 수도 있다 - 또한 더 나아가 잠재적인 장애 및 버그를 배포전에 발견하여 전반적인 서비스 운영 비용을 절약 할 수 있다.
- 가장 중요한 핵심은 단순히 코딩 스타일을 일관되게 유지하거나, 예상되는 문제를 일찍 파악하는데 끝나지 않고 코드에 대한, 역할에 대한 책임이 개인에 있지 않고 우리 모두에게 우리 모두의 개발자에게 있다는 문화를 만드는 데에 있다고 할 수 있다.
뱅크샐러드
“소프트웨어를 유지보수하는 조직에서 코드 한 줄을 변경한다고 했을 때, 코드리뷰가 도입되기 전에는 그러한 변경의 55% 정도가 문제를 일으켰다. 그러나 리뷰 과정이 도입된 이후에는 그러한 변경의 2% 정도에서만 문제가 발생했다.” - 코드 컴플릿, 스티브 맥코넬
코드리뷰의 경험담
꼰대집합소에서의 코드리뷰
생각해보면 첫 회사를 제외한 모든회사에서 형식적이지 않지만 코드리뷰를 어떤 형태이든 계속 진행 해왔었다. 그 회사들중 이전 회사에서 매주 수요일 코드리뷰를 각잡고 진행 해본 경험이 있엇는데...ㅠㅠ
그때 코드리뷰는 매주 5명이 날 단두대에서 시험하는ㅠㅠ 살얼음판을 걷는 경험있었다.
그 당시 코드리뷰는 매주 목요일 2시부터 ~ 3시 한 주 동안 내가 작성한 코드를 일일이 까보면서 5명의 꼰대 개발자들이 하나하나씩 파해쳐 갔다ㅠ
그 기분은 마치 정말 명동 거리에서 속옷 하나도 안입고 모든 사람들이 날 쳐다보는 느낌이였을까?
물론 그렇게 하나 하나 보면서 코칭해주면 실력은 늘겠지만 가장 싫었던거는 그 5명의 개발자들의 태도였다.
가장 많이 들었던 소리는 "응~ 남대리 그거 아니야~", "응 남대리 너 코드만 이상해"
충격적이겠지만 한꼰대는 정말 출신 대학교 가지고 너희 학교애들은 쓰레기야 매일 하루에 한번씩 들었다ㅎㅎㅎ
물론 내가 개발적 항상 부족한 사람이기에 절대적으로 잘했다고 볼 수 없지만. 매일 저런 소리를 들으니 있던 내 자신감도 자존감도 하락세를 걷다 못해 내가 개발자를 꼭해야 하나 싶은 생각이 마구마구들었다.
내개 생각하는 코드리뷰 문화
- 배움의 문화를 만들어가기 위한 노력
Egoless Programming 10계명
- 당신이 실수 할 것이라는 것을 이해하고 받아들여라
우리는 완변한 존재, 사람이 아니기 때문에 누구나 다 실수 한다. 그런 그 실수 들이
제품이 출시 되기 전이나 배포 되기전 그 실수가 일찍 찾아내는 것이다.
그러니 우리는 배우고, 웃으며 털어버리고, 받아들이고 나아 가야한다.
- 당신과 당신의 코드를 동일시하지 마라
코드리부에서 중점은 코드의 문제를 찾아가는것이지 당신에게! 너를위해 인신공격하는것은 아니다.
그 문제들에 대해서 발견해서 찾는 것이니 개인적인 공격으로 받아 들여서는 안된다.
(설사 인신공격은 절대적으로 하지 말아야 한다.)
- 당신이 얼마나 많은 무공을 알고 있든지 간에, 누군가는 더 많은 것을 알고 있다.
그런 사람들은 만약 당신이 부탁한다면 새로운 무공을 가르쳐 줄 것이다. 그것들이 필요 없다고 느껴지는 때일 수록, 다른 사람들 부터 피드백을 찾고 또 받아 들여라.
- 협의 없이 코드를 다시 만들지 마라
코드를 고치는 것과 코드를 다시 만드는 것에는 미세한 차이가 있다. 그 차이를 알고, 코드리부의 과정에서 스타일을 지켜가는 체인지를 만들도록 노력해야한다. 독불장군은 곤란한다.
- 자신보다 많이 알지 못하는 사람이라 해도 존경과 인내로 대하라.
개발자를 상대하는 일반의 non technical 한 사람들은 개발자들이 잘되면 프리마돈나이지만, 최악의 경우엔 떼쟁이 아기라는 의견을 가지고 있다. 분노와 조급함으로 인해 이런 편견이 굳어지도록 하지 말자.
- 이 세상에 존재하는 유일한 고정 값은 “변화” 그 자체이다.
열린 마음으로 미소를 지으며 변화를 받아들이자. 요구사항, 플랫폼, 새로운 도구들은 싸워 없애야하는 불편함이 아니라 새로운 도전으로 바라보자.
- 지위가 아니라 지식이야 말로 권위를 만드는 유일한 그거이다.
지식은 권위를 낳고, 권위는 존경을 낳는다. Egoless 한 방법에 대한 존중을 받고자 한다면, 지식을 쌓아가라.
- 당신이 믿는 것을 위해 투쟁하라. 하지만 패배는 겸허히 받아들여라.
때때로 당신의 생각들이 기각될 수 있다는 걸 이해해라. 나중에 당신이 옳았다고 밝혀지더라도, 복수를 하려 하거나 '거 보시오 내가 뭐랬소' 라고 한 두번 이상 말하지 말아라. 아쉽겠지만 기각된 당신의 아이디어를 순교자처럼 취급하거나, 슬로건처럼 쓰는 일이 없도록 하라.
- 방안에 박혀 혼자 있는 사람이 되지 마라.
자기 방에서만 혼자 코딩하다가 콜라가 필요해 잠깐 나타나는 그런 사람이 되지 마라. 방 안에서 혼자 코딩하는 사람은 연락하기도 어렵고, 잘 보이지도 않고, 통제 불능이다. 열려있고, collaborative 한 환경이 아니다.
- 사람보다 코드 그 자체를 비판하라.
코드가 아닌 코드를 작성한 사람에게 친절하라. 가능한한, 당신의 모든 리뷰 코멘트를 긍정적인 방향으로 코드 개선에 중점을 두고 이야기하라. 코멘트를 팀의 표준, 프로그램의 스펙, 나아진 성능등과 연결지어 얘기하라.
