작년에 심각한 품질 문제가 발생한 후 회사에서 최근 코드 검토를 도입했습니다. 가이드 라인이나 어떤 종류의 체크리스트없이 코드 검토 프로세스가 빠르게 도입되었습니다.

다른 개발자와 나는 시스템에 대한 모든 변경 사항을 트렁크에 병합하기 전에 검토하기로 결정했습니다.

우리는 또한 "기술 리드"로 선정되었습니다. 이는 코드 품질에 대한 책임이 있지만 프로세스 변경을 구현하거나 개발자를 재 할당하거나 프로젝트를 보류 할 권한이 없음을 의미합니다.

기술적으로 병합을 거부하여 다시 개발로 되돌릴 수 있습니다. 실제로 이것은 거의 항상 상사에게 제 시간에 배송되도록 요구합니다.

우리의 관리자는 다가오는 프로젝트 일정을 만드는 데 주로 관심이있는 MBA입니다. 그는 노력하는 동안 비즈니스 관점에서 소프트웨어가 무엇을하는지 거의 알지 못하며 개발자의 설명없이 가장 기본적인 고객 요구 사항을 이해하기 위해 고심하고 있습니다.

현재 개발은 SVN의 개발 지점에서 수행되며 개발자가 준비가되었다고 생각하면 티켓 시스템의 티켓을 관리자에게 다시 할당합니다. 관리자는 우리에게 그것을 할당합니다.

코드 검토로 인해 팀 내에서 긴장이 고조되었습니다. 특히 나이가 많은 회원 중 일부는 변경 사항에 의문을 제기합니다 (즉, "우리는 항상 이렇게했습니다"또는 "이 방법이 합리적인 이름을 가져야하는 이유는 무엇입니까?").

처음 몇 주 후 동료가 물건을 미끄러지기 시작하여 동료들에게 문제를 일으키지 않았습니다. 개발자가 지적한 것에 대해 그녀에게 화를 냈습니다).

반면에, 나는 현재 커밋 된 코드의 문제점을 지적하기위한 엉덩이로 유명합니다.

나는 내 기준이 너무 높다고 생각하지 않습니다.

현재 나의 점검표는 다음과 같습니다.

• 코드가 컴파일됩니다.
• 코드가 작동하는 적어도 하나의 방법이 있습니다.
• 이 코드는 대부분의 일반적인 경우에 작동합니다.
• 이 코드는 대부분의 경우와 함께 작동합니다.
• 삽입 된 데이터가 유효하지 않으면 코드에서 적절한 예외가 발생합니다.

그러나 나는 피드백을 제공하는 방식에 대한 책임을 전적으로 받아들입니다. 나는 왜 무언가가 왜 바뀌어야하는지, 때로는 왜 특정한 방식으로 왜 구현되었는지를 설명하는 실행 가능한 포인트를 제공하고 있습니다. 그것이 나쁘다고 생각하면 다른 방법으로 개발했을 것이라고 지적합니다.

내가 부족한 것은 "좋은"것으로 지적 할 무언가를 찾는 능력이다. 나는 나쁜 소식을 좋은 소식에 끼 우려 고 노력해야한다는 것을 읽었습니다.

그러나 나는 좋은 것을 찾기가 힘듭니다. "이번에 당신이 한 모든 일을 실제로 저지른 것"은 훌륭하거나 도움이되는 것보다 더 모호합니다.

코드 검토 예

조,

Library \ ACME \ ExtractOrderMail 클래스의 변경 사항에 대해 몇 가지 질문이 있습니다.

"TempFilesToDelete"를 정적으로 표시 한 이유를 이해하지 못했습니까? 현재 "GetMails"에 대한 두 번째 호출은 파일을 추가 한 후 삭제 한 후 절대로 제거하지 않기 때문에 예외를 발생시킵니다. 함수가 실행 당 한 번만 호출된다는 것을 알고 있지만 앞으로는 변경 될 수 있습니다. 인스턴스 변수로 만들면 병렬로 여러 객체를 가질 수 있습니다.

... (작동하지 않는 다른 점들)

사소한 포인트 :

• "GetErrorMailBody"가 예외를 매개 변수로 사용하는 이유는 무엇입니까? 내가 뭘 놓 쳤니? 예외를 던지지 않고 그냥 전달하고 "ToString"을 호출하면됩니다. 왜 그런 겁니까?
• SaveAndSend는 메소드의 이름이 아닙니다. 메일 처리가 잘못되면이 메소드는 오류 메일을 보냅니다. 이름을 "SendErrorMail"또는 이와 유사한 이름으로 바꿀 수 있습니까?
• 오래된 코드를 주석 처리하지 말고 삭제하십시오. 우리는 여전히 subversion에 있습니다.

코드 검토에서 긍정적 인 것을 찾는 방법은 무엇입니까?

작년에 심각한 품질 문제가 발생한 후 회사에서 최근 코드 검토를 도입했습니다.

회사의 가치를 창출 할 수있는 실질적인 기회가 있습니다.

처음 몇 주 후 동료가 문제를 해결하기 위해 동료들에게 문제를 일으키지 않기 시작했습니다. (고객이 버그 보고서를 제출 한 후 버그에 대해 알고 있었지만 개발자는 두려워했습니다. 그것을 지적한 것에 대해 그녀에게 화를 낼 것입니다).

동료가 개발자에게 코드의 문제점을 알려주는 것을 처리 할 수없는 경우 코드 검토를 수행해서는 안됩니다. 고객에게 영향을 미치기 전에 문제를 찾아 해결하는 것이 귀하의 임무 입니다.

마찬가지로, 동료를 위협하는 개발자도 해고를 요구하고 있습니다. 코드 검토 후 협박 감을 느꼈습니다. 상사에게 말하면 처리되었습니다. 또한 저는 제 직업을 좋아하므로 긍정적이고 부정적인 피드백을 유지했습니다. 리뷰어로서, 그것은 다른 사람이 아닌 나에게 있습니다.

반면에, 나는 현재 커밋 된 코드의 문제점을 지적하기위한 엉덩이로 유명합니다.

글쎄, 그것은 불행한 일입니다. 당신은 재치가 있다고 말합니다. 더 찾아야한다면 칭찬 할 것이 더 많습니다.

저자가 아닌 코드 비판

예를 들어 보자.

변경 사항에 대해 몇 가지 질문이 있습니다

"당신"과 "당신"이라는 단어를 사용하지 말고 "대신"이 대신 변경하십시오.

내가 뭘 놓 쳤니? [...] 왜 그런 겁니까?

당신의 비평에 수사적 번영을 더하지 마십시오. 농담하지 마십시오. 내가 들었던 규칙이 있는데, "만약 당신이 말을하면 기분이 좋으면 말도 안 돼요."

