코드 검토 프로세스 후 피드백을 제공하는 방법


10

현재 팀에 합류 한 주니어 개발자 코드 일부를 검토 중입니다.이 검토 결과를 어떻게 제공해야하는지 궁금합니다.

  1. 코드를 직접 수정해야합니까?

  2. 검토 프로세스에 대한 피드백을 제공하고 지침에 따라 수정을 수행해야합니까? 그렇다면 어떻게 피드백을 보내거나 특정 템플릿 문서를 작성하여 보내거나 나중에 코드 파일에서 문제를 확인하여 나중에 확인할 수있는 소프트웨어가 있습니까? (Visual Studio를 사용하고 있습니다).

코드 검토를 완료 한 후 수정이 완료된 후 시간이 지났으며 과거에 검토 한 코드의 일부가 변경되었습니다. 재검토 프로세스는 어떻게 수행합니까? 모든 코드를 다시 확인해야합니까? 아니면 변경된 부품 만 확인합니까? 그렇다면 이중 검토 코드를 피하기 위해 변경된 부분을 어떻게 추적합니까?


답변:


14

짧은 답변

코드를 직접 수정해야합니까?

아니.

검토 프로세스에 대한 피드백을 제공하고 지침에 따라 수정을 수행해야합니까?

예. 당신의 제안 에 따르면 , 지시 사항이 아닙니다 . 지시 사항이 너무 권위적으로 들립니다.

그렇다면 어떻게 피드백을 보내거나 특정 템플릿 문서를 작성하여 보내거나 나중에 코드 파일에서 문제를 확인하여 나중에 확인할 수있는 소프트웨어가 있습니까? (Visual Studio를 사용하고 있습니다).

도구를 사용하여 피드백을 제공하십시오. Visual Studio를 사용할 수 있습니다.

긴 답변

예전에는 Visual Studio를 사용했지만 다른 개발자에게 "검토 할 수 있도록 작업을 보내 주시겠습니까?" 나는 그것을 좋아하지 않았고 그것은 실제로 잘 작동하지 않았습니다. 이제 체크인을보고 검토를 시작할 수 있으므로 검토 보조를 사용 합니다. 검토 작업을 보내는 다른 개발자에게 의존 할 필요가 없습니다. 또한 항목을 결함으로 표시하거나 작성자가 볼 항목을 표시하는 데 도움이됩니다. 검토를 시작하면 검토 보드에 그대로 유지되고 번역에서 길을 잃지 않기 때문에 팀에 효과적입니다. 이것은 Visual Studio와 통합됩니다. 앞서 언급했듯이 Visual Studio에는 기본 검토 프로세스가 있지만 제한이 있으며 프로세스가 자연스럽지 않습니다. 따라서 Review Assistant를 사용합니다.

이 도구는 또한 앞뒤 프로세스, 토론 등에 도움이됩니다.

그 과정은 다음과 같습니다.

나는 무언가를 검토 한 다음 저자에게 당신의 경우 주니어 개발자에게 보냅니다. 그들은 변경 한 다음 다시 보냅니다. 변경 사항을보고 피드백을 제공합니다. 변경 사항에 익숙하면 검토를 종료합니다. 그렇지 않으면 앞뒤로갑니다. 때때로 앞뒤로 너무 많은 경우, 나는 그들의 책상으로 걸어 가서 화이트 보드를 사용할 것입니다.

코드 검토는 민감한 영역이므로 단어 선택에 매우주의하십시오. 나는 아무에게도 말하지 않는다

나쁜 표현 선택

코드를 검토 한 후 변경해야 할 항목이 있습니다.

대신에 이렇게 말합니다.

더 나은 문구 선택

코드를 살펴본 결과 도움이 필요합니다. 내가 보낸 항목을 검토하고 내 질문 중 일부를 명확히 할 수 있는지 확인할 수 있습니까?

이것은 저자가 생각하게한다 :

  1. 그들이 방어 모드로 들어 가지 않도록 도움이 필요합니다.
  2. 그들이 아닌 리뷰어 인 것 같습니다. 기술적으로 말하면, 나는 그들이 다른 모양을하고 일부를 변경하도록 요청하기 때문에 일종의 검토 자와 같습니다.

이 간단한 단어 선택은 내게 큰 도움이되었습니다.

