존중하는 코드리뷰

• from: https://chromium.googlesource.com/chromium/src/+/master/docs/cr_respect.md

• 책을 읽다가 구글 크로미움 코드리뷰 문화에 대한 좋은 글이 있어 내용을 번역하고, 간단히 리뷰 해 보았다.

해야할것

능력있고, 선의를 가지고 있다고 가정하라.

• 우리는 유능한 사람들을 끌어 들인다.

• 즉, 그들이 틀렸다고 하더라도 무능력이 아니라 정보 부족으로 비롯된 것일 가능성이 높다.

• 나쁜 CL은 일반적으로 당사자중 한 사람이 상대방이 알지 못하는 정보를 소유하고 있다는 것을 의미한다.

직접 대면으로 토론하기

• 의견이 일치하지 않은 경우 빠른 대면/영상/IM 채팅을 통해 진행 상황을 정리하라.

• 메일로 오랜 시간동인 왔다 갔다 하는 것보다 직접 만나서 "오, 몰랐어요"라고 말하는 것이 훨씬 쉽다.

• 다른 검토자와 동의하지 않는 경우 "대면"이 이중으로 적용된다.

• 그리고 리뷰 결과를 꼭 기록하자.

  
  

• 개인적 경험

  • 개인적인 경험으로 대만의 개발팀과 화상통화를 통해서 이야기한 적이 있었다.

  • 화상통화를 하나의 결정을 하기 위해서 4시간이 걸렸지만, 면대면으로 만나서 이야기 했을때 약 2시간만에 개발 상호간의 이견차를 대부분 해소할 수 있었다.

  • 이러고 보면 글로 의사소통 하거나, 바턴을 주고 받는 방식으로 한번씩 이야기하는 방식으로는 의사결정에 많은 시간이 소모된다.

  • 왜냐하면 상대의 의도를 파악하고, 협의할때에는 그림, 언어, 바디 랭귀지가 훨씬더 좋은 커뮤니케이션 수단이기 때문이다.

왜인지를 설명하라.

• 일부 코드가 잘못되었다는 것이 당신에게는 확실히 잘못된 것으로 파악할 수 있지만, 작성자는 분명하지 않을 수 있다.

• 그렇지 않았다면 그들은 그렇게 작성하지 않았을 것이다.

• 제발 "이건 틀렸어" 라고 말하지 말길 바란다.

• 대신 올바른 방법이 무엇인지 적어도 설명을 하라.

• 또는 그들이 다르게 일해야하는지 이유를 설명하라.

• 조금이라도 불확실하다면 "어쩌면 내가 뭔가를 놓치고 있을지도 모르지만..." 이 도움이 되는 문장이다.

왜 인지를 물어라.

• 작성자가 특정 방식으로 작업을 수행하는 이유가 명확하지 않은 경우 특정 변경을 수행한 이유를 자유롭게 물어보라.

• 모르는 것도 괞찮다. "왜" 라고 묻는 것은 나중에 질문에 답하는 데 도움이 될 서면 기록으로 남길 수 있다.

• 그리고 때때로 "왜 그렇게 하기로 결정 했는지요? 궁금합니다." 라고 묻는 것은 작성자가 자신의 결정을 다시한번 생각해 볼 수 있는 기회를 제공한다.

  
  

• 개인적 경험

  • 왜 라고 질문하는 습관은 개발자에게는 특히나 중요한 사항인것 같다.

  • 기획서에 모호한 용어가 있다면, 잘 이해가 가지 않는 기능이 있다면, 왜? 이 기능을 필요로 하는 이유에 대해서 물어보면 이 기능이 정말 필요한지 얼마나 중요한지 알게 되는 경우가 많았다.

  • 우리가 만드는 소프트웨어는 목적성을 갖지 못하면 필요없는 짓을 하는 것과 다름 없는 것과도 같다고 생각한다.

끝을 찾아라.

• 깔끔한 것을 좋아한다면 완벽해질 때까지 계속해서 코드 리뷰를 검토하고 필요 이상으로 오래 끌고 싶은 유혹을 느낄 것이다.

• 하지만 수신자 에게는 영혼을 죽이는 일이다. "LGTM(Looks good to me)"은 "내 불멸의 영혼을 보증한다. 이것은 결코 실패하지 않을 것이다" 가 아니라. "나에게 좋아 보인다"는 의미이다.

