팀에 건전한 코드 검토 사고방식 가져오기

'코드 검토'는 개발자로서 여러분 과 동료가 함께 작업하고 최신 코드가 릴리스되기 전에 버그를 찾는 개발 프로세스의 한 순간입니다. 그런 순간에 당신은 코드 작성자가 될 수도 있고 검토자가 될 수도 있습니다.

코드 리뷰를 할 때 찾고 있는 것이 무엇인지 잘 모를 수 있습니다. 반면에 코드 리뷰를 제출할 때 무엇을 기다려야 할지 모를 수도 있습니다. 양측 사이의 이러한 공감 부족과 잘못된 기대는 불행한 상황을 촉발하고 양측 모두에게 불쾌한 경험으로 끝날 때까지 프로세스를 서두르게 할 수 있습니다.

이 기사에서는 코드 검토 중에 사고 방식을 변경하여 이 결과를 변경하는 방법을 공유합니다.

• 팀으로서
• 작가로서
• 리뷰어로서

팀으로 일하기

협업 문화 조성

시작하기 전에 코드를 검토해야 하는 이유의 가치를 이해하는 것이 기본입니다. 지식 공유와 팀 결속은 모두에게 유익하지만, 잘못된 사고 방식으로 수행할 경우 코드 검토는 불쾌한 결과를 초래하는 엄청난 시간 소비가 될 수 있습니다.

팀 태도와 행동은 다른 사람의 경험에 관계없이 학습 및 공유라는 공통 목표를 가지고 비판단적 협업의 가치를 수용해야 합니다.

견적에 코드 리뷰 포함

완전한 코드 검토에는 시간이 걸립니다. 변경하는 데 일주일이 걸렸다면 코드 검토가 하루도 채 걸리지 않을 것으로 기대하지 마십시오. 그냥 그렇게 작동하지 않습니다. 코드 리뷰를 서두르거나 병목 현상으로 보지 마십시오.

코드 리뷰는 실제 코드를 작성하는 것만큼 중요합니다. 팀으로서 워크플로에 코드 검토를 포함 하고 코드 검토에 소요되는 시간에 대한 기대치를 설정하여 모든 사람이 동기화되고 자신의 작업에 대해 확신을 가질 수 있도록 하십시오.

지침 및 자동화로 시간 절약

일관된 기여를 보장하는 효과적인 방법은 프로젝트에 Pull Request 템플릿을 통합하는 것입니다. 이것은 작성자가 완전한 설명과 함께 건강한 PR을 제출하는 데 도움이 됩니다. PR 설명은 변경 목적, 이유 및 재현 방법을 설명해야 합니다. 스크린샷과 참조 링크(Git 문제, 디자인 파일 등)는 자명한 제출을 위한 최종 수정입니다.

이 모든 작업을 수행하면 검토자가 더 자세한 내용을 요구하는 초기 댓글을 방지할 수 있습니다. 코드 리뷰를 덜 까다롭게 보이게 하는 또 다른 방법은 리뷰어가 참여하기 전에 린터를 사용하여 코드 형식 및 코드 품질 문제를 찾는 것입니다. 검토 과정에서 반복적인 주석을 볼 때마다 이를 최소화할 수 있는 방법을 찾으십시오(더 나은 지침이나 코드 자동화를 통해).

학생 유지

누구나 코드 검토를 수행할 수 있으며, 직급에 상관없이 누구나 코드 검토를 받아야 합니다. 피드백을 배우고 지식을 공유할 수 있는 기회로 감사히 받으십시오. 모든 피드백을 방어적인 반응이 아닌 열린 토론으로 보십시오 . Ryan Holiday는 다음과 같이 말합니다.

“아마추어는 방어적이다. 전문가는 배우는 것(심지어 때때로 나타나는 경우도 있음)이 즐겁다고 생각합니다. 그들은 도전과 겸손을 좋아하며 지속적이고 끝없는 과정으로 교육에 참여합니다. (...)”

— 라이언 홀리데이, 자아는 적

학생이 되는 것을 그만두는 순간 지식이 약해지기 때문에 겸손을 유지하십시오.

리뷰어 선정 기술

제 생각에 리뷰어를 선택하는 것은 팀으로서 효과적이고 건전한 코드 리뷰를 위한 가장 중요한 결정 중 하나입니다.