나는 결코 주니어 개발자를 과소 평가하지 않습니다. 나는 일부 수석 개발자들 (10 년 이상 경험)과 함께 일했으며 코드는 주니어 협동 학생보다 나빴습니다. 따라서 그들이 선배 또는 후배이기 때문에 그다지 중요한 것은 아닙니다. 그들의 작업은 실제로 수년간의 경험보다 더 크게 말하는 것입니다.

종종 주니어 개발자들을 격려하고 리뷰에 참여하도록하기 위해, 나는 그들에게 검토 할 무언가를 보낼 것입니다. 나는 다음과 같이 말할 수 있습니다.

알아낼 수 없기 때문에 코드를 검토해 주시겠습니까?

이것은 다시 크게 도움이됩니다. 이것은 내가 리뷰를 한 유일한 사람이 아니라 리뷰를하고 프로세스의 일부임을 분명히 보여주기 때문에 도움이됩니다. 전체 아이디어는 훌륭하고 깨끗한 코드를 생성하고 필요한 경우 도움을 요청하는 것입니다. 검토 프로세스는 문화이므로 실제로 작업해야합니다.

이제 일부 사람들은 위의 작업을 수행하면 주니어 개발자가 할 수없는 일을했기 때문에 존경을 잃을 것이라고 걱정할 수 있습니다. 그러나 그것은 진실과 거리가 멀다. 도움을 요청하는 것은 겸손을 나타낸다. 또한 당신이 빛날 수있는 상황이 많이 있습니다. 마지막으로 그것이 두려움이라면 자존심 문제가 있습니다. 마지막으로, 나는 정말로 그것을 모른다 : 나는이 개발자 중 일부는 한 달 전에 방금 연구했기 때문에 머리에 신선한 알고리즘을 가지고 있음을 의미합니다.

어쨌든, 주니어와 리뷰로 돌아갑니다. 그들이 알아 차리고 답장을 보내면 얼굴을보아야합니다. 그런 다음 "좋아요, 변경하겠습니다. 만족하면 문제를 닫으십시오."

그들은 내 일을 살펴볼 힘이 있다고 굉장히 느낍니다. "그렇습니다, 당신의 변화는 좋습니다. 문제를 닫았습니다."

그래도 코드를 직접 수정하지는 않습니다.

  1. 저자는 그로부터 배우지 않을 것입니다.
  2. "무엇을 제쳐두고 어떻게하는지 보여 드리겠습니다. 내 코드가 당신 코드보다 낫습니다."
  3. 내가 왜? 이것은 나를 위해 더 많은 일입니다.

그러나 저자를 돕기 위해 의견에 아이디어와 코드 스 니펫을 제안합니다. 때때로 내 리뷰는 단순히 저자에게 그들의 코드를 이해하지 못한다고 묻습니다. 그들의 코드에는 아무런 문제가 없을 수 있습니다. 변수 이름을 변경하고 주석을 추가해야 할 수도 있습니다. 따라서이 경우에는 무엇을 변경해야할지 모릅니다. 그들 만이

검토를 계속하면 조만간 팀에있는 각 개발자의 지식 수준에 대한 좋은 아이디어를 얻게됩니다. 이것을 아는 것이 실제로 유용하며이를 활용하여 활용해야합니다. 방법은 다음과 같습니다. 일부 코드를 검토하고 개선해야 할 분명한 영역을보고 다른 개발자도 해당 코드를 발견하면 대신 검토하도록 할 것입니다. "저는 개선 할 수있는 몇 가지 영역이 있습니다. 자세한 내용을 검토 한 후 저자에게 의견을 보내 주시겠습니까?" 이제 2 명의 다른 개발자가 서로 협력하고 있기 때문에 이것은 잘 작동합니다.

일부 작업을 검토하고 팀 전체가 혜택을 볼 수있는 것을 발견하면 가상 시나리오를 작성하고 회의에서 문제를 설명합니다. 시나리오를 설명하는 것으로 시작하여 모든 사람이 문제를 찾거나 문제를 볼 수 있는지 물어보고 참여하도록하십시오. 모든 사람이 질문을하도록하십시오. 그런 다음 마침내 더 나은 접근 방식을 제시하십시오. 다른 사람이 더 나은 접근 방식을 가지고 있다면 나는 그들에게 감사하고 팀 앞에서 그들의 접근 방식이 더 낫다는 것을 인정합니다. 이것은 내가 "나의 길이나 고속도로"유형의 성격이 아님을 보여준다. 또한 나는 절대로 누군가의 작업을 열거 나 회의에서 문제를 지적하기 시작하지 않습니다. 저자는 내가 얼마나 훌륭하고 무해하다고 생각하든 그것을 인정하지 않을 것입니다.

