동료 / 코드 검토 좌절

나는 나 자신을 슈퍼 스타 개발자라고 부르지는 않지만 상대적으로 숙련 된 전문가라고 부를 것이다. 코드 품질을 높은 수준으로 유지하려고 노력하고 항상 코딩 스타일을 개선하고, 코드를 효율적이고 읽기 쉽고 일관성있게 유지하면서 팀이 패턴 및 방법론을 따라 일관성을 유지하도록 장려합니다. 또한 품질과 속도의 균형이 필요하다는 것도 알고 있습니다.

이를 달성하기 위해 동료 검토라는 개념을 팀에 소개했습니다. 병합을위한 github pull-request에서 두 개의 엄지 손가락. 위대하지만 내 의견으로는 좋지 않습니다.

나는 종종 같은 동료의 동료 리뷰 의견을 보았습니다-

• 뒤에 공백을 추가하는 것이 좋을 것입니다 <INSERT SOMETHING HERE>
• 메소드 사이에 불필요한 추가 라인
• docblock의 주석 끝에는 완전 정지를 사용해야합니다.

내 관점에서 볼 때, 검토자는 코드 미학을 피상적으로보고 있으며 실제로 코드 검토를 수행하지는 않습니다. 화장품 코드 검토는 오만한 / 정신 주의적 사고 방식으로 나에게 온다. 그것은 실체가 없지만 검토자가 기술적으로 정확 하기 때문에 너무 많이 논쟁 할 수는 없습니다 . 위와 같은 종류의 리뷰는 많지 않지만 다음과 같은 리뷰는 더 많이 볼 수 있습니다.

• 순환 복잡성을 줄일 수 있습니다 ...
• 일찍 종료하고 if / else를 피하십시오
• DB 쿼리를 리포지토리에 추상화
• 이 논리는 실제로 여기에 속하지 않습니다
• 자신을 반복하지 마십시오-추상과 재사용
• X메소드의 인수로 전달 되면 어떻게 Y됩니까?
• 이것에 대한 단위 테스트는 어디에 있습니까?

나는 화장품 유형의 리뷰를 제공하는 사람들이 항상 같은 종류의 사람들이고, 제 생각에 "Quality & Logic based"동료 리뷰를 제공하는 사람들과 같은 유형의 사람들이라는 것을 알았습니다.

동료 검토에 대한 올바른 접근 방법은 무엇입니까? 그리고 실제 코드 결함이 아닌 철자 오류 및 미적 결함을 찾는 코드를 기본적으로 훑어 보는 동일한 사람들에 좌절감을 느끼는 것이 맞습니까?

내가 맞다면-동료들에게 실제로 화장 용 터치 업 제안과 균형을 이루어 코드에서 결함을 찾도록 격려하는 방법은 무엇입니까?

내가 틀렸다면-깨달아주세요. 실제로 좋은 코드 검토를 구성하는 규칙에 대한 규칙이 있습니까? 코드 리뷰가 무엇인지 요점을 놓쳤습니까?

내 관점에서-코드 검토는 코드에 대한 책임을 공유하는 것입니다. 논리, 가독성 및 기능을 다루거나 확인하지 않고 코드에 엄지 손가락을 올리는 것은 편안하지 않습니다. 누군가가 doc-block에서 완전히 멈추지 않았다는 것을 알면 견고한 코드 조각에 대한 병합을 차단하는 것을 귀찮게하지 않을 것입니다.

코드를 검토 할 때 500 Loc 당 15-45 분이 소요될 수 있습니다. 이 얕은 리뷰가 그들이 수행하는 리뷰의 깊이라면 10 분 이상 걸리는 것을 상상할 수 없습니다. 또한 얕은 검토 자의 엄지 손가락 업 가치는 얼마입니까? 확실히 이것은 모든 엄지 손가락의 무게가 같지 않으며 2 패스 검토 프로세스가 필요할 수 있음을 의미합니다. 심도있는 검토를위한 하나의 엄지 손가락과 "연마"를위한 두 번째 엄지 손가락?