아마도 당신은 다른 사람의 비용으로 자신의 자아를 버프하고있을 것입니다. 사실 만 지키십시오.

긍정적 인 피드백을 제공하여 막대를 높이십시오

동료 개발자가 더 높은 표준을 충족 할 때 칭찬 할 수있는 기준을 높입니다. 그것은 질문을 의미합니다.

코드 검토에서 긍정적 인 것을 찾는 방법은 무엇입니까?

좋은 주소이며 다루어야 할 가치가 있습니다.

코드가 상위 수준의 코딩 관행의 이상을 충족시키는 곳을 지적 할 수 있습니다.

모범 사례를 따르고 계속해서 막대를 높이는 것을 찾아보십시오. 더 쉬운 이상이 모든 사람에게 기대되면, 당신은 이것들을 칭찬하는 것을 멈추고 칭찬을위한 더 나은 코딩 관행을 찾고 싶을 것입니다.

언어 별 모범 사례

언어가 코드, 네임 스페이스, 객체 지향 또는 기능적 프로그래밍 기능의 문서를 지원하는 경우이를 호출하여 저자가 적절한 곳에서 사용하도록 축하 할 수 있습니다. 이러한 문제는 일반적으로 스타일 가이드에 해당합니다.

• 사내 언어 스타일 가이드 표준을 충족합니까?
• 언어에 대한 가장 권위있는 스타일 가이드를 충족합니까 (아마도 사내보다 더 엄격하므로 사내 스타일을 여전히 준수하고 있습니까)?

일반적인 모범 사례

다양한 패러다임에서 일반적인 코딩 원칙에 대해 칭찬 할 점을 찾을 수 있습니다. 예를 들어, 그들은 좋은 단위 테스트를 가지고 있습니까? 단위 테스트가 대부분의 코드를 다루고 있습니까?

찾다:

• 테스트 대상이 아닌 값 비싼 기능을 조롱하는 주제 기능 만 테스트하는 단위 테스트.
• API 및 의미 적으로 공개 기능을 완벽하게 테스트하여 높은 수준의 코드 적용 범위.
• 단위 테스트를 위해 조롱 된 기능을 포함하여 종단 간 기능을 테스트하는 수락 테스트 및 연기 테스트.
• 좋은 이름, 정식 데이터 포인트이므로 코드는 DRY (반복하지 말 것)이며 마법의 문자열이나 숫자가 없습니다.
• 변수 이름 지정이 너무 좋아서 주석이 대부분 중복됩니다.
• 정리, 객관적인 개선 (상충없이) 및 코드를 원본 작성자에게 완전히 외국으로 만들지 않고 코드 줄과 기술 부채를 줄이는 적절한 리팩토링.

기능적 프로그래밍

언어가 기능적이거나 기능적 패러다임을 지원하는 경우 다음과 같은 이상을 찾으십시오.

• 세계와 세계 국가를 피하다
• 클로저 및 부분 함수 사용
• 읽기 쉽고 정확하며 설명이 포함 된 작은 함수
• 단일 종료점으로 인수 수 최소화

객체 지향 프로그래밍 (OOP)

언어가 OOP를 지원하는 경우 다음 기능의 적절한 사용법을 칭찬 할 수 있습니다.

• 캡슐화-깔끔하게 정의 된 소규모 공용 인터페이스를 제공하고 세부 정보를 숨 깁니다.
• 상속-아마도 믹스 인을 통해 코드가 적절하게 재사용되었습니다.
• 다형성-인터페이스, 아마도 추상 기본 클래스, 파라 메트릭 다형성을 지원하도록 작성된 함수가 정의됩니다.

OOP에는 SOLID 원칙 (OOP 기능에 대한 일부 중복성)도 있습니다.

• 단일 책임-각 개체에는 하나의 이해 관계자 / 소유자가 있습니다
• 열림 / 닫힘-설정된 객체의 인터페이스를 수정하지 않음
• Liskov 대체-서브 클래스는 부모 인스턴스를 대체 할 수 있습니다.
• 인터페이스 분리-컴포지션에서 제공하는 인터페이스, 아마도 믹스 인
• 의존성 역전-인터페이스 정의-다형성 ...

유닉스 프로그래밍 원칙 :

유닉스 원칙은 모듈성, 명확성, 구성, 분리, 단순성, 파마 모니, 투명성, 견고성, 표현, 최소 놀람, 침묵, 수리, 경제, 생성, 최적화, 다양성 및 확장 성입니다.

일반적으로 이러한 원칙은 많은 패러다임에서 적용될 수 있습니다.

당신의 기준

이것들은 너무 사소한 것입니다-이것에 대해 칭찬하면 기뻐할 것입니다.

• 코드가 컴파일됩니다.
• 코드가 작동하는 적어도 하나의 방법이 있습니다.
• 이 코드는 대부분의 일반적인 경우에 작동합니다.

다른 한편으로, 이것들은 당신이 다루고있는 것을 고려할 때 상당히 높은 평가이며, 나는 이것을하는 개발자를 칭찬하는 것을 망설이지 않을 것입니다 :

• 이 코드는 대부분의 경우와 함께 작동합니다.
• 삽입 된 데이터가 유효하지 않으면 코드에서 적절한 예외가 발생합니다.

코드 검토 통과 규칙을 작성 하시겠습니까?

이론적으로는 좋은 생각이지만, 일반적으로 잘못된 이름 지정을위한 코드를 거부하지는 않지만 이름을 너무 잘못 지정하여 코드를 수정하라는 지시 사항으로 코드를 거부 할 수 있습니다. 어떤 이유로 든 코드를 거부 할 수 있어야합니다.

코드를 거부 할 수 있다고 생각할 수있는 유일한 규칙은 코드를 생산에서 제외시킬 수있는 것입니다. 정말 나쁜 이름은 생산을 기꺼이하지 않을 것입니다.하지만 규칙을 정할 수는 없습니다.

결론

언어가 지원하는 경우 모범 사례를 여러 패러다임에서, 그리고 아마도 모든 패러다임에서 따를 수 있습니다.

탄탄하고 간결한 예가 아니라 집중된 문제와 직접 관련이없는 한 좋은 것을 고르지 마십시오.

나는 설탕을 입히지 않을 것입니다-그 소리로 당신은 그들의 능력에 안전하지 못하고 미숙 한 방식으로 그들의 일에 대해 도전 받고있는 적어도 한 사람을 다루고 있습니다. 그들은 또한 자신의 업무에 나쁜 영향을 줄 수 있습니다. 훌륭한 개발자는 항상 자기 자신을 반영하고 건설적인 비판을 받고 자신의 길을 바꿀 수 있어야합니다.