• 보기 좋다면 계속하라. (철저하지 말라는 뜻이 아니라, 판단이다.) 그리고 더 큰 리펙토링이 있다면 새로운 CL(Change List)로 옮겨라.

합리적인 시간 내에 회신하기

• 시간대와 다른 그눔시간을 염두에 두고 리뷰 대상자를 오래 기다리게 두지 마라.

• 만약 24시간 이내 리뷰를 받을 수 없는 경우 CL에 짧은 코멘트를 남겨라 (가능한경우)

• 만약 해당 기간을 놓친 경우 검토 대상자가 알림 메시지를 IM(Instance Message)으로 보내면 예의를 갖추길 바란다

• 만약 며칠 이상 휴가나 기타 OOO에 있는 경우 Chromium 코드 검토 도구에서 이를 표시하도록 닉네임을 설정하라. (OOO까지)를 추가하라.

• 당신에게 코드리뷰를 보내는 모든 사람이 당신의 캘린더를 볼 수 있는 것은 아니라는 점을 기억하라.

  
  

• 개인적 경험

  • 코드리뷰를 요청하거나, 머지 리퀘스트를 요청했을때, 빠른 피드백을 받지 못한다면 다양한 방면으로 손해가 발생하는것을 많이 보았다.

  • 코드의 버전 차이가 나기 시작하고, 코드리뷰를 받는동안 다른 일을 하고 있다면 컨텍스트 스위칭을 하기 위한 시간적인 손해도 많게 된다.

  • 특히나 코드의 버전이 차이가 나면, 연관된 기능들이 푸패하기 시작한다. 리뷰가 되지 않는 기능을 기다리다 다시 만드는 경우나, 우회하는 경우가 발생하면서 낭비가 발생하기도 했다.

긍정적인점 이야기하기

• "결함을 모두 찾아라" 는 마임가짐으로 빠지기 매우 쉽지만 긍정적인 점을 인정하는 것은 상황을 예의바르게 유지하고 받는 사람의 하루를 밝게 만드는 데 도움이 된다.

• 가짜 미소일 필요는 없지만 좋은 결정이 있거나 누군가가 정말 지저분한 작업을 수행하는 경우 좋은 일임을 인정하라.

• 반대로 리뷰어에 "감사합니다" 라고 말하는 것도 때로는 좋은 일이다.

하지말것

사람을 부끄럽게 하지마라.

• "어떻게 이걸 못봐어?" 라고 말하는 것은 도움이 전혀 되지 않는다.

• 동료들이 최선을 다하지만 때때로 실수를 한다고 가정한다. 그래서 실수를 발견하기 위해서 코드리뷰를 하는 것이다.

• 흠잡을데 없는 CL은 굉장하지만, 결함이 있는 CL이 일반적인 것이다.

  
  

• 개인적 경험

  • 개발자들 토론장이 기술 자랑의 무대가 되는 경우를 많이 봤다.

  • 한때는 내가 그 기술 자랑 무대의 주인공이었던 적도 있었다.

  • 그런데 그때마다 후회하고, 발견한 내가 놓치고 있었던 사실은, 토론을 왜 하는지, 현재 프로젝트의 목적을 잊어버리고 있었다는 사실이다.

  • 그리고 내가 토론에 이겼다는 마음 다음에 오는 공허함은 가장 부끄러운 단면 이었던 기억이 난다.

극단적 이거나 매우 부정적인 언어를 사용하지 마라.

• 검토중인 변경 사항에 관한 것이든 주변 코드에 관한것이든 "제정신인 사람이라면 이렇게 하지 않을 것이다" 또는 "이 알고리즘은 끔찍합니다" 와 같은 말을 하지마라.

• 당신이 원하는 것을 하도록 리뷰 받는 사람을 위협할 수 있지만 장기적으로는 도움이 되지 않는다.

• "이것은 좋은 시작이지만, 약간의 작업이 필요하다." 혹은 "이것은 약간의 정리가 필요하다." 라고 말하는 것이 더 좋다.

• 사람이 아니라 코드에 대해서 토론하라.

  
  