동료가 코드 검토를 제출하고 무의식적으로 프로세스 속도를 높이고 가능한 최고의 코드를 제공하거나 모든 사람이 코드 변경에 대해 알도록 하기 위해 "모든 사람"에 태그를 지정하기로 결정했다고 가정해 보겠습니다. 각 검토자는 알림을 받은 다음 PR 링크를 열고 검토자로 태그가 지정된 많은 사람들을 봅니다. "다른 사람이 해줄거야"라는 생각이 머릿속에 떠오른다. 그러면 코드 리뷰를 무시하고 링크를 닫게 된다.

아직 아무도 검토를 시작하지 않았기 때문에 동료가 각 검토자에게 검토를 수행하도록 상기시켜 줄 것입니다. 즉, 그들에게 압력을 가하는 것입니다. 검토자가 검토를 시작하면 모든 사람이 자신의 의견을 갖고 공통된 합의에 도달하는 것이 악몽이기 때문에 검토 프로세스가 영원히 걸립니다. 한편, 코드를 검토하지 않기로 결정한 사람은 모든 검토 주석이 포함된 수많은 전자 메일 알림을 스팸으로 보내 생산성에 문제를 야기합니다.

이것은 내가 원하는 것보다 더 많이 일어나는 것을 보는 것입니다. 리뷰어로 태그가 지정된 많은 사람들과 함께 요청을 풀고 아이러니하게도 비생산적인 코드 리뷰로 끝납니다.

검토자를 선택할 때 몇 가지 일반적인 효과적인 흐름이 있습니다. 가능한 흐름은 코드에 익숙한 2~3명의 동료를 선택하여 검토자를 요청하는 것입니다. Gitlab 팀이 설명하는 또 다른 접근 방식은 최소 두 명의 검토자가 코드에 동의할 때까지 작성자가 한 명의 검토자를 선택하고 다른 검토자를 선택하는 연쇄 검토 흐름을 갖는 것입니다. 선택한 흐름에 관계없이 검토자가 너무 많은 것은 피 하세요. 동료의 코드 판단을 신뢰할 수 있어야 효과적이고 건전한 코드 검토를 수행할 수 있습니다.

공감하다

개선할 코드 조각을 찾는 것은 성공적인 코드 검토의 일부일 뿐입니다. 동료들에게 공감을 보여줌으로써 건전한 방식으로 피드백을 전달하는 것도 중요합니다.

댓글을 쓰기 전에 다른 사람의 입장이 되어보는 것을 잊지 마십시오. 글을 쓰다 보면 오해받기 쉬우니, 보내기 전에 자신의 말을 잘 살펴보세요. 대화가 어색해지기 시작하더라도 영향을 미치지 않도록 하십시오. 항상 존중하십시오. 다른 사람에게 잘 말하는 것은 결코 나쁜 결정이 아닙니다.

타협하는 방법을 알고

토론이 빨리 해결되지 않으면 개인 전화나 채팅으로 가져갑니다. 현재 변경 요청을 마비시킬 가치가 있는 주제인지 또는 다른 요청에서 해결할 수 있는지 함께 분석합니다.

유연하지만 실용적이고 효율성(전달)과 효율성(품질)의 균형을 유지하는 방법을 알고 있습니다. 팀으로서 타협해야 하는 것입니다. 이 순간에 저는 코드 리뷰를 최종 솔루션이 아니라 반복이라고 생각하고 싶습니다. 다음 라운드에서는 항상 개선의 여지가 있습니다.

대면 코드 검토

저자와 검토자를 쌍 프로그래밍 스타일로 함께 모으는 것은 매우 효과적일 수 있습니다. 개인적으로 코드 검토에 복잡한 변경 사항이 포함되거나 많은 양의 지식 공유 기회가 있는 경우 이 접근 방식을 선호합니다. 이것은 오프라인 코드 검토에도 불구하고, 특히 회의 후 변경이 필요한 경우 토론에 대해 온라인에 댓글을 남기는 것이 좋습니다. 이는 다른 온라인 검토자를 최신 상태로 유지하는 데에도 유용합니다.

코드 검토 결과에서 배우기

코드 검토가 많은 변경을 겪었거나 너무 오래 걸리거나 이미 너무 많은 토론을 했다면 팀을 모아 원인과 취할 수 있는 조치를 분석하십시오. 코드 검토가 복잡한 경우 향후 작업을 더 작은 작업으로 분할 하면 각 코드 검토가 더 쉬워집니다.