리뷰를 할 때 좋은 코드를 찾는 것뿐만 아니라 코드가하는 일도 찾습니다. 비즈니스 요구 사항 인 경우 : 직원이 10 년 이상 회사에 근무한 경우 5 % 증가시킵니다. 그렇지 않으면 2.5 % 입니다. 내가 확인하는 첫 번째 것은 실제로 그렇게하는지입니다. 그런 다음 깨끗하고 일관되며 성능이 좋은 방식으로 수행되고 있는지 확인합니다.

검토를 수행하면 후속 조치를 취하거나 아무도 검토를 진지하게 고려하지 않습니다.

나는 몇 년 전 누군가와 함께 리뷰를하고 개발자 매니저와 QA 매니저를 만나려고했지만 두 매니저 모두 사업 배경에서 왔거나 개발 경험이 거의 없었습니다. 그는 단지 그들을 감동시키기 위해 이것을했다. 아무도 그것을 좋아하지 않았다. 그리고 나는 내가 결코 그 실수를하지 않을 것이라고 나 자신에게 말할 때이다.

그가했던 또 다른 것은 프로그래밍 스타일을 고르는 것이며 그의 스타일이 최고라고 확신했습니다 ( "내 쿵푸는 원숭이 스타일보다 훨씬 낫다 ..."). 그것은 저에게 또 다른 교훈이었습니다. 문제를 해결하는 방법은 항상 1 가지 이상입니다.

번호가 매겨진 몇 가지 질문에 대한 답변

1- 코드를 직접 수정해야합니까?

아니요, 위에서 언급 한 이유를 참조하십시오.

2- 검토 과정에 대한 피드백을 제공하고 지침에 따라 수정하도록해야합니까?

예, 친절하지만주의가 필요한 문장과 어조를 사용하십시오. 최대한 명확하게하십시오. 코드의 문제점, 개선 방법에 대해 설명하십시오. 단순히 바꾸라고 요구하지 마십시오. 그러나 이유를 제공하십시오.

이 피드백을 어떻게 주거나, 특정 템플릿 문서를 작성하여 보내거나, 나중에 확인할 수있는 코드 파일 내부에 문제가있는 것을 표시하는 데 도움이되는 소프트웨어가 있습니까? (Visual Studio를 사용하고 있습니다).

내가 말했듯이, 내가 사용하는 도구 또는 다른 도구를 사용할 수 있습니다. 이메일이나 단어 문서는 분실되어 추적하기가 어렵 기 때문에 사용하지 마십시오.

코드 검토를 완료하고 수정이 완료된 후 언젠가는 지나갔으며 과거에 검토 한 코드의 일부가 변경되었습니다. 재검토 프로세스는 어떻게합니까? 모든 코드를 다시 확인해야합니까?

주로 내가하는 일은 델타를 확인하는 것입니다 (변경 사항 만). 그러나 깨진 것이없고 아키텍처를 따르는 지 확인하려면 전체적인 그림을 염두에 두어야합니다.

마지막 생각들

개인적으로 "코드 검토"라는 단어는 좋지 않은 선택이며 시작 방법을 모릅니다. 그들은 훨씬 더 권위 있고 덜 권위있는 단어를 선택할 수있었습니다.


변수 이름과 같은 작은 것들에 대해서만 작동합니다. 그러나 아키텍처가 잘못된 경우 도움이 될 수있는 도구가 없습니다. 전체를 버리고 다시 작성하기 만하면됩니다.
t3chb0t

왜 작은 것입니까? 즉 making sense architecturally, 데이터 액세스 계층 코드가 데이터 액세스 계층 내에 있는지, UI 유효성 검사가 UI 등에 있는지 확인해야했습니다. 즉, 다른 영역에 문제가 발생하지 않도록해야합니다. 아키텍처를 유지하는 데 도움이되는 도구가 있습니다. 실제로 VS는 이제 이것을 즉시 상자 밖으로 만듭니다. 우리는 그것을 사용합니다.
CodingYoshi

도구와 관련하여 완벽하게 유효한 도구는 이미 수행해야 할 작업을 추적하는 데 사용할 수있는 발권 / 작업 추적 소프트웨어 형태 일 것입니다. 예를 들어, Github을 사용하는 경우 변경 사항이 모두 이슈와 관련이있을 수 있으며 해당 토론 스레드에서 검토가 수행됩니다. Jira와 Trac은 다른 두 가지 도구입니다. 이것은 작업과 관련된 모든 정보의 중앙 위치를 유지하며 티켓을 닫기 전에 명확하게 볼 수 있습니다.
Kat

