Stop Nitpicking in Code Reviews (번역)

* Nitpick: 작은 문제에 대해 지적하는 일

유튜브에서 개발 영상을 보다가 아래 영상을 통해 아래 글을 보게되었다.
어느정도 공감이 가는 내용이라서 번역해보았다.

관련 영상: https://youtu.be/08NlhU4gzdY?si=7gua1YZ3QoIhR40d
원문: https://blog.danlew.net/2021/02/23/stop-nitpicking-in-code-reviews/

Stop Nitpicking in Code Reviews

 

TL;DR

1. 문제:

• 코드 리뷰에서 과도한 nitpicking은 코드 품질을 저하시키고 관계를 손상시킬 수 있습니다.

2. 해결책:

• 이 문제를 해결하기 위해 nitpicking을 중단하고 불완전성을 수용하세요.
• 코드 리뷰에서 소음을 줄이고 nitpicks를 처리하기 위해 자동화를 사용하세요.

3. 영향:

• 이 변경으로 코드 품질과 팀의 화합이 향상됩니다.
• 이것은 코드 리뷰에서 신호 대 잡음 비율을 향상시키며 팀 구성원 간에 더 긍정적인 관계를 유발합니다.

 

코드 리뷰에서의 nitpicking을 그만 두세요

내가 최근 직장에서 한 가지 가장 좋은 변화 중 하나는 코드 리뷰에서의 nitpicking을 그만 두기로 한 것입니다.

Nitpicking이란 잘못된 코드가 아니라 안 좋아 보이는 코드를 지적하는 것입니다.

1) 더 적합한 단어를 사용할 수 있는 변수 이름을 지적하거나
2) 더 깔끔하게 포맷팅할 수 있는 조건문을 지적하거나
3) 논리를 약간 더 간단하게 만들 수 있는 부분을 지적하는 것입니다.

Nitpicks은 본질적으로 더 나은 코드로 이어지지 않으며 개발자에게 가르침을 주지도 않습니다. 기술적으로는 개선 사항이지만 의미가 크지 않은 작은 변화입니다.

나는 우리 코드베이스가 완벽해야 한다고 생각했고 내 마음속에서 이러한 nitpicking이 그것이 이루어지는 중요한 부분이라고 생각했습니다. 나는 이전에 매우 철저한 코드 리뷰를 진행했었으며 아키텍처와 버그에 대한 의견 뿐만 아니라 nitpicking이 많은 리뷰를 채웠습니다. Nitpicks은 종종 다른 의견들을 압도했고 큰 우려사항마다 nitpicking이 열두 개씩 있을 수 있었습니다.

이러한 나의 습관은 나를 가장 인기 있는 동료로 만들지는 않았습니다. 그와는 멀었죠. 그 때는 알지 못했지만 나의 완벽주의는 유해했습니다. 가장 나쁜 경우에는 사람들을 화나게 하고, 그 감정은 코드 리뷰 자체를 훨씬 넘어서 지속되었습니다.

---

코드 리뷰에서의 nitpicking 중단

몇 년 전, 한 동료가 우리가 nitpicking을 완전히 중단해 보는 것이 어떤 일이 발생하는지 살펴보는 것을 제안했습니다. 처음에 나는 이 제안에 반박했습니다. 왜 나쁜 코드가 코드베이스에 들어가게 허용하고 싶을까요? 그러나 결국 우리는 한 달 동안의 실험에 동의했습니다.

한 달이 끝날 때, 놀랍게도 상황은 분명 이전보다 나아졌습니다. 정말 좋았기 때문에 정책을 계속할 것인지에 대해 거의 논의조차 거의 없었습니다. Nitpick을 그만 두는 것은 분명한 개선 사항이었기 때문에 자연스레 유지하는게 되었습니다.

우리가 경험한 두 가지 큰 이점이 있었습니다:

