모든 개발자가 코드 검토를 수행하도록하기

저는 7-8 개발자 팀의 소프트웨어 개발자입니다. 우리는 꽤 오랫동안 코드 검토를 해왔으며 시간이 지남에 따라 코드 품질이 향상되었습니다.

그러나 최근에 일부 개발자는 다른 개발자보다 더 많은 코드 검토를 요구하는 것으로 나타났습니다. 융통성있는 태도 때문인 것 같습니다.

제 생각에 이것은 코드 검토가 수행되는 방식이 아닙니다. 모든 팀이 이에 대해 책임을 져야하며 코드 검토자가 변경 사항을 쉽게 받아 들일 의지가 없도록 선택해서는 안됩니다.

팀에서이 문제를 어떻게 처리합니까?

코드 검토자를 선택하기위한 규칙을 설정 했습니까?

코드 검토 자들이 코드 검토에 좋은 시간을 보냈다고 생각하십니까? 그리고 그들은 어떻게 보상을 받아야 하는가?

답변 / 아이디어 주셔서 감사합니다.

우리는 검토자를 선택하지 않습니다.

우리 팀에서 :

• 풀 요청이 완료되기 전에 모든 코드 변경 사항을 코드 검토해야합니다.
• 최소한 한 명의 개발자가 코드 검토를 수행해야합니다 (두 명 이상의 검토자가 더 우수하며 코드 검토를 수행하는 테스터, 분석가 및 기타 팀 구성원도 매우 유용합니다)

코드 리뷰는 할당되지 않았으며 사람들은 자신을 위해 일할 때 선택합니다. 이해는 파이프 라인을 통해 스토리를 전달할 수 없다는 것입니다. 때때로 누군가는 스탠드 업에서 CR을 기다리고 있다고 언급하지만 그에 관한 것입니다.

나는이 모델을 좋아한다. 사람들이 할 수있는 것을 주워 "사람에게 일자리를주는 것"을 피한다.

변경 사항을 커밋 한 사람뿐만 아니라 해당 내용을 검토 한 사람에게만 수정을 위해 버그를 할당 할 수있는 규칙을 소개하십시오. 코드 검토에 대한 올바른 관점을 만들어야합니다.

에 관해서는

코드 검토 자들이 코드 검토에 좋은 시간을 보냈다고 생각하십니까?

글쎄, 급여를 받고 자신이 한 일을 자랑스럽게 생각하는 것을 제외하고 개발자가 일반적으로 업무를 수행 한 것에 대해 어떻게 보상을 받는지 잘 모르겠습니다. 그러나 코드 검토가 작업의 일부이므로 검토자는 검토 할 시간을 가져야하고 크레딧을 어떻게 든 공유해야합니다.

당신이 가지고있는 주요 문제는 기술적 인 것이 아니지만 일부 도구는 코드 검토에 드는 노력을 줄일 수 있습니다. 극복해야 할 몇 가지 과제가 있습니다.

• 변화가 무엇인지 이해합니다. 기능 브랜치의 Git Pull Requests는 실제로이 프로세스에 도움이됩니다.
• 사람들이 같은 방에 있어야하는 이벤트를 코드에서 검토하도록합니다. 이것은 스케줄링, 리소스 회의 등의 스트레스를 추가합니다. GitHub, GitLab 및 BitBucket은 비동기 검토를 허용하므로 피어가 준비 될 때 발생할 수 있습니다.
• 코드를 볼 때 의미있는 피드백을 제공하는 기능 솔직히 말해서, GitHub, GitLab, Bitbucket pull 요청의 라인 별 주석 기능은 실제로 대면 회의보다 더 유용합니다. 덜 정치적 느낌입니다.

SubVersion이나 Fisheye와 같은 다른 도구를 사용하여 도움을 줄 수는 없지만 기능 분기가있는 Git 파이프 라인에 통합 된 것은 실제로 작업을 덜 번거롭게 만듭니다.

툴링 외부에서 더 많은 사회적 과제를 살펴 봐야합니다.

• 오픈 풀 요청을 검토하여 개발자가 하루를 시작하도록하십시오.
• 개발자가 새 작업을 시작하기 전에 열린 풀 요청을 검토하도록합니다
• 풀 요청에 대해 둘 이상의 사람의 승인이 필요합니다.

