짧은 답변
코드를 직접 수정해야합니까?
아니.
검토 프로세스에 대한 피드백을 제공하고 지침에 따라 수정을 수행해야합니까?
예. 당신의 제안 에 따르면 , 지시 사항이 아닙니다 . 지시 사항이 너무 권위적으로 들립니다.
그렇다면 어떻게 피드백을 보내거나 특정 템플릿 문서를 작성하여 보내거나 나중에 코드 파일에서 문제를 확인하여 나중에 확인할 수있는 소프트웨어가 있습니까? (Visual Studio를 사용하고 있습니다).
도구를 사용하여 피드백을 제공하십시오. Visual Studio를 사용할 수 있습니다.
긴 답변
예전에는 Visual Studio를 사용했지만 다른 개발자에게 "검토 할 수 있도록 작업을 보내 주시겠습니까?" 나는 그것을 좋아하지 않았고 그것은 실제로 잘 작동하지 않았습니다. 이제 체크인을보고 검토를 시작할 수 있으므로 검토 보조를 사용 합니다. 검토 작업을 보내는 다른 개발자에게 의존 할 필요가 없습니다. 또한 항목을 결함으로 표시하거나 작성자가 볼 항목을 표시하는 데 도움이됩니다. 검토를 시작하면 검토 보드에 그대로 유지되고 번역에서 길을 잃지 않기 때문에 팀에 효과적입니다. 이것은 Visual Studio와 통합됩니다. 앞서 언급했듯이 Visual Studio에는 기본 검토 프로세스가 있지만 제한이 있으며 프로세스가 자연스럽지 않습니다. 따라서 Review Assistant를 사용합니다.
이 도구는 또한 앞뒤 프로세스, 토론 등에 도움이됩니다.
그 과정은 다음과 같습니다.
나는 무언가를 검토 한 다음 저자에게 당신의 경우 주니어 개발자에게 보냅니다. 그들은 변경 한 다음 다시 보냅니다. 변경 사항을보고 피드백을 제공합니다. 변경 사항에 익숙하면 검토를 종료합니다. 그렇지 않으면 앞뒤로갑니다. 때때로 앞뒤로 너무 많은 경우, 나는 그들의 책상으로 걸어 가서 화이트 보드를 사용할 것입니다.
코드 검토는 민감한 영역이므로 단어 선택에 매우주의하십시오. 나는 아무에게도 말하지 않는다
나쁜 표현 선택
코드를 검토 한 후 변경해야 할 항목이 있습니다.
대신에 이렇게 말합니다.
더 나은 문구 선택
코드를 살펴본 결과 도움이 필요합니다. 내가 보낸 항목을 검토하고 내 질문 중 일부를 명확히 할 수 있는지 확인할 수 있습니까?
이것은 저자가 생각하게한다 :
- 그들이 방어 모드로 들어 가지 않도록 도움이 필요합니다.
- 그들이 아닌 리뷰어 인 것 같습니다. 기술적으로 말하면, 나는 그들이 다른 모양을하고 일부를 변경하도록 요청하기 때문에 일종의 검토 자와 같습니다.
이 간단한 단어 선택은 내게 큰 도움이되었습니다.
나는 결코 주니어 개발자를 과소 평가하지 않습니다. 나는 일부 수석 개발자들 (10 년 이상 경험)과 함께 일했으며 코드는 주니어 협동 학생보다 나빴습니다. 따라서 그들이 선배 또는 후배이기 때문에 그다지 중요한 것은 아닙니다. 그들의 작업은 실제로 수년간의 경험보다 더 크게 말하는 것입니다.
종종 주니어 개발자들을 격려하고 리뷰에 참여하도록하기 위해, 나는 그들에게 검토 할 무언가를 보낼 것입니다. 나는 다음과 같이 말할 수 있습니다.
알아낼 수 없기 때문에 코드를 검토해 주시겠습니까?
이것은 다시 크게 도움이됩니다. 이것은 내가 리뷰를 한 유일한 사람이 아니라 리뷰를하고 프로세스의 일부임을 분명히 보여주기 때문에 도움이됩니다. 전체 아이디어는 훌륭하고 깨끗한 코드를 생성하고 필요한 경우 도움을 요청하는 것입니다. 검토 프로세스는 문화이므로 실제로 작업해야합니다.
이제 일부 사람들은 위의 작업을 수행하면 주니어 개발자가 할 수없는 일을했기 때문에 존경을 잃을 것이라고 걱정할 수 있습니다. 그러나 그것은 진실과 거리가 멀다. 도움을 요청하는 것은 겸손을 나타낸다. 또한 당신이 빛날 수있는 상황이 많이 있습니다. 마지막으로 그것이 두려움이라면 자존심 문제가 있습니다. 마지막으로, 나는 정말로 그것을 모른다 : 나는이 개발자 중 일부는 한 달 전에 방금 연구했기 때문에 머리에 신선한 알고리즘을 가지고 있음을 의미합니다.
어쨌든, 주니어와 리뷰로 돌아갑니다. 그들이 알아 차리고 답장을 보내면 얼굴을보아야합니다. 그런 다음 "좋아요, 변경하겠습니다. 만족하면 문제를 닫으십시오."
그들은 내 일을 살펴볼 힘이 있다고 굉장히 느낍니다. "그렇습니다, 당신의 변화는 좋습니다. 문제를 닫았습니다."
그래도 코드를 직접 수정하지는 않습니다.
- 저자는 그로부터 배우지 않을 것입니다.
- "무엇을 제쳐두고 어떻게하는지 보여 드리겠습니다. 내 코드가 당신 코드보다 낫습니다."
- 내가 왜? 이것은 나를 위해 더 많은 일입니다.
그러나 저자를 돕기 위해 의견에 아이디어와 코드 스 니펫을 제안합니다. 때때로 내 리뷰는 단순히 저자에게 그들의 코드를 이해하지 못한다고 묻습니다. 그들의 코드에는 아무런 문제가 없을 수 있습니다. 변수 이름을 변경하고 주석을 추가해야 할 수도 있습니다. 따라서이 경우에는 무엇을 변경해야할지 모릅니다. 그들 만이
검토를 계속하면 조만간 팀에있는 각 개발자의 지식 수준에 대한 좋은 아이디어를 얻게됩니다. 이것을 아는 것이 실제로 유용하며이를 활용하여 활용해야합니다. 방법은 다음과 같습니다. 일부 코드를 검토하고 개선해야 할 분명한 영역을보고 다른 개발자도 해당 코드를 발견하면 대신 검토하도록 할 것입니다. "저는 개선 할 수있는 몇 가지 영역이 있습니다. 자세한 내용을 검토 한 후 저자에게 의견을 보내 주시겠습니까?" 이제 2 명의 다른 개발자가 서로 협력하고 있기 때문에 이것은 잘 작동합니다.
일부 작업을 검토하고 팀 전체가 혜택을 볼 수있는 것을 발견하면 가상 시나리오를 작성하고 회의에서 문제를 설명합니다. 시나리오를 설명하는 것으로 시작하여 모든 사람이 문제를 찾거나 문제를 볼 수 있는지 물어보고 참여하도록하십시오. 모든 사람이 질문을하도록하십시오. 그런 다음 마침내 더 나은 접근 방식을 제시하십시오. 다른 사람이 더 나은 접근 방식을 가지고 있다면 나는 그들에게 감사하고 팀 앞에서 그들의 접근 방식이 더 낫다는 것을 인정합니다. 이것은 내가 "나의 길이나 고속도로"유형의 성격이 아님을 보여준다. 또한 나는 절대로 누군가의 작업을 열거 나 회의에서 문제를 지적하기 시작하지 않습니다. 저자는 내가 얼마나 훌륭하고 무해하다고 생각하든 그것을 인정하지 않을 것입니다.
리뷰를 할 때 좋은 코드를 찾는 것뿐만 아니라 코드가하는 일도 찾습니다. 비즈니스 요구 사항 인 경우 : 직원이 10 년 이상 회사에 근무한 경우 5 % 증가시킵니다. 그렇지 않으면 2.5 % 입니다. 내가 확인하는 첫 번째 것은 실제로 그렇게하는지입니다. 그런 다음 깨끗하고 일관되며 성능이 좋은 방식으로 수행되고 있는지 확인합니다.
검토를 수행하면 후속 조치를 취하거나 아무도 검토를 진지하게 고려하지 않습니다.
나는 몇 년 전 누군가와 함께 리뷰를하고 개발자 매니저와 QA 매니저를 만나려고했지만 두 매니저 모두 사업 배경에서 왔거나 개발 경험이 거의 없었습니다. 그는 단지 그들을 감동시키기 위해 이것을했다. 아무도 그것을 좋아하지 않았다. 그리고 나는 내가 결코 그 실수를하지 않을 것이라고 나 자신에게 말할 때이다.
그가했던 또 다른 것은 프로그래밍 스타일을 고르는 것이며 그의 스타일이 최고라고 확신했습니다 ( "내 쿵푸는 원숭이 스타일보다 훨씬 낫다 ..."). 그것은 저에게 또 다른 교훈이었습니다. 문제를 해결하는 방법은 항상 1 가지 이상입니다.
번호가 매겨진 몇 가지 질문에 대한 답변
1- 코드를 직접 수정해야합니까?
아니요, 위에서 언급 한 이유를 참조하십시오.
2- 검토 과정에 대한 피드백을 제공하고 지침에 따라 수정하도록해야합니까?
예, 친절하지만주의가 필요한 문장과 어조를 사용하십시오. 최대한 명확하게하십시오. 코드의 문제점, 개선 방법에 대해 설명하십시오. 단순히 바꾸라고 요구하지 마십시오. 그러나 이유를 제공하십시오.
이 피드백을 어떻게 주거나, 특정 템플릿 문서를 작성하여 보내거나, 나중에 확인할 수있는 코드 파일 내부에 문제가있는 것을 표시하는 데 도움이되는 소프트웨어가 있습니까? (Visual Studio를 사용하고 있습니다).
내가 말했듯이, 내가 사용하는 도구 또는 다른 도구를 사용할 수 있습니다. 이메일이나 단어 문서는 분실되어 추적하기가 어렵 기 때문에 사용하지 마십시오.
코드 검토를 완료하고 수정이 완료된 후 언젠가는 지나갔으며 과거에 검토 한 코드의 일부가 변경되었습니다. 재검토 프로세스는 어떻게합니까? 모든 코드를 다시 확인해야합니까?
주로 내가하는 일은 델타를 확인하는 것입니다 (변경 사항 만). 그러나 깨진 것이없고 아키텍처를 따르는 지 확인하려면 전체적인 그림을 염두에 두어야합니다.
마지막 생각들
개인적으로 "코드 검토"라는 단어는 좋지 않은 선택이며 시작 방법을 모릅니다. 그들은 훨씬 더 권위 있고 덜 권위있는 단어를 선택할 수있었습니다.