리뷰의 종류

동료 검토를 수행 할 수있는 진정한 방법은 없습니다. 코드의 품질이 충분한 지 판단하는 방법에는 여러 가지가 있습니다. 버그가 있는지, 또는 확장되지 않거나 취하기 쉬운 솔루션이 있는지에 대한 의문이 있습니다. 현지 표준 및 지침을 준수하는 문제는 다른 표준보다 중요하지는 않지만 고품질 코드에 기여하는 것의 일부입니다.

검토 자의 유형

우리가 소프트웨어를 판단하기위한 다른 기준을 가지고있는 것처럼, 심사를 수행하는 사람들도 다릅니다. 우리 모두는 자신의 기술과 편견이 있습니다. 어떤 사람들은 메모리 사용이나 테스트의 코드 적용 등에 더 관심이있는 것처럼 현지 표준을 준수하는 것이 매우 중요하다고 생각할 수 있습니다. 전체적으로 더 나은 코드를 작성하는 데 도움이되기 때문에 이러한 유형의 리뷰를 모두 원합니다.

동료 리뷰는 태그 게임이 아닌 협업입니다.

그들에게 일을하는 방법을 말할 권리가 있는지 잘 모르겠습니다. 확실하게 달리 알지 않는 한,이 사람이 자신에게 맞는 방식으로 기여하려고한다고 가정하십시오. 그러나 개선의 여지가 보이거나 동료 검토에서 예상되는 내용을 이해하지 못하는 것으로 의심 되면 그들 과 대화하십시오 .

동료 검토 의 요점은 동료 를 참여시키는 것 입니다. 참여는 벽에 코드를 던지고 응답이 다시 발생하기를 기다리지 않습니다. 참여는 더 나은 코드를 만들기 위해 함께 노력하고 있습니다. 그들과 대화에 참여하십시오.

조언

당신의 질문이 끝날 무렵 :

미학적 오류와 눈에 띄게 코드에서 결함을 실제로 찾도록 동료들에게 격려하는 방법은 무엇입니까?

다시 한 번 대답은 의사 소통입니다. 아마도 여러분은 그들에게 "이러한 실수를 발견해 주셔서 감사합니다. 코드를 제대로 구성하고 있는지 여부와 같은 더 깊은 문제에 집중할 수 있다면 큰 도움이 될 것입니다. 시간이 걸리지 만 실제로는 도움."

좀 더 실용적인 메모로, 나는 개인적으로 코드 검토 주석을 두 개의 캠프로 나누고 적절하게 표현해야한다 : 고쳐야 할 것, 그리고 더 장식적인 것. 파일 끝에 빈 줄이 너무 많으면 제대로 작동하는 코드가 체크인되는 것을 막을 수 없습니다. 그러나이 점을 지적 하겠지만, "우리의 가이드 라인에는 끝에 빈 줄이 하나 있다고 말하고 20 개가 있습니다. 쇼 스토퍼는 아니지만 기회가된다면 문제를 해결하고 싶을 수도 있습니다. "

고려해야 할 또 다른 사항이 있습니다. 코드를 검토하는 것이 귀찮을 수도 있습니다. 그들의 애완 동물 은 당신 (또는 비슷한 리뷰를 얻는 다른 팀원)이 조직의 코딩 표준과 관련하여 조잡하다는 것입니다.

검토 후해야 할 일

마지막으로, 검토 후 약간의 조언 : 검토 후 코드를 커밋 할 때 한 번의 커밋과 다른 커밋의 기능 변경을 모두 고려하는 것이 좋습니다. 이 두 가지를 혼합하면 중요한 변화와 중요하지 않은 변화를 구분하기가 어려울 수 있습니다. 모든 외관을 변경 한 다음 "화장품; 기능적 변경 없음"과 같은 메시지를 커밋합니다.

