코드 검토 아이디어를 싫어하는 사람을 다루는 방법?

분명히, 경영진이 코드 검토를 통해 시간을 투자한다면 모두가 그렇게해야합니다.

그러나 그들의 존재에 대해 저항하는 사람들은 항상 있습니다.

이 시나리오를 동료 검토 자로 취급 할 때이 시나리오를 어떻게 효과적으로 관리합니까?

그는 두려움 때문에 저항한다 . 이 컨디셔닝 은 아이, 학교, 직장 또는 현재 팀에서 검토 한 경험이 이전에 좋지 않은 결과 일 수 있습니다. 현대 사회에서 우리는 누군가의 작업 결과를 인간으로서의 그의 가치와 혼동하는 것이 매우 일반적입니다. 그것이 직장에서의 리뷰가 잘 인식되지 않는 이유입니다. 그렇기 때문에 가장 널리 퍼진 공포증 중 하나 (공포에 대한 두려움)에서 공개 연설을하는 이유도 있습니다.

그러한 행동을 피하려면 심리학이 필요합니다. 당신은 그의 도마뱀 뇌 에 코드 리뷰에 대한 감수성을 줄임 으로써 ( 판사 , 굴욕, 살해 등의 일이 발생하지 않을 것임) 증명해야합니다 .

내가 누군가를 차단 해제하는 가장 효과적인 방법 중 하나는 코드 를 검토하기 전에 코드를 검토 하도록 요청하는 것 입니다.

잠시 후, 제안 그것으로부터 배울 자신의 코드를 읽고 그를 왜하지 제안 개선. 변경할 내용을 찾으면 작성하는 내용에주의하십시오. 그는 두려워 할 것이 없다는 것을 이해하고 검토 과정의 긍정적 인 부분, 즉 지식을 배우고 늘리는 것 입니다.

아이디어를 좋아하는 사람과 아이디어를 싫어하는 사람을 팀으로 묶고 몇 주 동안 서로의 코드를 검토하도록합니다. 분명히 이것은 도움이 될 수도 있고 아닐 수도 있지만, 검토의 양쪽 끝에 있으면 프로세스에 대한 더 둥근 견해를 갖게 될 것입니다. 한 쌍이 함께 일하면 서로의 스타일과 일반적인 실수에 익숙해지고 고무 도장보다는 서로 더 나아질 수 있도록 실제로 시간을 줄 수 있습니다. 또한 검토뿐만 아니라 처음부터 다시 코딩하거나 계획 및 코딩하는 경향이 커질 수 있으므로 작업 환경에서 페어 프로그래밍을 약속하는 데 도움이 될 수 있습니다.

관심이없는 당사자가 기꺼이 시도하는 한 도움이 될 수 있습니다. 그들이 그것을 고려하지 않으면, 그들이 팀에있는 한 당신이 할 수있는 일은 많지 않습니다.

@Pierre의 답변은 코드 검토를 두려워하는 사람에게 적합합니다. 다른 상황을 상상할 수 있습니다. 코드 검토를 느끼는 스타 프로그래머는 코드가 허용 가능한 품질 및 정확성 표준에 도달하기 때문에 시간 낭비입니다. 이 경우 코드 검토가 시간 낭비이며 마녀 사냥이라고 느낄 수 있습니다. (아무 것도 없을 때 문제를 찾는 것입니다.)

이 경우 검토 목표의 방향을 바꾸겠습니다. 코드 검토에서 코드에서 "문제"를 찾는 대신 리팩토링 대상 또는 향후 개선 사항 또는 추가 디자인 기능을 검색하십시오. 이러한 방식으로, 코더와 검토자가 프로세스에 관여하며이 유능한 코더가 시간이 잘 활용되고있는 것처럼 느낄 수 있기를 바랍니다.

솔직히, 잘 관리 된 상점이 있다면이 질문은 의미가 없습니다.

1) 직업의 일부라면 반드시해야하거나 그렇지 않은 사람이어야합니다. 그들이해야 할 일의 일부를 열심히 거부하는 사람은 통조림을 받아야합니다. 프로그래밍은 기술이자 직업입니다. 검토 자와 관리자는 나이에 관계없이 버릇없는 아이들을 다루지 않고 일을 끝내도록 도와줍니다.