@Kat 발권 도구가 여기에 적합한 도구인지 확실하지 않습니다. 코드 검토 도구는 변경 사항의 차이점을 보여 주며 문제는 티켓 시스템의 문제와 다른 문제입니다. 그들은 다른 것을 의미합니다. 그러나 나는 틀릴 수 있습니다.
코딩 요시

3

회사의 코드 검토를 이해하는 방법에 따라 다릅니다. 코드 검토가 공식화되지 않은 프로세스 인 회사가 거의 없지만 큰 문제가 있습니다. 다른 경우 코드 검토는 구현되는 각 작업의 필수 부분이며 형식이 거의없는 매우 평범하고 빠른 것입니다. 개인적으로, 나는 후자의 접근법을 선택하지만, 당신이 그것을 사용할 수 있는지 여부는 귀하의 결정 일 수도 있고 아닐 수도 있습니다.

코드 리뷰가 귀하의 시간 가치가 있습니까? 라는 제목의 블로그 게시물을 작성했습니다 . 팀에서 사용하는 프로세스를 요약합니다. 귀하의 질문과 관련된 테이크 아웃은 다음과 같습니다.

  1. 개발자가 코드를 수정하도록합니다. 이를 통해 귀하의 의견을 더 잘 이해하고 (또는 완전히 이해하지 못하고 묻지 않음) 과제를 수행하는 것이 그것에 대해 읽는 것보다 더 나은 학습 방법입니다.
  2. 코드 검토를위한 소프트웨어가 필요합니다. 오픈 소스 및 독점 옵션이 많이 있습니다. 대부분은 git에서 작동합니다. 우리 팀은 BitBucket (이전에는 Stash라고 함)을 사용하고 GitLab과 GitHub, Gerrit (개인적으로 팬이 아닙니다) 및 기타 여러 가지가 있습니다. 이러한 응용 프로그램의 대부분은 웹 기반이므로 어떤 IDE를 사용하든 중요하지 않지만 많은 IDE 용 플러그인도 있으므로 Visual Studio 용 플러그인도 있습니다. 이와 같은 소프트웨어를 사용하면 코드가 기본 분기 (일반적으로 풀 요청을 통해)에 병합되기 전에 코드를 검토 할 수 있으며 각 변경에 대한 수정 된 부분과 일부 컨텍스트 라인이 표시됩니다. 이로 인해 코드 검토가 매끄럽고 번거롭지 않습니다.

리뷰-픽스-픽스-픽스-픽스 사이클에 관해서는, 개발자의 성숙도와 발견 한 문제의 중력에 따라 선택해야합니다. 팀이 매일 코드 검토를 수행하면 클래스 이름 변경과 같은 사소한 변경 사항 만 적용되어 다시 확인할 필요가 없습니다. 팀이 아직 코드 리뷰로 판매되지 않았거나 사람들이 실제로 경험이 없다면 그러한 것들을 확인하고 싶을 수도 있습니다. 반면에 검토 결과 주니어 개발자가 지적한 후에도 완전히 이해하지 못하는 복잡한 동시성 문제를 발견 한 경우 수정 사항을 확인하고 실제로 수정하기 전에 변경 사항을 승인하지 않는 것이 좋습니다.

풀 요청으로 작업하는 경우 사전 결정된 수의 개발자의 승인을받을 때까지 변경 사항을 병합하지 않도록 소프트웨어를 쉽게 설정할 수 있으므로 도구를 사용하면 도움이됩니다. 일반적으로 변경 사항의 개별 커밋에서 변경 사항을 볼 수 있으므로 마지막 주석 이후에 추가 된 변경 사항 만 쉽게 볼 수 있습니다.


1

두 번째 옵션에 투표합니다. 주니어는 스스로 변경을 수행 할 때 더 나은 "lerning curve"를 가질 수 있습니다.

또한 : 코드를 검토하는 유일한 사람이되지 마십시오.
숙련 된 팀원 중 일부가 코드를보고 검토자가 검토 결과 ( 회의 전에 만든 것 )를 저자에게 제시 하는 정기 검토 회의를 예약하십시오 . 이것은 후배들 경험 팀원들의 동기를 높여 줄 것 입니다.


4
좋은 지적입니다. 또한 후배들은 OP의 코드와 서로의 코드를 "검토"해야합니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.