사람들은 코드 형식 및 오타에 대해 언급하기가 쉬우 며 많은 노력이 필요하지 않기 때문에 의견을 제시합니다.

이 부분은 쉽게 고칠 수 있습니다. 거의 모든 언어에 린 터나 스타일 체커 도구가 있습니다. 빌드 프로세스에서 플러그인을 작성하여 중복 공간이있는 경우 빌드에 실패합니다. 결과적으로 언급 할 스타일 문제는 없습니다.

그들이 실제 문제를 찾도록하는 것은 상당히 어려울 수 있습니다. 여기에는 호기심이 많고 세부적인 지향적 인 사고 방식뿐만 아니라 중요한 동기 부여가 필요합니다.

그리고이 동기는 경험에서 비롯됩니다. 이전 개발자가 작성한 엉터리 코드 작업 경험. 선임 엔지니어는 그 점을 많이 가지고 있습니다. 똥 바다에서 수영하면 다시는 거기에 가지 않기를 원합니다.

코드 검토 중에 확인할 주요 사항을 하나 선택해야 할 경우 코드 유지 관리 성이 좋을 것입니다. 항상이 코드를 검토하는 개발자는이 코드를 이해하고 향상시키고 수정할 준비가되어 있어야합니다. 여기에서 무슨 일이 일어나고 있는지에 대한 단서가 없다면 즉시 알려야하며 코드를 다시 작성해야합니다.

실제적인 답변은 다음과 같습니다.

시나리오 1 : 당신은 선임 회원이며 연습을 결정할 수있는 사람

회의에 전화하여 규범 검토 규칙 및 지침을 마련하십시오. 저를 믿으십시오. 명확한 지침은 어떤 '명예로운'시스템이나 교육보다 효과적입니다. 코드 형식 문제가 전혀 발생하지 않아야 함을 분명히하십시오. 일부 회원은 이의를 제기합니다. 학생들의 말을 듣고 실험으로 처음 몇 개월 동안 지침을 따르도록 요청하십시오. 현재 가이드 라인이 작동하지 않을 경우 기꺼이 변화를 보여주십시오.

시나리오 2 : 당신은 연습을 결정하는 사람이 아니거나 팀에서 비교적 후배 인

가장 좋은 방법은 시나리오 1 에 도달 할 때까지 코드 검토 문제를 해결하는 것 입니다.

"사소한"코드 검토 주석을 방지하기위한 간단한 대답은 (효율성을 위해) 검토자가이를 수정해야한다고 주장하는 것입니다. 따라서 리뷰어가 당신이 (고통!) 풀 스톱을 놓쳤거나 주석을 잘못 입력 한 것을 발견하면, 그냥 고쳐야합니다.

내 경험상 이것은 다음을 의미합니다.

• 귀하의 검토 자들은 이러한 의미없는 검토 의견 작성을 중단하고 수정을 위해 다시 전달합니다.
• 대부분의 OCD 검토 자만 문제를 해결하므로 대부분의 검토가 통과됩니다. 이는 개발자가보다 실질적인 검토를 수행하도록 요구하는 실질적인 영향을 미칩니다. 실제로 코드를 검토하지 않기 때문에 상식을 신고하는 사람들은 모든 검토가 주석없이 통과하는 이유를 정당화해야합니다.

어느 쪽이든, 이것은 이점입니다. 검토 실패 비용은 개발자가 작업중인 작업을 중지하고 코드를 다시 방문하게하고 후속 후속 검토를 수행하는 측면에서 비쌉니다. 리뷰에서 실제 코드 품질이나 아키텍처 문제가 발견되면이 비용은 모든 페니의 가치가 있지만 사소한 비용을 지불하는 것은 아닙니다.

검토 프로세스 검토