2) 잘 관리 된 소스 제어 시스템 (전문 소프트웨어 상점에서 필수)을 보유하고 있다면 원하는지 여부에 관계없이 해당 코드를 검토 할 수 있습니다. 따라서 코드를 검토하십시오.

• 그것이 좋으면 그들에게 알리고 등을 두드려주십시오-참여를 장려 할 것입니다.

• 좋지 않다면 그들에게도 알려주십시오. 이것은 자신을 방어하기 위해 참여 동기를 부여하는 효과가 있어야합니다. 그렇지 않은 경우, 벌금, 재정적 처벌, 상태 저하 등의 징계 조치를 사용할 수 있습니다. 귀하의 노력에도 불구하고이 직원이 출근하지 못하면 IMO에 나쁜 직원이 있으며 문을 보여 주어야합니다.

코드 검토가 제대로 수행되지 않은 곳에 부정적인 경험이 있습니까? 합법적 인 우려가있을 수 있습니다.

그들이 운동에 대한 장점을 전혀 보지 못한다면, 참을성있게 요청하고 결과적으로 그들의 코드와 특히 다른 사람들 (그들이 완벽하다고 생각한다면)에 어떤 일이 일어나는지보십시오.

Code Review는 개발을 개선해야하지만 실제로 작동하는 시스템이 생길 때까지 누구나 왜 그렇게해야합니까?

저는 개인적으로 인구의 100 %가 이길 수없는 싸움이 있다고 개인적으로 말합니다.

누군가가 강제로 할 때 페어 프로그래밍이 작동하지 않는 충분한 이유를 알 수 있습니다.

그러나 코드 검토는 다릅니다. 업무 습관이 아니라 생산성을 변화시킵니다.

경영진은 생산성으로 인한 저항을 줄이기 위해 다음과 같은 몇 가지 작업을 수행 할 수 있습니다. 1) 모든 개발자의 속도 감소를 수용하십시오. 2) 검토 주기로 인해 여러 버전의 관리 및 병합을 처리 할 수있는 적절한 도구를 제공합니다 (예 : 개발자가 로컬 git 저장소를 가질 수 있도록 허용). 리뷰.

그들이 그렇게한다면, 모든 사람이 참여하도록 요구하는 것이 합법적입니다, IMHO. 내가 지금 전 세계적으로이 일을하는 회사는 소유자의 승인 없이는 제출할 수 없습니다. 그리고 이것이 속도를 늦추는 동안 많은 사고를 예방합니다.

우리는 코드 검토를 의무화하기 위해 기술적 조치를 사용했습니다.

코드 검토를 도입 한 방식은 소스 제어에서 다른 사람이 서명하지 않은 코드를 푸시 한 코드를 병합하는 것이 불가능하다는 것입니다.

그들을 해고

그것은 고독한 사람 프로젝트를 얻거나 가야만하는 것이 간단합니다. 팀에서 멀리 떨어지십시오. 그들은 자신의 역할을 수행 할뿐만 아니라 팀의 사기와 관행을 약화시킵니다.

팀의 50 %를 해고해야한다면 ...

알다

왜 거부합니까? 그들은 시간이 없습니까? 타 버렸나요? 경험이없는 것에 대한 리뷰입니까? 그들은 왜 시간 낭비라고 생각합니까?

민첩한 방법론이 도움이 될 것입니다-나는 당신이 사일로에 대해 끊임없이 노력하고 있다고 가정하고 있습니다 (즉, 버스 팩터를 줄이기 위해). 팀의 개인이 다른 사람들의 일에 관여하고 있다고 가정합니다.

개별 병합 요청이 매우 작도록 노력하십시오. 변경 화면이 2 개 이상인 경우 수행중인 작업을 설명하기 위해 스탠드 업 또는 번개 대화가 필요합니다. 10 페이지 인 경우 슬라이드 및 아키텍처 다이어그램이있는 프리젠 테이션이 필요합니다.

문제가있는 모든 사람이 동일한 프로젝트에서 작업합니까?

프로젝트가 이미 기술 부채 산에 묻혀 있습니까?

그들은 프로젝트와 지속적인 개선을 믿습니까?