첫째, 우리는 신호 대 잡음 비율(Signal to Noise Ratio)이 크게 향상된 것을 보았습니다. 5개의 nitpicks와 해결해야 할 중요한 문제 하나가 발생하는 코드 리뷰를 상상해보십시오. 도움이 안되는 여러 nitpicks를 해결하는 소란 속에서 중요한 코멘트는 덜 중요하게 느껴질 수 있거나 심지어 놓칠 수 있습니다.

nitpicks가 없으면 중요한 코멘트 하나만 언급됩니다. 모든 주의를 거기에 기울이며, 이는 올바른 것입니다. 중요한 것에 더 집중 하게 되고, 중요하지 않은 것은 무시됩니다.

둘째, 이것은 코드 리뷰와 그것을 수행하는 사람들과의 관계를 개선했습니다. 온라인에서 코드 리뷰를 개인적으로 받아들이지 않아야 한다고 말하는 사람들이 많이 얘기합니다.

• 코드 리뷰는 개인적으로 받아들일 필요가 없다
• 코드가 비판되는 것이 아니라 사람이 비판되는 것이 아니다, 등.

그것은 헛소리입니다. 나는 10년 동안 코드 리뷰를 받아왔고 누군가 나의 실수를 지적하거나 내 코드 디자인에 반발할 때 아직도 상처받습니다.

상상해보십시오: 당신이 풀 리퀘스트를 시작하고 첫 번째 리뷰어가 12개의 nitpicks을 지적합니다. 당신의 자연스러운 반응은 절제된 수용이 아니라 분노일 것입니다. 당신이 하고 싶은 것은 이 코드를 병합하는 것뿐이지만 누군가는 당신이 병합을 하기 전에 필요없어보이는 일들을 먼저 하라고 시키는 것 처럼 느낍니다. nitpicks를 수정하고 리뷰를 보내도 여전히 병합할 수 없을 것입니다. 더 많은 nitpicks를 리뷰어가 발견했기 때문이죠! 악!

개발자들은 냉혹한 논리만으로 이뤄진 사람이라고 생각하지만 사실 우리는 피할 수 없는 감정과 기분을 가진 사람들입니다.

예전의 완벽주의 nitpicker 시절의 나는 실제로 무엇을 하고 있었을까요? 주요 효과는 코드베이스를 개선하는 것이 아니었으며 사람들은 그들의 코드에 화를 내고 나에게 화를 냈습니다. 그 결과로 나의 피드백에 대한 태도가 나빠지고 동료와의 관계가 악화되었습니다.

nitpicks를 중단한 몇 년 후에 사람들은 코드 리뷰에서의 피드백을 훨씬 더 잘 받아들이며 나를 훨씬 덜한 사람으로 생각합니다. 이전과 비교하면 낮과 밤만큼의 차이입니다.

---

궁극적으로, 우리 코드베이스는 nitpicking 부족으로 인해 고통받지 않았습니다. 오히려 팀으로서 우리는 더 잘 협력하고 리뷰에서 코드 디자인의 중요한 부분에 집중하므로 이전보다 나아집니다.

그렇지만 이전에 nitpick하는 것을 여전히 신경 쓰는 경우 어떻게 해야 할까요? 제 제안은 그렇다면 그것을 자동화하는 것입니다. CI에 lint 검사 및 코드 스타일 강제를 추가하십시오. 도구를 사용하면 문제를 사전에 확인할 수 있습니다. 또한 자동화가 당신이 잘못되었다고 알려줄 때는 개인적인 지적이 아니기 때문에 그 결과가 어떻든 덜 짜증이 납니다 (유닛 테스트 실패와 누군가가 당신을 비난하는 것과 같이).

하지만 정말로: 당신이 이전처럼 모든 코드 라인이 완벽해야 하는 사람이라면, 조금 놓아보세요. 코멘트하기 전에 자신의 'LOGAF (Level of give a fxxx)'를 확인하십시오. 어쩌면 어떤 코드는 완벽하지 않을 수 있지만, 당신의 코드베이스와 팀의 화합은 그것을 통해 더 좋아질 것입니다.