이제 공기 중에 나왔으니 당신에 대해 이야기 할 수 있습니다. 당신이 합리적이라고 생각하든, 공을 굴리기 위해서는 이와 같은 사람들을 조심해야합니다. 이 사람들을 다루는 가장 좋은 방법은 당신이 말을하는 방법에 매우주의를 기울이는 것입니다.

저자가 아닌 코드를 비난하고 있는지 확인하십시오 . 코드 기반 인 똥 산이 아닌 한 가지 문제에 초점을 맞추십시오.이 코드는 코드 작성에 많은 도움이되었으며 추가 개인 공격으로 간주 될 수 있습니다. 처음에는 전투를 선택하고 사용자에게 드러나는 중요한 문제에 집중하여 자신이 말하는 모든 것을 무시하도록 이끌고있는 사람에 대한 비판을 시작하지 않도록하십시오.

신체 언어와 어조는 직접 대화 할 때 중요하며, 말하는 내용을 명확하게 말하고 대화를하거나 기술 능력을 무시하지 않아야합니다. 그들은 박쥐에서 바로 방어에있을 가능성이 높으므로 걱정을 확인하는 대신 해결해야합니다. 그들은 당신이 무의식적으로 자신의 편에 있다고 생각할 수 있도록이 대화에 대해 너무 분명하지 않고 의식 할 필요가 있으며, 그들이 관심을 가져 왔던 변화를해야한다는 것을 받아들이기를 바랍니다.

이것이 효과가 없다면 좀 더 공격적으로 시작할 수 있습니다. 회의실에서 제품을 실행할 수있는 경우 코드 검토 중에 프로젝터에서 제품을 가져 와서 버그를 직접 보여주십시오. 관리자가 바로 있으면 사람이 물러 설 수 없습니다. 이것은 부끄러운 것이 아니라 사용자가 실제로 문제를 해결하고 코드를 이해하는 대신 문제를 해결해야한다는 점을 받아들이도록 강요하는 것입니다.

결국, 당신이 아무데도 가지 않고, 유치원 학생처럼 사람을 대하는 데 지쳤으며, 경영진은 문제를 완전히 인식하지 못하며 코드 검토 자로서의 성과에 대해 잘 반영하지 못하거나 자신의 건강에 관심이 있습니다. 회사 및 / 또는 제품의 경우 상사와 대화를 시작해야합니다. 최대한 구체적이고 비인간적 인 태도를 취하십시오-생산성과 품질이 저하되는 비즈니스 사례를 만드십시오.

코드 검토는 유독하고 시간 낭비이며 생생한 괴상한 전쟁에 대한 의지가 될 수 있습니다. 깨끗한 코드 대 주석, 명명 규칙, 단위 및 통합 테스트, 전략 체크인, RESTfulness 등과 같은 것들에 대한 의견의 차이를 살펴보십시오.

이를 피할 수있는 유일한 방법 은 코드 검토를 통과하기위한 규칙을 작성하는 것입니다.

그렇다면 체크인에 실패하거나 승인하지 않은 사람이 아닙니다. 그들은 단지 규칙을 준수했는지 확인하는 것입니다.

그리고 그것들은 미리 기록되어 있기 때문에 코드를 작성할 때 규칙을 따를 수 있으며 추론을 설명하거나 나중에 논쟁을 할 필요가 없습니다.

규칙이 마음에 들지 않으면 회의를 열어 규칙을 변경하십시오.

귀하의 의견은 후원으로 간주 될 수 있으므로 귀하의 의견을 설탕으로 코팅하지 않습니다.

제 생각에는 모범 사례는 항상 코드에 집중하고 저자에게는 절대로 초점을 맞추지 않는 것입니다.

그것은의 코드 리뷰가 아닌 개발자 검토, 그래서 :

• "루프가 끝나지 않을 수도 있습니다"가 아니라 "이 루프가 끝나지 않을 수도 있습니다"
• "이 시나리오를 다루기 위해 테스트를 작성하지 않았습니다"가 아니라 "시나리오 X에 테스트 케이스가 필요합니다"

다른 사람들과의 검토에 대해 이야기하면서 동일한 규칙을 적용하는 것도 매우 중요합니다.

• "앤,이 코드에 대해 어떻게 생각하세요?"가 아니라 "앤, 당신은 존의 코드에 대해 어떻게 생각하십니까?"

코드 검토는 성능 검토를위한 시간이 아니므로 별도로 수행해야합니다.

지금까지 답변에 언급되지 않은 것에 놀랐습니다. 코드 리뷰에 대한 나의 경험은 드문 일이지만,

단일 메시지로 전체 병합 요청을 검토하는 이유는 무엇입니까?

코드 리뷰에 대한 나의 경험은 GitLab을 통한 것입니다. 다른 코드 검토 도구도 비슷하게 작동 할 것이라고 항상 상상했습니다.

코드 검토를 할 때 diff의 특정 개별 라인 에 대해 언급합니다 . 이다 매우 는 코드와 실제로에 논평하기 때문에, 개인 비판으로 수신 할 가능성이 표시 주석으로 코드에 코드 바로 아래에 표시 그것의 논평이다.

또한 전체 병합 요청에 대해 의견을 제시 할 수 있으며 종종 그렇게합니다. 그러나 diff의 특정 라인에서 특정 지점을 지적 할 수 있습니다. 또한 diff가 변경되도록 새 커밋을 추가하면 "오래된 diff"에 대한 주석이 기본적으로 숨겨집니다.

이 워크 플로우를 통해 코드 검토는 훨씬 모듈화되고 응집력이 떨어집니다. 코드 검토의 한 줄은 단순히

전용 기능으로 래핑하는 멋진 접근 방식!

또는 말할 수도 있습니다.

이 객체 이름은 실제로 객체의 목적과 일치하지 않습니다. 'XYZ'와 같은 이름을 대신 사용할 수 있을까요?

또는 섹션에 중대한 문제가 있다면 다음과 같이 쓸 수 있습니다.

나는이 코드가 작동하는 것을 보았고 왜 작동하는지 알지만 그것을 이해하려면 집중 연구가 필요합니다. 나중에 유지 관리하기 쉽도록 별도의 기능으로 리팩토링 할 수 있습니까?

(예 : 함수 ABC는 실제로 여기에서 foo를 괴롭 히고, boz를 금지하고, zorf를 프릿 핑하는 세 가지 작업을 수행합니다. 이들은 모두 별도의 함수일 수 있습니다.)

위의 내용을 모두 작성한 후 전체 병합 요청에 대해 다음과 같은 요약 의견을 작성할 수 있습니다.