경험 격차가 클 때 페어 프로그래밍을 채택하는 것은 지식 공유뿐만 아니라 오프라인 협업 및 커뮤니케이션을 위한 놀라운 결과를 제공하는 전략입니다. 결과가 어떻든 항상 명확한 기대치를 가지고 건강하고 역동적인 팀을 목표로 하십시오.

작가로서

작성자로서 코드 리뷰 작업을 할 때 주요 관심사 중 하나는 코드를 처음 읽을 때 리뷰어가 놀라는 것을 최소화하는 것입니다. 이것이 예측 가능하고 원활한 코드 검토를 위한 첫 번째 단계입니다. 방법은 다음과 같습니다.

조기 커뮤니케이션 구축

너무 많이 코딩하기 전에 미래의 리뷰어와 이야기하는 것은 결코 나쁜 생각이 아닙니다. 내부 또는 외부 기여일 때마다 함께 개선하거나 개발 초기에 약간의 페어 프로그래밍을 수행하여 솔루션을 논의할 수 있습니다.

첫 번째 단계로 도움을 요청하는 것은 잘못된 것이 아닙니다. 사실, 리뷰 밖에서 함께 작업하는 것은 초기 실수를 방지하고 초기 동의를 보장하기 위한 첫 번째 중요한 단계입니다. 동시에 검토자는 향후 코드 검토가 이루어질 것임을 알게 됩니다.

지침을 따르십시오

검토를 위해 풀 요청을 제출할 때 설명을 추가하고 지침을 따르는 것을 잊지 마십시오. 이렇게 하면 검토자가 새 코드의 컨텍스트를 이해하는 데 시간을 할애하지 않아도 됩니다. 리뷰어가 이미 내용을 알고 있더라도 이 기회를 활용하여 작문 및 커뮤니케이션 기술을 향상할 수도 있습니다.

첫 번째 검토자가 되십시오

다른 컨텍스트에서 자신의 코드를 보면 코드 편집기에서 놓쳤던 것을 찾을 수 있습니다. 동료에게 요청하기 전에 자신의 코드에 대한 코드 검토를 수행하십시오. 검토자 마인드를 갖고 실제로 모든 코드 라인을 살펴보세요.

개인적으로 저는 리뷰어를 더 잘 안내하기 위해 제 자신의 코드 리뷰에 주석을 달고 싶습니다 . 여기의 목표는 주의 부족과 관련된 댓글을 방지하고 기여 지침을 따랐는지 확인하는 것입니다. 받고 싶은 것처럼 코드 리뷰를 제출하는 것을 목표로 하십시오.

인내심을 가지고

코드 리뷰를 제출한 후 리뷰어에게 "몇 분 정도만 보세요."라고 요청하고 간접적으로 엄지손가락을 치켜세우는 이모티콘을 갈망하는 새 비공개 메시지로 바로 뛰어들지 마십시오. 동료들에게 일을 서두르려고 하는 것은 건전한 사고방식이 아닙니다. 대신 동료들이 당신이 좋은 코드 리뷰를 제출할 것이라고 신뢰하므로 동료의 워크플로 를 신뢰하십시오. 한편, 그들이 사용 가능할 때 다시 연락할 때까지 기다리십시오. 리뷰어를 병목 현상으로 보지 마십시오. 어려운 일에는 시간이 걸리므로 인내심을 잊지 마십시오.

청취자가 되십시오

코드 검토가 제출되면 의견이 제출되고 질문이 제기되고 변경 사항이 제안됩니다. 여기에서 황금률은 피드백을 인신공격으로 받아들이지 않는 것입니다. 모든 코드는 외부 관점에서 이점을 얻을 수 있음을 기억하십시오.

리뷰어를 적으로 보지 마십시오. 대신 이 순간을 통해 자존심을 버리고 실수를 인정하고 동료들에게 열린 마음으로 배움으로써 다음에 더 나은 일을 할 수 있습니다.

리뷰어로서

미리 계획하십시오

검토자가 되라는 요청을 받았을 때 즉시 일을 중단하지 마십시오. 제가 항상 보는 흔한 실수입니다. 코드를 검토하려면 모든 주의가 필요하며, 코드 컨텍스트를 전환할 때마다 초점을 재조정하는 데 시간을 낭비함으로써 생산성이 저하됩니다. 대신 코드 검토를 위해 하루 중 시간을 할당하여 미리 계획하십시오.