코드 검토 외에도 정기적으로 검토 프로세스를 검토하는 것이 좋습니다. 적절한 코드 검토를 제공하는 방법과 같이 사람들이 여기서 배울 수있는 것이 많이 있습니다.

일반적으로 자전거 창고 중 일부는 경험이 부족하며 무엇을 찾아야할지 모릅니다. 그들은 코드와 관련하여뿐만 아니라 유용한 코드 검토를 수행하는 것에 대한 약간의 지침이 필요합니다. 리뷰에 대한 피드백을 제공하면 더 나은 리뷰와 더 나은 코드로 이어지는 학습 프로세스가 생길 것입니다.

다음으로, 일련의 가치와 기준, 조직이나 팀이 Good Code ™로 인식하는 것, 피해야 할 반 패턴은 (느슨하게) 공식화하는 것이 좋습니다. sth를 설정하는 것이 아닙니다. 구체적으로, 처음부터 코드 품질 에 대한 공통된 합의를 얻는 방법에 대해 .

이 양쪽에있는 사람 (다른 사람들이 작성한 코드를 검토하고 내가 작성한 코드를 검토 함)으로 피드백에 속하는 세 가지 범주가 있다고 말하고 싶습니다. 네, "모두가 좋다"라는 즐거운 사례도 있습니다.

"좋아요, 그러나 그것은 당신을 차단하지 않습니다" 또는 "시스템이 던질 블록이 비활성화되었는지 확인하십시오") :

• 문장 끝에서 완전히 멈추는 것을 잊어 버립니다 (문서 문자열 또는 주석). 모양이나 형태 (다시, 문서 문자열 및 주석)로 사용자에게 방출되지 않는 모든 서투른 문법
• 더 우아한 방법을 가지고 있지만 이해하기 쉽고 관용적 인 코드 (아마도 제안을 넣을 수 있으므로 떠나거나 수정하기 쉽습니다)

"수정되어야 할 것들이지만, 당신이 그렇게하겠다고 믿습니다" 다시 완료 "(이 시점에서 다른 팝업이 표시되지 않는지 신속하게 스캔합니다)) :

• 사소한 퀴즈 ( "부울과 비교 true, 약간의 편집증 ...", ...)
• 사소한 스타일 위반 ( "스타일 가이드는 X, 당신이 한 일은 그 밖에 있습니다; 당신이 가고 싶은 방식에 따라 Y 또는 Z를 할 것입니다")
• 작성하기 어려운 몇 가지 누락 된 테스트 사례

마지막으로, "문제가있는 것, 일단이 문제를 해결 한 후에는 코드를 다시 검토해야합니다"(이 범주에있는 경우 다른 검토가 필요하므로 " 또한 몇 가지 사소한 것들이 있습니다. 처음 두 가지 범주 중 하나라도 존재하는 경우 고정 된 것들 중 일부를 보는 것이 좋을 것입니다.)

• 이것은 "아니, 실제로는 훨씬 더 나은 작성 방법이있다", "단위 테스트에서 이러한 최첨단 사례를 놓치므로 예상 한 것을 계산하지 않는 것"및 기타 모든 심각한 문제와 같은 것들이 될 것이다.

일부 사람들은 가장 중요한 질문을 잊어 버린 것 같습니다. 실제로 코드 검토를 통해 달성하려는 것은 무엇입니까?

코드 검토의 목적은 버그가없고 유지 보수가 쉬운 코드를 더 빨리 얻는 것입니다. 코드 검토는 여러 가지 방법으로이를 달성합니다. 개발자는 먼저 검토 할 것임을 알고 있기 때문에 더 나은 코드를 작성합니다. 검토 과정의 일부로 지식이 공유되며 검토자가 개발자로서 자신의 실수에 대해 눈을 멀게하지 않기 때문에 버그가 발견됩니다. 할 수 있습니다.

검토 프로세스를 동료를 중단하거나 동료를 위해 작업을 생성 할 수있는 기회로보고 있다면 잘못한 것입니다.