이것은 새롭고 멋진 기능이며 병합되면 실제로 유용합니다. 함수 명명을 정리하고 내가 작성한 개별 의견에 언급 된 리팩토링을 처리 한 다음 다시 살펴 보도록 하시겠습니까? :)

병합 요청이 완전한 개 아침 식사 인 경우에도 개별 의견은 간단 할 수 있습니다. 더 많은 것이있을 것입니다. 그런 다음 요약 의견은 다음과 같이 말할 수 있습니다.

죄송하지만이 코드는 실제로 문제가되지 않습니다. 잘못 처리되고 사용자 경험이 좋지 않거나 한 번에 데이터가 손상 될 수있는 많은 경우가 있습니다 (개별 의견에 자세히 설명되어 있음). (커밋 438a95fb734에 대한 주석을 참조하십시오.) 일부 일반적인 사용 사례에서도 응용 프로그램 성능이 매우 저하 될 수 있습니다 (일부 파일에 대해서는 diff에 대한 개별 주석에 명시되어 있음).

생산 준비가 되려면이 기능은 흐름의 모든 지점에서 어떤 가정이 안전한지에 대해 더 많은주의를 기울여 완전히 다시 작성해야합니다. (힌트 : 확인되지 않은 가정은 안전하지 않습니다.)

전체 다시 쓰기 보류중인 병합 요청을 닫습니다.

요약 : 개별 코드 라인에 대한 주석으로 코드 의 기술적 측면을 검토하십시오 . 그런 다음 병합 요청에 대한 전체 주석으로 해당 주석을 요약 하십시오. 개인적으로 생각하지 마십시오 . 코더가 아니라 코드 에 대한 사실과 의견 에 대해 다루십시오 . 사실, 정확한 관찰 및 이해에 대한 귀하의 의견을 바탕으로하십시오.

아무도 그 사실을 알지 못해서 놀랐지 만 샘플 리뷰에 문제가 있습니다.

Joe에게 직접 연락해야 할 이유는 없습니다. Joe가 자신의 실패를 고치는 것은 당신의 사업이 아닙니다. 그건 누군가가 않습니다, 당신의 사업이다. 귀하의 우려는 코드 품질입니다. 따라서 요청 / 주문 / 수요를 작성하는 대신 (내가 Joe 인 경우 정당하지 않기 때문에 간단히 거부 할 수 있음) 역할을 유지하고 간단한 익명의 할 일 목록을 작성하십시오.

좋은 점과 나쁜 점을 공평하게하는 것은 불가능할뿐만 아니라 당신의 역할에서 완전히 벗어납니다.

다음은 리뷰에서 가져온 콘텐츠로 재구성 한 예입니다.

• Library \ ACME \ ExtractOrderMail 클래스에서 변경 사항을 가져 오기 전에 몇 가지 문제를 해결해야합니다.
• 내가 놓친 것이 아니라면 "TempFilesToDelete"는 정적이어서는 안됩니다.
• 앞으로는 실행마다 함수를 두 번 이상 호출 할 수 있으므로 이것이 필요한 이유입니다 (여기서 수행해야 할 작업).
• "GetErrorMailBody"가 예외를 매개 변수로 사용하는 이유를 이해해야합니다. (그리고 지금은 경계선이되고 있습니다. 왜냐하면 지금은 이미 결론 이 있어야하기 때문입니다 )
• 예를 들어 "SendErrorMail"과 같이 SaveAndSend의 동작에보다 적합하도록 이름을 바꿔야합니다.
• 주석 처리 된 코드는 가독성을 위해 삭제해야합니다. 최종 롤백에는 Subversion을 사용합니다.

독자가 당신을 개인적으로 미워하는 정도에 관계없이 리뷰를 공식화하면, 여기에서 볼 수있는 것은 누군가가 나중에 수행해야 할 개선 사항에 대한 메모입니다. 누구? 언제 ? 아무도 신경 쓰지 않습니다. 뭐 ? 왜 ? 당신이 말해야 할 것.

이제 코드 검토에서 인적 요소를 제거하여 긴장이 고조되는 이유를 다루겠습니다.

코드 검토의 핵심은 문제를 찾는 것입니다. 버그 가 있는 경우 실패한 테스트 사례를 작성하는 것이 가장 좋습니다.

팀 (매니저)은 버그 생성이 게임의 일부라는 사실을 알려 주어야하지만 버그를 찾아 수정하면 모든 사람의 작업 이 저장됩니다 .

정기적 인 회의 (팀 또는 페어)를 갖고 몇 가지 문제를 해결하는 것이 도움이 될 수 있습니다. 원래 프로그래머는 의도적으로 문제를 일으키지 않았으며 때로는 문제가 충분하다고 생각할 수도 있습니다. 그러나 두 번째 쌍의 눈을 갖는 것은 완전히 새로운 시각을 제공하며 문제를 살펴보면 크게 배울 수 있습니다.

그것은 실제로 문화적인 것이며 많은 신뢰와 의사 소통이 필요합니다. 그리고 결과를 다루는 시간.

긍정적 인 조치는 리뷰를하기 전에 코딩 표준에 대한 합의를 얻는 것입니다. 다른 사람들은 입력을 받았을 때 더 많은 것을 사려고합니다.

명명 규칙과 같은 경우 다른 사람에게 이것이 중요한지 물어보십시오. 대부분의 개발자는 특히 동료들 사이에 동의합니다. 프로그래밍 세계에서 널리 퍼져있는 것에 동의하지 않는 사람이되고 싶은 사람은 누구입니까? 누군가의 코드를 고르고 결함을 지적하여 프로세스를 시작하면 매우 방어 적입니다. 표준이 정립되면 해석 또는 "충분히 좋은"것으로 간주되는 것에 대해 의견이 일치하지 않지만 현재보다 나아지는 편입니다.

이 프로세스의 또 다른 부분은 코드 검토가 이의 제기를 처리하는 방법을 결정하는 것입니다. 이것은 끝없는 논쟁이 될 수 없습니다. 어느 시점에서 누군가는 결정을 내려야합니다. 어쩌면 제 3자가 판사가 될 수 있거나 검토자가 모든 권한을 얻을 수 있습니다. 목표는 달성해야 할 일입니다.

이것의 마지막 부분은 Code Reviews가 당신의 아이디어가 아니라는 것을 모든 사람들에게 알리는 것입니다. 모두가 힘이 없다고 생각되면 코드를 검토 할 수 있습니까?

바라건대, 관리에 대한 측정 가능한 결과는 버그, 고객 불만, 지연 등을 제한하는 것입니다. 그렇지 않으면 누군가가 방금 "코드 검토"라는 단어를 듣고 프로세스에 추가하면 많은 시간과 에너지없이 기적이 일어날 것입니다. 노력은 이것에 넣어.