개인적으로 저는 아침이나 점심 식사 후에 다른 작업을 선택하기 전에 먼저 코드 리뷰를 하는 것을 선호합니다. 내 두뇌는 아직 전환할 이전 코드 컨텍스트 없이 신선하기 때문에 그것이 나에게 가장 잘 맞는 것입니다. 게다가 리뷰가 끝나면 나는 내 자신의 작업에 집중할 수 있고 작성자는 피드백을 기반으로 코드를 재평가할 수 있습니다.

지원하기

풀 리퀘스트가 기여 가이드라인을 따르지 않는다면, 특히 새로 온 사람들을 지지하십시오. 그 순간을 작가가 기여도를 높일 수 있는 기회로 삼으십시오. 한편, 저자가 처음부터 지침을 따르지 않은 이유를 이해하려고 노력하십시오. 아마도 이전에는 인식하지 못했던 개선의 여지가 있을 것 입니다.

지점을 확인하고 실행

코드를 검토하는 동안 특히 사용자 인터페이스와 관련된 경우 자신의 컴퓨터에서 실행되도록 합니다. 이 습관은 새 코드를 더 잘 이해하고 검토 범위를 변경된 코드로 제한하는 브라우저에서 기본 diff-tool을 사용한 경우 놓칠 수 있는 사항을 찾는 데 도움이 됩니다(코드 편집기에서와 같이 전체 컨텍스트를 사용하지 않음). .

가정하기 전에 묻기

이해하지 못하는 것이 있으면 주저하지 말고 말하고 질문하십시오. 질문할 때 먼저 주변 코드를 읽고 추측을 피하는 것을 잊지 마십시오.

대부분의 질문은 다음 두 가지 유형의 범주에 해당합니다.

1. "어떻게" 질문
   어떤 것이 어떻게 작동하는지 또는 무엇을 하는지 이해하지 못한다면 코드가 충분히 명확한지 작성자와 함께 평가하십시오. 무지로 간단한 코드를 오해하지 마십시오. 읽기 어려운 코드와 모르는 코드에는 차이가 있습니다. 아직 깊이 알지 못하더라도 열린 마음으로 새로운 언어 기능을 배우고 사용하십시오. 그러나 코드베이스를 단순화하는 경우에만 사용하십시오.
2. "왜" 질문
   "이유"를 이해할 수 없을 때 코드에 주석을 달도록 제안하는 것을 두려워하지 마십시오. 특히 예외적인 경우나 버그 수정인 경우에 그렇습니다. 코드는 그것이 하는 일을 설명할 때 자명해야 합니다. 주석은 특정 접근 방식 뒤에 있는 이유를 설명하는 보완책입니다. 컨텍스트를 설명하는 것은 유지 관리 측면에서 매우 중요하며 누군가가 쓸모 없다고 생각한 코드 블록을 삭제하는 것을 방지합니다. (개인적으로 나중에 잊어버릴 염려가 없을 때까지 코드에 주석을 달고 싶습니다.)

건설적인 비판

개선해야 한다고 생각하는 코드를 찾으면 항상 프로젝트에 기여한 작성자의 노력을 인식하고 수용적이고 투명한 방식으로 자신을 표현해야 합니다.

• 토론을 엽니다.
  피드백을 "당신은..." 또는 "당신은 ...을 잊어버렸습니다. 필수 요청 대신 공개 토론으로 피드백을 표현하세요. 작성자가 아니라 코드에 주석을 달아야 합니다. 주석이 코드에 대한 것이 아닌 경우 코드 검토에 포함되어서는 안 됩니다. 앞서 말했듯이 지원합니다. 수동태를 사용하고 복수형으로 말하기, 질문이나 제안을 표현하는 것은 저자와의 공감을 강조하는 좋은 방법입니다.
  

"여기에서 이 방법을 추출..." 대신 "이 방법을 추출해야 합니다..." 또는 "이 방법을 추출하는 것에 대해 어떻게 생각하세요..."를 선호합니다.

• 명확하게.
  피드백은 특히 의견을 표현하거나 사실이나 지침을 공유할 때 잘못 해석될 수 있습니다. 댓글에서 즉시 지우는 것을 항상 기억하십시오.

불분명: "이 코드는…."

의견: "이 코드는..."

사실: "[우리 가이드라인]에 따르면 이 코드는..."입니다.

• 이유를 설명해라.
  당신에게는 분명한 것이 다른 사람들에게는 그렇지 않을 수도 있습니다. 피드백의 동기를 너무 많이 설명하지 않으므로 작성자는 무언가를 변경하는 방법뿐만 아니라 그로부터 얻을 수 있는 이점도 이해합니다.