• 개인적 경험

  • 부정적인 언어도 사기를 꺽지만, 무관심이나 경멸의 눈빛도 조심해야한다는 것을 경험상 알게 되었다.

  • 사람을 움직이기 위해서는 핀찬 보다는 칭찬이 더 효과적이고 긍정적인 결과를 낸다는건 만고의 진리이며, 잘 안 되도 노력해야한다.

  • 개발자라고 시니컬하고 논리적이지 말자~. 이런 행동은 초보자일때만 하는 짓이다. 시간이 지나면서 일은 혼자하는 것이 아니라 많은 사람의 노력으로 만들어지는 것을 잊지 말아야 한다.

툴 사용을 꺽지마라.

• 만약 사람들이 자동회된 포매터를 사용한다면, 일관된 코드 기반을 보장하기 위해 서식 지정 권한을 기꺼이 포기하는 것에 감사하라.

• 자신의 기본 설정을 적용하기 전에 신중하게 생각하라.

• 사람들이 사소한 변경 사항에서 버그를 찾기 위해 트라이 봇을 사용한다면 낙담시키지 마라.

• 그들이 더 많은 문제를 해결할 수 있는 더 많은 공간을 만들기 위해 기계 시간을 교환하고 있다는 사실에 오히려 감사하라.

  
  

• 개인적 경험

  • 툴 사용을 막는 것은 아마 기술적 뒤쳐짐에 대한 두려움의 행동이 아닐까 싶다.

  • 사실 다른사람이 매우 편리한 툴을 쓰고 있는데, 그 원리를 이해하지 못하는 경우 반감을 자주 갖게 되는 현상을 알게 되었다.

  • 그럴때마다 나를 돌아보면, 기술적인 무지함이 그런 불안감을 만들어 내고 부정적인 시선으로 바라봤다는 것을 깨달은 적이 많았다.

사소한 것 오래끌지 않기

• 이 결정이 장기적으로 정말 중요한지 또는 주관적인 선호를 강요하고 있지 않는지 항상 스스로에게 물어보라.

• 맞으면 기분이 좋지만 두 참가자 중 한명만이 그 게임에서 이길 수 있다.

• 중요하지 않은 경우 동의하지 않고 계속 진행하라.

  
  

• 개인적 경험

  • 내가아는 지인의 회사에서 코드 리뷰를 하면서 상대를 인격적으로 공격하는 분위기에 대해서 자주 들었다.

  • 영어가 문법에 맞지 않는다는둥, 단어가 이게 아니라는둥.

  • 코드리뷰에서 가장 많이 나오는 것이 이런 영어문법에 대한 지적이다.

  • 그리고 코드 작성 방법에 대한 논쟁으로 쓸데없는 시간을 허비하는 코드리뷰를 많이 하는것 같다.

  • 그런데 나의 생각은 "영어 공부는 영어학원에 가서 하시라." 라고 말하고 싶다.

    
    

• 코드리뷰의 첫번재는 의도와 목적이 무엇인지 물어보고 그것을 서로 가장 잘 이해하는 용어 혹은 메타포를 찾고, 목적을 가장 잘 수행할 수 있는 올바른 아키텍처와 모델을 찾는 것이라는 것을 잊어 버리지 말아야한다.

• 쓸데없는 코드리뷰를 절약하면 그만큼 개발 시간을 늘일 수 있다. 5명이 2시간 코드 리뷰를 절약하면 10시간의 개발 시간을 확보할 수 있음을 꼭 깨달아야 한다.

• 그리고 코드 작성법은 꼭 코드작성 규칙을 문서화고 숙지하는 노력보다, 자동 포매터를 사용하는것이 훨씬 생산적이다~.

용어

• CL

  • Change Log (변경 이력)

• LGTM

  • Looks Good To Me (나에게는 좋아보임)

• IM

  • Instant Message (인스턴트 메시지 - DM)

• Bikeshedding

  • C. Northcote Parkinson이 사소함의 법칙으로 만든 용어

  • 개발팀이 자전거 주차장의 색상과 같이 시스템의 사소하거나 중요하지 않은 세부 사항에 과도한 시간과 노력을 할애할 때 발생한다.

WrapUp

• 개발을 진행하고 경력이 쌓이면서 조직에 위와 같은 그라운드 룰이 꼭 필요함을 느낀다.

• 특히나 태도에 대한 그라운드 룰은 조직을 긍정적으로 만들어내기 위해서 반드시 신중하게 도입하고 실천해야하는 사항이 아닐까 생각이 든다.