참여도가 높은 사람들이 코드 검토중인 작업 유형을 확인하는 것도 좋습니다. 그들은 모든 쉬운 리뷰를 잡아서 다른 사람들에게 더 고통 스럽습니다.

좋은 방법은 라운드 로빈 방식으로 수행하는 것입니다. 코드에 대해 최소한의 리뷰를 한 사람을 선택하십시오. 시간이 지남에 따라 팀의 모든 사람은 대략 같은 수의 리뷰를 수행해야합니다. 지식도 확산됩니다.

분명히 정점과 여물통이있는 휴일과 같은 예외가있을 것입니다.

후배와 노인 / 리드 사이에는 차이가 없어야합니다. 코드의 검토는 상급자에 관계없이 모든 사람의 코드에 대해 수행되어야합니다. 마찰을 줄이고 다양한 접근 방식을 공유하는 데 도움이됩니다.

이 모든 후에도 리뷰의 품질이 여전히 우려되는 경우 코드 검토를 통과하기위한 최소 표준 세트를 도입하는 것이 좋습니다. 포함하는 것은 전적으로 귀하에게 달려 있지만 고려해야 할 사항은 코드 범위, 단위 테스트, 주석 처리 된 코드 제거, 메트릭, 충분한 주석, 빌드 품질, SOLID 원칙, DRY, KISS 등입니다.

코드 검토 장려에 관해서는 품질 코드 가 보상입니다. 우리는 처음에 다른 개발자가 코드를 처음부터 다시 한 번 부여하고 건설적인 변경을 제안했을 때 고통을 줄일 수있는 차선책의 코드 기반에서 작업했다고 확신합니다.

팀에 코드 검토를위한 공식적인 프로세스가 부족한 것 같습니다.

나는 350 페이지의 Word 문서를 만드는 것에 대해 이야기하는 것이 아니라 프로세스가 수반하는 것에 대한 몇 가지 간단한 요점을 제시합니다.

중요한 비트 :

1. 핵심 검토 자 세트를 정의하십시오. 일반적인 진술은 없습니다. 사람들의 이름을 지정하십시오.

   이들은 수석 개발자 여야합니다.

2. 검토에서 사인 오프하려면 둘 이상의 핵심 검토자가 필요합니다.

3. 임시 핵심 검토자인 각 스프린트 또는 릴리스마다 최소 1 명의 다른 비 핵심 검토자를 식별하십시오. 이 기간 동안 모든 코드 검토에서 사인 오프해야합니다.

항목 # 3을 통해 다른 개발자는 핵심 검토 자 그룹으로 전환 할 수 있습니다. 몇 주 동안 다른 사람들보다 리뷰에 더 많은 시간을 할애합니다. 균형 행위입니다.

보람있는 사람에 관해서는? 전체 팀 앞에서 코드를 검토하는 동안 사람이 한 노력을 인정하면 여러 번 일할 수 있지만이 점에 대해 스트레스를받지 마십시오.

확실하지 않은 경우 프로세스를 정의하고 팀에 고수해야한다고 지시하십시오.

그리고 당신이 시도 할 수있는 마지막 한 가지가 있습니다-논쟁의 여지가있을 것입니다 : 관용구를 사용할 수 있다면 @ # $ %가 팬을 때리십시오.

코드 검토 프로세스를 따르지 않으므로 팀이 실패하게하십시오. 경영진이 참여하고 사람들이 변화 할 것입니다. 이것은 프로세스를 이미 정의하고 팀이 프로세스를 거부 한 가장 극단적 인 경우에만 좋은 아이디어입니다. 사람들을 해고하거나 징계 할 권한이 없다면 (대부분의 주요 개발자 가하지 않는 것처럼 )이 일을 할 수있는 사람을 참여시켜야합니다.

그리고 변화를 가져 오지 못하는 것만 큼 좋은 것은 없습니다. 사람들의 말에도 불구하고 타이타닉 호를 조종 할 수는 있지만 아이스버그에 닿기 전에는 할 수 없습니다.

때때로 당신은 타이타닉이 빙산에 충돌하도록해야합니다.