이것은 가혹할 수 있지만 측정 할 것이 없다면 좋은 피드백을주는 것에 대해 걱정하지 마십시오.

그러나 앞으로 개발자가 코드를 개선하기 시작하면 좋은 피드백을주고 싶을 것입니다. 코드의 개선 사항을 지적하고 팀 전체의 이점을 지적하고 싶을 것입니다. 개선이 시작될 때에도 개선이 이루어지고 천천히 일이 시작됩니다.

또 다른 한가지; 마치 말이없는 것처럼 느끼기 때문에 방어적인 공기가있을 수 있습니다. 서로의 코드를 검토하게하지 않겠습니까? 구체적인 질문을하고 참여하도록하십시오. 그들 대 당신이되어서는 안됩니다. 팀 노력이되어야합니다.

1. 시간이 있다면이 코드에서 무엇을 바꾸겠습니까?
2. 코드베이스의이 영역을 어떻게 개선 하시겠습니까?

지금 물어보고 6 개월 후에 물어보세요. 여기에 학습 경험이 있습니다.

요점-보증되지 않는 코드의 관점에서 칭찬하지 말고 노력을 인정하고 확실히 개선을 인정하십시오. 적대적인 것이 아니라 팀 운동을 검토해보십시오.

장력없는 품질

코드에 대해 긍정적 인 말을하는 방법을 물었지만 실제 질문은 "심각한 품질 문제"를 해결하면서 "[팀] 내 긴장을 피할 수있는 방법"입니다.

"좋은 소식에 나쁜 소식"을 끼우는 오래된 속임수는 역효과를 낳을 수 있습니다. 개발자는 그것이 무엇인지에 대해 그것을 볼 가능성이 높습니다.

조직 하향식 문제

상사는 품질을 보장하는 임무를 맡았습니다. 코드 품질 기준 목록을 작성했습니다. 이제 긍정적 인 강화를위한 아이디어가 팀에 제공되기를 원합니다.

팀을 행복하게하려면 어떻게해야합니까? 팀에 문의하는 것을 고려 했습니까?

당신이 멋지게 최선을 다하고있는 것 같습니다. 문제는 메시지를 전달하는 방법이 아닙니다. 문제는 커뮤니케이션이 일방 통행이라는 것입니다.

양질의 문화 구축

양질의 문화는 처음부터 끝까지 성장해야합니다.

상사가 품질이 충분히 향상되지 않는다고 우려하고 있으며 하버드 비즈니스 리뷰 (Harvard Business Review)의 조언을 적용하려고 합니다.

팀과 만나십시오. 팀에서보고 싶은 행동 : 겸손, 존중 및 개선 약속.

“아시다시피, [동료]와 저는 최근에 겪었던 생산 문제를 방지하기 위해 코드 품질을 보장해야했습니다. 나는 개인적 으로이 문제를 해결했다고 생각하지 않습니다. 내 가장 큰 실수는 처음에는 더 이상 당신과 관련이 없다고 생각합니다. [동료] 그리고 저는 코드 품질 관리에 대해 여전히 책임 을 지고 있지만 앞으로도 우리 모두는 함께 품질 노력을하고 있습니다.”

코드 품질에 대한 팀의 아이디어를 얻으십시오. (화이트 보드가 도움이 될 것입니다.) 요구 사항이 끝날 때까지 확인하십시오. 정중 한 방식으로 통찰력을 제공하고 적절한 경우 질문하십시오. 팀이 느끼는 것에 기꺼이 놀라십시오. 비즈니스 요구에 영향을주지 않으면 서 융통성이 있습니다.

(당신이 부끄러운 구식 코드를 가지고 있다면, 모든 사람들이 솔직 해 지도록 장려 할 수 있습니다. 결국 사람들에게 당신이 작성한 것을 알려주십시오. 다른 사람들이 건축 비평을받을 때 바라는 성숙한 반응을 모델링하십시오. )

협업 코드 검토

몇몇 수석 프로그래머가 모든 코드를 검토하고 수정하는 설명과 같은 곳에서 일하지 않았습니다. 선생님이 논문에 빨간 표시를하는 것처럼 응답하는 사람들은 당연합니다.

아이디어를 관리에 팔 수 있다면 피어 코드 검토를 시작하십시오 . 이것은 귀 하나 다른 책임 개발자를 포함한 소규모 그룹에서 가장 잘 수행됩니다. 모든 사람을 존중해야합니다.

동료 검토 코드의 중요한 목표는 팀의 모든 구성원이 코드를 이해할 수 있도록하는 것입니다. 불명확 한 함수 이름의 예를 생각해보십시오. 상급 개발자로부터 함수 이름이 혼동되는 것이 수석 개발자의 다른 "수정"보다 쉽게 ​​받아 들일 수 있다고 들었습니다.

품질은 여행입니다

또 다른 방법은 코드 검토가 통과 / 실패 유형이라는 개념을 정리하는 것입니다. 모든 사람은 코드 검토 후 약간의 수정을해야합니다. (그리고 당신의 임무는 그들이 일어나도록하는 것입니다.)

그러나 그것이 효과가 없다면 ...

양질의 문화를 확립하기 위해 약간의 발전을했다고 가정 해 봅시다. 여전히 모든 사람이 탑승하지 못할 수도 있습니다. 누군가가 여전히 품질 프로그램을 가지고 있지 않다면 이제 문제는 둘 사이에 문제가있는 것이 아니라 팀에 적합하지 않다는 것입니다. 팀에서 해고해야 할 경우 나머지 팀은 이유를 더 잘 이해할 것입니다.

또 다른 긴 대답에 대해 죄송하지만 다른 사람들 이이 문제의 인적 요소를 완전히 다루지 않았다고 생각합니다.

때로는 특정 방식으로 구현 된 이유를 묻기도합니다. 그것이 나쁘다고 생각하면 다른 방법으로 개발했을 것이라고 지적합니다.

"왜 이런 식으로 구현 했습니까?" 개발자를 즉시 ​​방어에 두는 것입니다. 질문 자체는 상황에 따라 모든 종류의 것을 암시 할 수 있습니다. 더 나은 솔루션을 생각하기에는 너무 어리 석습니까? 이것이 최선입니까? 이 프로젝트를 망치려고합니까? 작업 품질에 관심이 있습니까? 코드가 특정한 방식으로 개발 된 이유를 묻는 것은 대립 일 뿐이며, 귀하의 의견에 대한 교육 학적 의도를 전복시키는 것입니다.

마찬가지로 "나는 이것을 다르게 했었을 것이다 ..."는 또한 대립적이다. 왜냐하면 개발자가 가질 수있는 즉각적인 생각은 " 이런 식으로 해봤 어 .. 문제가 생겼 니? "그리고 다시, 그것은 대립적이다. 토론을 코드 개선에서 멀어지게해야합니다.