의견: "이 코드는..."

설명: "이 코드는 (...) 가독성을 향상시키고 단위 테스트를 단순화할 수 있기 때문에 가능합니다."

• 예를 제공합니다.
  작성자에게 익숙하지 않은 코드 기능이나 패턴을 공유할 때 참고 자료로 제안 사항을 보완하십시오. 가능하면 MDN 문서를 넘어 현재 코드 시나리오에 적용된 스니펫 또는 작업 예제를 공유하십시오. 예제를 작성하는 것이 너무 복잡할 경우 직접 지원 하거나 화상 통화로 도움을 주겠다고 제안합니다.

"필터를 사용하면 [동기부여]에 도움이 될 것입니다."와 같은 말 외에도 "이 경우 [코드 조각]과 같을 수 있습니다. [Finder.js에서 예제]를 확인할 수 있습니다. 의심스러운 점이 있으면 언제든지 Slack에서 저를 핑(ping)해 주세요.”

• 합리적이어야 합니다.
  같은 오류가 여러 번 발생하는 경우 해당 오류에 대해 한 가지 의견만 남기고 작성자를 기억하여 다른 곳에서도 검토하도록 하십시오. 중복 주석을 추가하면 소음만 발생하고 역효과가 날 수 있습니다.

초점을 유지

현재 코드와 관련 없는 코드 변경을 제안하지 마십시오. 변경을 제안하기 전에 그 순간에 꼭 필요한지 자문해 보십시오. 이러한 유형의 피드백은 특히 리팩터링에서 일반적입니다. 이는 우리가 팀으로 만들어야 하는 효율성과 효율성 사이의 많은 절충점 중 하나입니다.

리팩터링에 관해서는 개인적으로 작지만 효과적인 개선 을 선호하는 경향이 있습니다. 그것들은 검토하기 쉽고 대상 분기로 분기를 업데이트할 때 코드 충돌이 발생할 가능성이 적습니다.

기대치 설정

코드 검토를 반쯤 완료한 상태로 남겨두면 작성자에게 이에 대해 알려주므로 예상 시간을 통제할 수 있습니다. 마지막으로 새 코드에 동의하는지 또는 나중에 다시 한 번 다시 검토하고 싶은지 작성자에게 알려주십시오.

코드 검토를 승인하기 전에 나중에 해당 코드를 만질 가능성이 있는지 스스로에게 물어보십시오. 그렇다면 코드 리뷰를 성공적으로 마쳤다는 신호입니다!

코드 검토를 거부하는 방법을 배우십시오

아무도 인정하지 않지만 때로는 코드 검토를 거부해야 합니다. 코드 검토를 수락하기로 결정했지만 서두르려고 하는 순간 프로젝트의 품질은 물론 팀의 사고 방식도 손상됩니다.

다른 사람의 코드 검토를 수락하면 그 사람은 당신의 능력을 신뢰하는 것입니다. 그것은 약속입니다. 검토할 시간이 없다면 동료에게 아니오라고 말하십시오. 정말 진심이다; 동료가 절대 완료되지 않을 코드 검토를 기다리게 하지 마십시오. 의사 소통을 하고 기대치를 명확하게 유지하는 것을 잊지 마십시오 . 팀에게 정직하고 자신에게 더 잘하십시오. 어떤 선택을 하시든 건강하게, 올바르게 하세요.

결론

충분한 시간과 경험이 주어지면 코드 검토를 수행하면 기술 지식 그 이상을 배울 수 있습니다. 다른 사람들로부터 피드백을 주고받는 방법과 더 많은 생각을 하여 결정을 내리는 방법을 배우게 됩니다.

각 코드 리뷰는 커뮤니티로 그리고 개인적으로 성장할 수 있는 기회입니다. 외부 코드 리뷰라 할지라도 그것이 당신과 당신의 동료들에게 자연스럽게 오는 그날까지 건전한 사고방식을 길러야 한다는 것을 기억하십시오. 공유는 우리를 더 낫게 만드는 것이기 때문입니다!

SmashingMag에 대한 추가 정보:

• 협력: 디자이너와 개발자가 더 나은 프로젝트를 만들기 위해 의사 소통하는 방법
• 디자이너를 코드 검토 프로세스에 참여시켜 더 나은 협업
• 웹 디자이너와 개발자는 어떤 팟캐스트를 들어야 할까요?
• 완벽한 웹 개발자 이력서 작성 방법