한빛출판네트워크

제공 : 한빛 네트워크
저자 : Emma Jane Westby
역자 : 김인범(http://revolutionist-inbum.tistory.com)
원문 : Six Ways to Make Your Peer Code Reviews More Effective

비평은 디자인 학교의 주요산물이다. 당신은 어떻게 비평이 그들을 디자이너로 만들거나, 어떻게 그들의 삶을 망가뜨리는지에 대해 디자인 학생의 몇몇 블로그 보다 많은 것을 발견할 것이다. "비평"을 "코드리뷰"로 대체하고 당신은 오픈소스 커뮤니티에서 불안감으로 채워진 많은 블로그 포스트들을 발견할 가능성이 높아진다. 또는, 더 가능성 있는 사항으로, 당신은 특히 가혹한 텍스트 기반 트랜잭션에 대한 기여자(contributor)들의 참여 부족을 알아챌 수 있다.

어느 순간 우리가 원래의 의미를 잊은 단어 중 하나는 "비평"이다. 위키피디아에 따르면 critique(비평)은 문서화된 또는 구술 담론의 훈련되고 체계화된 분석의 방법이다.

좋은 비평은 긍정적인 피드백의 두 단면 사이에서 부정적인 피드백을 감싸고 있는 긍정적인 피드백 샌드위치보다 더 좋은 것이다. 효과적인 비평이 되기 위해서는 세 가지 요소가 적절히 위치해야 한다.

1. 평가를 위해 합의된 프레임워크

2. 검토 객관성

3. 자신의 일에서 분리된 작성자

정량적 검토

정량적인 검토는 가장 수행하기 쉬운 것이다. 일반적으로 프로젝트의 코딩 기준은 정량적이다. 정량적 검토의 질문에 대한 답변은 다음과 같다. 이 코드가 코딩 기준에 따라 구성된 것인가? 코드가 어떤 성능적 회귀를 발생시키지는 않는가? 정량적 평가는 쉽게 측정될 수 있다. 검토된 코드는 올바를 수 있거나 비호환 적일 수 있다. 정량적 검토의 발견은 일반적으로 논의하기 힘들다. 정량적인 프레임워크를 고정적으로 가지는 것은 종종 당신의 프로젝트가 고정적으로 자동화된 테스트를 넣음으로써 검토 시간을 확보할 수 있음을 의미한다. 어느 쪽이 더 어려운 유형의 리뷰를 위해 시간을 남길 것인가? 질적 리뷰이다.

질적 리뷰

질적 리뷰를 위한 프레임워크는, 그것이 프로젝트의 가치를 다루는 데 있어 주관적인 생각을 위한 공간이기 때문에, 만들어내기 굉장히 어렵다. 의견을 위한 공간이 있다. 두 사람은 비록 전혀 동의하지 않음에도 불구하고, 바로 동시에 (공간에) 있을 수 있다. 질적 프레임워크는 대부분의 프로젝트들이 시도해보지 않은 것을 만들어내는 것이 무척 어렵다. 그러나, 효과적인 질적 프레임워크는 코더와 리뷰어 모두 그들의 능력을 향상시킬 수 있도록 돕는다. 질적 프레임워크는 비전문가에게 그들이 리뷰하는 코드 안에서 찾아야 할 것은 무엇인지를 가르친다. 질적 검토 중에 제기된 질문이 포함될 수 있다. 이 코드는 우리가 이미 프로젝트 어딘가에서 봤던 패턴을 구현하는지? 코드가 다른 상황에서 다시 사용할 수 있도록 충분히 추상화되었는지?

명확한 의사소통의 어려움

평가를 실시하는 것은 본직적으로 도덕적 판단 활동이다. 좋은 리뷰어들은 그들의 의견을 표현하여, 너무 많이 입력하는 것 없이 해당 작업을 언급된 프레임워크에 묶을 수 있다. 또한 동등하게 중립적인 방식으로 대응하는 작업의 작성자에게 공간을 제공한다.

완벽한 세상에서는 리뷰어가 말하기 원하는 것과 작성자가 들은 것 사이에 완벽한 연결이 존재할 수 있다. 아주 종종 이러한 일은 - 특히 우리의 유쾌한 국제 FOSS 기여자 풀(pool)에서 - 발생하지 않는다. 사람들은 종종 그들의 두 번째 또는 세 번째 언어로 쓰고(읽고) 있다. 의사소통은 어렵고, 중립적인 의사소통은 특히나 더 어렵다. 사실 중립적인 의사소통은 종종 적대적인 편견 - 우리가 모호한 의사소통을 적대적으로 해석하는 것을 유발하는 인간의 특성 - 에 의해 희생되곤 한다.

유용한 팁들

다음의 단순한 가이드라인들을 따르면 모든 사람을 위한 리뷰어 경험을 향상시킬 수 있다. 시작하기 전에, 올바른 유형의 평가가 수행될 것임을 확인하라. 일단 커뮤니티가 그러한 특성에 동의하게 되고 광범위한 세부 구현 사항이 프로젝트에 적합하면, 코드가 쓰여지고 그 뒤에 리뷰가 진행되어야 한다. 리뷰를 진행하는 동안, 다음의 간단한 팁들을 따를 것인지를 보장하라.

• 작업의 범위에 당신의 리뷰를 제한하라. 효과적인 리뷰는 현재 작업중인 문제에 초점이 맞춰져 있는 것을 말한다. 당신이 추가적인 관심이 필요하다고 생각되는 업무 범위 밖의 어떤 일들(예를 들어, 티켓)에 대해서도 추가 조치 항목들을 만들어라.
  
  
• 리뷰를 상세화하라. 특별한 줄 또는 구성요소를 당신의 리뷰에서 제시하라. 진술을 일반화하고 광범위하게 만드는 것을 피하라.
  
  
• 실천 가능한 리뷰를 만들어라. 만약 당신이 요청한 변화를 구현할 방법을 즉시 명확하게 할 수 없다면, 해당 내용을 리뷰에서 지워라.
  
  
• 적절한 시기에 당신의 리뷰를 제공하라. 당신이 리뷰를 위해 오래 대기할수록, 작성자는 더욱더 왜 그런 결정이 이루어졌는지를 기억으로부터 이끌어내야 한다. 나는 우리가 함께 일을 진행할 수 있도록 내 동료 중 한 명과 함께 리뷰 시간을 조정하기 시작했다. 이것이 항상 가능하거나 매력적인 것은 아니지만, 작은 팀 단위에서는 효과적이다.
  
  
• 리뷰의 일부로서, 해당 문제에 대하여 코더에 의해 소요되는 시간을 인지해야 한다. 때때로, 세 라인의 변화는 작업에 몇 시간이 걸릴 수 있다. 침착할 수 있는 시간을 가지고, 해당 작업에 대해 시간이 소요되는 것을 인정하라.
  
  
• 감사하게도, 특히 오픈 소스 프로젝트에서 기여자는 일반적으로 그 어떤 것도 제출할 것을 요구 받지 않는다. 특히 직장에서 직장 동료들은 때때로 그들이 진정으로 싫어하는 프로젝트의 일부에 참여하도록 강요 받는다. 감사할 시간을 가져라. 그것은 모든 차이를 만들어 낼 수 있다.