예:

묻는 대신 "왜 당신은이 값 상수 변수를 사용하지 않도록 선택 했습니까?", 단순히 "이 하드 코딩 된 값이 상수로 대체해야합니다 상태 XYZ파일의 Constants.h문제는 개발자가 적극적으로 선택한 것을 제안 요구" 하지 를 사용하는 이미 정의 된 상수이지만, 그것이 존재한다는 사실조차 몰랐을 수도 있습니다. 코드가 충분히 크면 각 개발자가 알지 못하는 것이 많이 있습니다. 이는 개발자가 프로젝트 상수에 익숙해지기위한 좋은 학습 기회입니다.

코드 리뷰와 함께 걸을 수있는 좋은 라인이 있습니다. 당신이 말하는 모든 것을 설탕 코팅 할 필요가 없으며, 나쁜 소식을 좋은 소식과 함께 넣을 필요가 없으며, 타격을 부드럽게 할 필요가 없습니다. 그것은 내가 속한 문화 일 수 있지만, 동료와 나는 코드 리뷰에서 서로를 칭찬하지 않습니다. 우리가 개발 한 코드에서 결함이없는 부분은 칭찬으로 충분합니다. 당신이해야 할 일은 당신이보고있는 결함을 식별하고 아마도 이유를 제시하는 이유 일 것입니다 (이유가 명백하고 단순 할 때 왜 그다지 유용하지 않은지).

좋은:

• "이 변수의 이름은 코딩 표준과 일치하도록 변경해야합니다."

• "PascalCase가 되려면이 함수 이름의 'b'를 대문자로 입력해야합니다."

• "이 함수의 코드가 제대로 들여 쓰기되지 않았습니다."

• "이 코드는에있는 코드와 중복 ABC::XYZ()되므로 해당 함수를 대신 사용해야합니다."

• " 오류가 발생하더라도이 기능에서 항목이 올바르게 닫히도록 자원 사용 시도 를 사용해야 합니다." [자바가 아닌 사용자가 try-with-resources의 의미를 알 수 있도록 여기에 링크 만 추가했습니다.]

• "우리의 n-path 복잡성 표준을 충족시키기 위해서는이 기능을 리팩토링해야합니다."

나쁜:

• " 표준과 일치하도록 변수 이름을 변경하여이 코드를 개선 할 수 있다고 생각 합니다."

• " 아마도이 함수에서 try-with-resource를 사용하여 항목을 올바르게 닫는 것이 좋습니다."

• " 이 기능의 모든 조건을 다시 한 번 검토하는 것이 바람직 할 수 있습니다. N- 경로 복잡도는 표준의 최대 허용 복잡도를 초과합니다."

• "왜 표준의 4 개 대신에 2 개의 들여 쓰기가 있는가?"

• "n-path 복잡성 표준을 어기는 함수를 왜 작성 했습니까?"

잘못된 설명에서 이탤릭체로 표시된 부분은 사람들이 타격을 완화하고자 할 때 일반적으로 사용하는 것들이지만 코드 검토에서 실제로하는 일은 자신을 불확실하게 들리게하는 것입니다. 리뷰어 인이 코드를 개선하는 방법을 확신하지 못한다면 왜 내 말을 들어야합니까?

'좋은'진술은 무뚝뚝하지만 개발자를 비난하지 않으며 개발자를 공격하지 않으며 대립적이지 않으며 결함이 왜 존재하는지 의심하지 않습니다. 존재합니다. 여기 수정이 있습니다. 그들은 마지막 '왜'질문만큼 대립적이지 않습니다.

당신이 보는 문제는 다음과 같습니다. 개발자들은 자신의 코드가 비판 된 것에 대해 불행합니다. 그러나 그것은 문제가 아닙니다. 문제는 코드가 좋지 않다는 것입니다 (코드 리뷰가 양호하다고 가정).

개발자가 자신의 코드가 비판을 끄는 것을 좋아하지 않는다면 해결책은 쉽습니다. 더 나은 코드를 작성하십시오. 코드 품질에 심각한 문제가 있다고 말합니다. 그것은 더 나은 코드가 필요하다는 것을 의미합니다.

"이 방법이 합리적인 이름을 가져야하는 이유는 무엇입니까?" 내가 특히 혼란스럽게 생각하는 것입니다. 그는 그것이 무엇을하는지, 적어도 그는 그렇게 말하지만, 나는 그렇지 않습니다. 모든 메소드는 적절한 이름을 가져서는 안되며, 코드의 독자에게 그것이하는 일을 즉시 명확하게하는 이름을 가져야합니다. Apple의 웹 사이트를 방문하여 Swift 2에서 Swift 3으로의 변경 사항에 대한 WWDC 비디오를 찾아보십시오. 모든 것을 더 읽기 쉽게 만들기 위해 많은 변경 사항이 있습니다. 아마도 이런 종류의 비디오는 개발자보다 훨씬 똑똑한 개발자가 직관적 인 분석법 이름이 매우 중요하다는 것을 개발자에게 확신시킬 수 있습니다.

또 다른 방해물은 "고객이 버그 보고서를 제출 한 후 버그를 알고 있지만 개발자가 지적한 것에 대해 개발자에게 화를 낼 까봐 두려웠다"고 자신에게 말했다. 이 몇 가지 오해가있을 가능성이 있지만, 당신이 그들에게 버그를 지적하면 개발자가 화가 얻는 경우에, 그 나쁘다.

귀하가 설명한 코드 검토 방법에 대해 동의하지 않습니다. '폐쇄 된 방'에 들어가서 비판을받는 두 명의 직원 은 좋은 코드 검토를 피해야 한다는 일종의 적대적인 개념을 제도화 합니다 .

코드 검토를 가능한 한 긍정적 인 경험으로 만드는 것이 성공하기 위해서는 필수적입니다. 1 단계는 적대적인 검토 개념을 제거하는 것입니다. 매주 또는 격주 그룹 이벤트로 만드십시오 . 누구나 참여할 수 있음을 모두 알도록하십시오. 피자 나 샌드위치 등으로 주문하십시오. 부정적인 의미를 불러 일으키면 그것을 '코드 리뷰'라고 부르지 마십시오. 현재의 스프린트 또는 반복을 통해 진행되는 것 이상이더라도 축하하고 격려하고 공유 할 무언가를 찾으십시오. 검토에 리더십을 교대로 할당하십시오.

제품과 사람들에게 서비스를 제공하기 위해 노력하십시오. 그것들이 건설적으로, 긍정적으로 이루어지면, 좋은 기술이나 패턴은 가난한 사람들이 낙담하는 것처럼 공유되고 장려됩니다. 모두가 공개 코치를받습니다. "문제가없는"문제가있는 프로그래머라면 더 큰 그룹 앞에서는 사적으로나 개별적으로 다루어야합니다. 코드 검토와는 별개입니다.

제기하기 위해 "좋은"것을 찾는 데 어려움이 있다면, 그 질문을 제기 할 수 있습니다. 당신이 진정으로 찾을 수없는 경우 아무 것도 좋은, 그 마지막 검토 중 하나이기 때문에 해본 적이 모든 것을 의미한다 나쁜 나보다 더 나은 중립을 . 정말 그렇습니까?

세부 사항은 공통 표준이 필수적입니다. 수행중인 작업에 모든 사람에게 스테이크를 제공하십시오. 또한 더 새롭고 더 나은 기술을 코드 기반에 통합 할 수 있습니다. 그렇게하지 않으면 "우리는 항상 그런 식으로 해왔다"는 식으로 오래된 습관을 보장받지 못합니다.

이 모든 요점은 코드 리뷰가 제대로 구현되지 않았고 경험이 적거나 숙련되지 않은 프로그래머를 망치로 사용하기 때문에 코드 검토에 약간의 나쁜 랩이 주어진다는 것입니다. 이런 방식으로 사용하는 관리자는 매우 효과적인 관리자가 아닐 수도 있습니다. 모든 사람이 참여자 인 제품, 직원 및 회사와 같이 모든 사람에게 서비스를 제공하는 올바른 코드 검토.

게시물 길이에 대한 사과가 있었지만 코드 검토가 크게 무시되는 그룹에 있었기 때문에 유지 관리 할 수없는 코드의 유산이 있었고 수년간 오래된 코드베이스를 변경할 수있는 경우에도 좁은 범위의 개발자만이 가능했습니다. 다시 횡단하지 않기로 선택한 경로였습니다.

좋은 코드의 역설은 전혀 눈에 띄지 않으며 매우 간단하고 작성하기 쉬운 것처럼 보입니다. 이 답변 의 풀 플레이어 예제를 정말 좋아합니다 . 코드 리뷰에서 그것은 나쁜 코드에서 리팩터링되지 않는 한 정말 쉽게 광택을 내도록 해줍니다.

나는 그것을 찾아야한다. 코드를 검토하고 있고 읽기가 매우 쉬운 파일을 통해 읽기가 쉽지 않은 것처럼 보이는 경우, "여기에서 방법이 짧고 깔끔한 방식이 마음에 듭니다"또는 적절한 것이 무엇이든 빠르게 처리합니다. .

또한 예를 들어 이끌어야합니다. 코드도 검토하도록 요구해야하며 수정을받을 때 팀의 행동 방식을 모델링해야합니다. 가장 중요한 것은 피드백에 대해 진심으로 사람들에게 감사해야한다는 것입니다. 이것은 당신이 줄 수있는 일방적 인 피드백보다 더 큰 차이를 만듭니다.

실제 문제는 모든 코드 검토를 수행하는 사람이 두 명 뿐이며 심각하게 생각하는 사람만이 많은 책임과 많은 불행으로 불행한 상황에 처하게된다는 것입니다. 다른 팀원의 압력.

더 나은 방법은 팀 전체에 코드 검토를 수행하는 책임을 분산시키고 모든 사람이 참여하도록하는 것입니다 (예 : 개발자가 코드를 검토 할 대상 선택). 이것은 코드 검토 도구가 지원해야하는 것입니다.

나는 이것이 직접 발생하는 것을 보았고 감성 지능 도전 답변 에서 멀리주의를 기울이고 싶습니다 . 팀 전체를 죽일 수 있습니다. 매년 새로운 개발자를 모집, 교육 및 정규화하지 않는 한 동료와 긍정적 인 관계를 형성하는 것이 필수적입니다. 결국, 코드 품질을 개선하고 코드 품질이 더 높은 문화를 조성하기 위해 이러한 검토를 수행하는 것이 중요하지 않습니까? 이 코드 검토 시스템을 팀 문화에 통합하는 수단으로 긍정적 인 강화를 제공하는 것이 실제로 당신의 일의 일부라고 주장합니다.

어쨌든 코드 검토 시스템을 검토해야 할 것 같습니다. 바로 지금, 그 소리에서 검토 과정의 모든 것이 객관적인 것이 아니라 주관적인 것으로 해석 될 수 있습니다. 누군가가 가이드 라인에 맞지 않을 때 인용 할 수있는 이유가 아니라 코드가 마음에 들지 않기 때문에 누군가 코드를 고르는 것처럼 느껴질 때 상처를 받기 쉽습니다. 이렇게하면 사무실 문화에 적합한 방식으로 코드 품질의 긍정적 인 개선 (추천 시스템과 관련하여)을 쉽게 추적하고 '축하'할 수 있습니다.

기술 책임자는 검토 세션 외부에서 함께 모여 코딩 지침 / 코드 검토 체크리스트를 작성해야하며 검토 중에 준수하고 참조해야합니다. 이것은 프로세스가 발전함에 따라 업데이트되고 개선 될 수있는 살아있는 문서 여야합니다. 이 테크 리드 회의는 개발자가 의견 불일치가 코드의 결과라고 생각하지 않고 '항상 우리가 항상 해왔 던 일'과 '새롭고 개선 된 일을하는 방식'에 대한 논의가 이루어져야 할 때가되어야합니다. 초기 지침이 다소 완화되면 개발자를 적극적으로 강화하는 또 다른 방법은 피드백을 요청한 다음 실제로 조치를 취하는 것입니다. 팀으로 프로세스를 발전 시키려면 온보드 코드를 검토하기 시작하는 속도가 빨라져서 은퇴 할 때까지 검토를하지 않아도됩니다.

가옥...

프로그래머는 문제를 해결합니다. 문제 나 오류가 발생하면 디버깅을 시작하도록 조정되었습니다.

코드는 개요 형식의 매체입니다. 피드백을 위해 단락 형식 설명으로 전환하면 연결이 끊어 져야합니다. 불가피하게 무언가를 잃어 버리거나 오해하게됩니다. 불가피하게, 리뷰어는 프로그래머의 언어로 말하지 않습니다.

컴퓨터에서 생성 된 오류 메시지는 거의 질문을받지 않으며 결코 개인적인 문제로 간주되지 않습니다.

코드 검토 항목은 사람이 생성 한 오류 메시지입니다. 프로그래머와 자동화 된 도구가 놓칠 수있는 최첨단 사례와 다른 프로그램 및 데이터에 대한 불가피한 부작용을 포착하기위한 것입니다.

결론 ...

따라서 더 많은 코드 검토 항목을 자동화 된 도구에 통합할수록 더 잘받을 수 있습니다.

의문의 여지없이, 이러한 도구는 절차, 표준 및 관행에 대한 모든 변경 사항을 준수하도록 보통 매일 또는 매주 지속적으로 업데이트해야합니다. 관리자 또는 개발자 팀이 변경하기로 결정한 경우이를 적용하려면 도구를 변경해야합니다. 코드 검토 자의 많은 작업이 도구에서 규칙을 유지 관리하게됩니다.

코드 검토 피드백 예 ...

이 기술들을 통합 한 주어진 예제의 재 작성 :

• 제목:

  • 라이브러리 \ ACME \ ExtractOrderMail 클래스.

• 원칙 문제 ...

  • TempFilesToDelete는 정적입니다
    • 이후에 GetMail에 대한 호출은 파일이 추가되었지만 삭제 후에는 제거되지 않기 때문에 예외를 발생시킵니다. 지금은 한 번의 전화 만하더라도 향후 몇 가지 병렬 처리로 성능이 향상 될 수 있습니다.
    • 인스턴스 변수 인 TempFilesToDelete를 사용하면 여러 객체를 동시에 사용할 수 있습니다.
• 이차 문제 ...
  • GetErrorMailBody에 예외 매개 변수가 있습니다
    • 예외 자체를 던지지 않고 ToString에 전달하기 때문에 필요합니까?
  • SaveAndSend 이름
    • 앞으로 이메일을보고하는 데 이메일이 사용되거나 사용되지 않을 수 있으며이 코드에는 영구 사본을 저장하고 오류를보고하는 일반적인 논리가 포함되어 있습니다. 보다 일반적인 이름은 종속 방법으로 변경하지 않고도 이러한 예상되는 변경을 허용합니다. 한 가지 가능성은 StoreAndReport입니다.
  • 오래된 코드 주석 처리
    • 주석 처리되고 주석이 표시된 OBSOLETE를 남겨두면 디버깅에 매우 도움이 될 수 있지만 "주석"은 인접한 코드의 오류를 가릴 수도 있습니다. 우리는 여전히 Subversion에 있습니다. 아마도 Subversion의 정확한 위치를 나타내는 주석일까요?

기존 코드에 대해 할 말이 없다면 (이해할 수있을 것 같음) 개발자가 코드를 개선하도록 참여 시키십시오.

기능 변경 또는 버그 수정 패치에서는 다른 변경 (이름 변경, 리팩토링 등)을 동일한 패치에 묶는 것이 도움이되지 않습니다. 버그를 수정하거나 기능을 추가하도록 변경해야합니다.

이름 변경, 리팩토링 및 기타 변경 사항 이 표시되면 전후에 별도의 패치로 변경하십시오 .

• 이것은 추악하지만 다른 모든 불쾌한 코드와 일치한다고 생각합니다. 나중에 기능적으로 변경되지 않는 패치로 정리해 보겠습니다 .

  당신이 리팩토링에 참여하고 할 경우에도 도움이 들을 검토 하여 코드를. 그것은 왜 당신이 무언가가 나쁘기보다는 좋다고 생각하는지 말할 수있는 기회를 제공하고 건설적인 비판을 잘 보여주는 예를 보여줍니다.

새로운 기능에 단위 테스트를 추가 해야하는 경우 기본 패치로 진행됩니다. 그러나 버그를 수정하는 경우 테스트가 이전 패치로 진행되어 통과하지 않아야 버그가 실제로 수정되었음을 확인할 수 있습니다.

작업이 완료되기 전에 계획을 수정하는 방법 (리 팩터를 테스트하는 방법 또는 리팩토링 대상 및시기)을 논의하는 것이 이상적이므로 문제가 발생하기 전에 많은 노력을 기울이지 않았습니다.

코드가 입력에 대처하지 못한다고 생각되면 개발자가 합리적인 입력으로 보는 것과 일치하지 않을 수도 있습니다. 가능하다면 미리 동의하십시오. 적어도 대처할 수 있어야하는 것과 그것이 얼마나 실패 할 수 있는지에 대해 적어도 토론을하십시오.

"나의 표준에 따라 업무를 판단 할 때 동료들이 화가 나서 그것을 강제 할 힘이있다"는 기술적이거나 쉬운 해결책이 있다고 생각하는 것은 실수라고 생각합니다.

코드 검토는 단지 좋은 것과 나쁜 것에 대한 토론이 아니라는 것을 기억하십시오. 그것들은 암묵적으로 "우리가 누구를 사용하고 있습니까?", "결정을 내리는 사람"이며, 따라서 가장 냉담한 순위입니다.

그 점을 다루지 않으면 문제가 발생하지 않는 방식으로 코드 검토를 수행하는 것이 어려울 것입니다. 여기에 방법에 대한 좋은 조언이 있지만 어려운 작업을 설정했습니다.

흔들리는 방없이 옳다면 그것을 지적하는 것이 공격이다. 누군가 엉망이되어 버린다. 그렇지 않은 경우 : 다른 MBA를받지 못한 사람. 어느 쪽이든, 당신은 나쁜 사람이 될 것입니다.

그러나 리뷰의 내용과 이유 가 명확하고 합의 된 경우 나쁜 사람이되지 않을 가능성이 높습니다. 당신은 문지기가 아니라 교정자입니다. 이 계약을 얻는 것은 해결하기 어려운 문제입니다 [1]. 나는 당신에게 조언을하고 싶지만 아직 그 자신의 걸림돌을 얻지 못했습니다 ...

[1] 사람들이 "좋아요"라고 말하거나 그것에 대해 싸우지 않기 때문에 해결되지 않습니다. 아무도 X가 우리의 {지능, 경험, 인력, 마감일 등}에 실용적이지 않다고 말하는 사람이되고 싶지는 않지만 X를 실제로 수행하는 특정 사례에 실제로 적용되는 것은 아닙니다.

코드 검토는 상호 적이어야합니다. 모두가 모두를 비난했습니다. 좌우명을 "화 내지 말고 균등하게하십시오." 모든 사람들이 실수를 저지르고 사람들이 코드를 고치는 방법에 대해 핫 샷을 말하면 이것이 정상적인 절차이며 공격이 아니라는 것을 이해할 것입니다.

다른 사람들의 코드를 보는 것은 교육적입니다. 약점을 지적 할 수있는 지점까지 코드를 이해하고 약점은 많은 것을 가르쳐 줄 수 있다고 설명해야합니다 !

요점은 결함을 찾는 것이기 때문에 코드 검토에서 칭찬의 여지가 거의 없습니다. 그러나 픽스 에 대한 칭찬을 쌓을 수 있습니다 . 적시성과 깔끔함을 칭찬 할 수 있습니다.