팀에서 주요 코드 검토가 완료된 것으로 보입니다. 주석없이 너무 많은 코드 검토가 병합되었습니다.

하나의 주석없이 코드 검토와 같은 것이없는 것처럼 보입니다.

팀 리더로서 팀이 적절한 코드 검토 프로세스를 수행하고 있는지 확인하고 프로세스의 이점을 극대화하도록 어떻게 도울 수 있습니까?

최신 정보

사람들은 모든 업데이트에 대해 알고 싶어 할 것입니다. 나는 여기에 주어진 많은 제안을 시도했다. 대부분은 이미 사용 중입니다. 일부는 조금 도움이되었습니다. 그러나 문제는 남아있었습니다. 일부 사람들은 내가 찾지 않을 때 지속적으로 잘못된 코드를 받았습니다.

코드 검토 모니터링은 팀이 코드를 더 잘 시작할 수 있도록 도구를 제공하는 것만 큼 도움이되지 않는다는 것을 알게되었습니다.

그래서 복사 붙여 넣기를 감지하기 위해 "jscpd"라는 라이브러리를 추가했습니다. 복사 붙여 넣기에서 빌드가 실패했습니다. 그것은 즉시 하나의 문제를 제거했습니다.

다음으로 우리는 codeclimate를 시도 할 것입니다.

또한 반나절 동안 스프린트 한 번 이전 코드 검토에 대한 수동 검토를 수행하고 있습니다. todo사람들이 글을 쓰고 있음을 알았을 때 s를 이슈 / 티켓으로 변환 하고 있지만 나중에는 처리되지 않습니다. 또한 코드가 적절한 경우 전체 팀과 회의를 통해 코드를 검토합니다.

일반적으로 우리가 올바른 방향으로 움직이는 것처럼 느낍니다.

동료 응답자와는 다른 의견을 제시 할 것입니다. 그들은 옳습니다-당신이 일이 어떻게되는지보고 싶다면 참여하십시오. 더 많은 Tracability를 원한다면이를위한 도구가 있습니다.

그러나 내 경험상, 다른 일이 있다고 생각합니다.

팀이 대부분의 커밋에서 프로세스가 중단되거나 어리 석거나 비효율적이라고 생각할 수 있다고 생각 했습니까? 프로세스는 준수해야 할 규칙이 아니라 잘 작동하는 것을 문서화하고 있음을 기억하십시오 . 그리고 팀장이 이끌 때 규칙을 지키지 않고 최선을 다할 수 있도록 도와줍니다.

따라서 회고 (민첩한 경우) 또는 하나의 회의 (관리자 인 경우) 또는 무작위 즉석 복도 회의 (당신이 민첩하지 않은 팀장이고 다른 관리자가 하나를 수행하는 경우)에서 . 사람들이 코드 검토 프로세스에 대해 어떻게 생각하는지 물어보십시오. 어떻게 작동합니까? 어때요? 팀에 최대한 도움이되지 않는다고 생각한다고 가정 해보십시오. 당신이 확인 듣고 .

이 회의에서 코드 검토를 옹호 할 수는 있지만 피드백을 듣는 것이 좋습니다. 대부분의 경우, 팀이 "적절한"프로세스를 조정해야한다고 생각하거나 근본 원인 (시간 압박, 검토 자 부족, Bob이 코드를 커밋하여 왜 그렇게 할 수 없는지)이 있다고 생각합니다. .

깨진 프로세스 위에 도구를 강제로 추가해도 프로세스가 더 나아지지는 않습니다.

한 줄 답변을 게시하는 것을 싫어하지만이 답변이 적절 해 보입니다.

프로세스에 참여하십시오.

ReviewBoard 또는 Redmine의 코드 검토 플러그인 과 같은 도구를 사용하십시오 . 그런 다음 각 리뷰는 버그 티켓처럼 누군가가 닫거나 댓글을 달아야하는 작업으로 생성됩니다. 그런 다음 검토 티켓을 만든 사람과 누가 닫았는지 추적 할 수 있습니다. 검토 티켓을 소스 코드 체크인과 묶을 수 있습니다 (예 : 개정판에서 티켓 생성).

몇 가지 사항 (솔직히 말하면, 대부분은 답변을 다루지 만 한 곳에두기를 원했습니다)

• 코드 검토가 이루어 지도록 프로세스와 규칙을 적용 할 수는 있지만 실제로 코드 검토가 상자 치기 연습 이상이되도록하는 것은 불가능합니다. 궁극적으로 팀은 프로세스에 유용하게 접근하려면 프로세스의 이점을보아야합니다.

• 예를 들면. 리뷰에 참여하십시오. 개발자로서, 관리자가 아닌 개발자가 내가 찾지 못하는 것을 발견하면 기분이 나빠집니다. 검토 중에 발견 된 문제를 비난의 방식으로 강조하십시오. 생산 문제가 발생하는 경우 QA 중에 문제가 발생하면 (별도의 QA 프로세스가있는 경우) 코드 검토에서 문제가 발생한 위치를 강조 표시하십시오. 수있는 방법을 팀과 함께 토론 우리가 있습니다 잡은 그 같은 미래의 문제를 보장 할 수 있습니다

• 팀이 프로세스 수행을 원하는 것에 대해 토론하십시오. 그들이 처음부터 일어날 수있는 어떤 점을 보지 못하면 생산 문제와 필요한 수정 사항을 이점의 증거로 사용하십시오

• Sonarqube와 같은 자동 코드 검사 소프트웨어를 사용하면 코드 검토가 이해할 수없는 코드, 논리 오류, 문서 부족 등과 같은 문제에 자동으로 대응할 수 없도록 집중할 수 있습니다.

개발자가 논의하고 동의 한 코드 검토에서 팀이 원하는 것을 문서화 할 수 있습니다. 코드 검토의 일부로 고려할 수있는 사항은 다음과 같습니다.

• 코드가해야 할 일, 즉 요구 사항을 충족하는지 확인하십시오.

• 개발자가 일관된 스타일로 코딩하도록하는 코드 스타일

• 함수 호출 횟수와 같은 최적화

• 아키텍처 및 재사용 성

• 예외 처리 및 로깅

• 기술 부채 : 개발자가 작업을 시작했을 때보 다 더 나은 상태의 코드

• 코드를 확인하고 빌드하십시오 (이 기능은 유용하지만 팀의 다른 개발자는 이것을 테스터에게 맡기는 것을 선호합니다)

• 자동 도구 사용 (나는 SonarQube를 사용 했습니다 ). 코드를 향상시키기 위해 이것을 빌드 프로세스에 통합하는 것이 유용하다는 것을 알았습니다. 예 : 테스트 범위 증가

위의 단계 중 일부는 자동화 된 도구로 다룰 수 있지만 코드 검토 방식을 개선하거나 수행하는 동안 도구 및 안구 검토를 모두 사용하는 것이 좋습니다. 그러나 기술 부채 (아키텍처 및 재사용 성)를 방지하기위한 가장 중요한 단계를 완전히 자동화 할 수는 없습니다.

팀이이를 적용하는 데 일관성이없는 경우 코드 검토를 올바르게 수행하는 개발자 만 병합 권한을 갖도록 허용 할 수 있습니다. 예를 들어 팀의 수석 개발자로 시작하고 싶을 수 있습니다. 이러한 접근 방식의 단점은 이러한 개발자가 개발 프로세스에서 병목 현상을 일으킬 수 있으므로 사용자와 팀이 원하는지 결정해야한다는 것입니다. 개인적으로 나는이 절충안을 받아들이고 코드 검토를 통해 팀 전체의 규율을 늘리고 준비가되면 병합 권한을 가진 개발자 수를 늘릴 수 있습니다.

마지막으로 리뷰를 검토 할 가치가 있습니다. 따라서 일주일에 한 번 개발자와 함께 검토 및 개선 방법을 건설적으로 논의하십시오.

우리 팀이 어떻게 코드 검토를 워크 플로에 신속하게 통합했는지 설명하겠습니다.

먼저 질문을하겠습니다. 버전 관리 시스템 (예 : Mercurial, Git)을 사용하고 있습니까?

대답이 예이면 계속하십시오.

1. 모든 사람 이 (작은 수정 사항이라도) 마스터 브랜치 (트렁크)로 직접 푸시하는 것을 금지합니다 *
2. 별도의 지점에서 새로운 기능 (또는 수정) 개발
3. 개발자가 지점을 마스터에 통합 할 준비가되었다고 생각하면 "풀 요청"을 생성합니다.
4. 모든 사람 이 자신의 풀 요청을 병합 하지 못하도록 금지 *
5. 다른 개발자가 풀 요청을 평가하고 새 코드를 검토하도록합니다.
6. 코드가 검토를 통과하면 풀 요청을 병합하거나 그렇지 않으면 수정 사항을 적용 할 수 있습니다.
7. 코드가 충분히 성숙 될 때까지 6 단계를 반복하십시오 (다시 시작하지 않아도 됨) **
8. 완료되면 모든 새 코드가 이름을 가진 사람 에 의해 (적어도 요약해서) 검토 됩니다.

이제 코드 검토가 수행되는 정확한 워크 플로우 지점이 있습니다.

거기에서 행동하십시오.

* 서버 측 후크를 사용하여 자동으로 시행 할 수 있습니다.

**이 절차가 완전히 (다른 사람의 사이에서) GitHub의 지원, 그리고 사용하기 쉬운 공정이다, 그것을 확인

템플릿을 만들고 팀 구성원에게 코드 검토를 수행 할 때마다 업데이트하도록 요청해야한다고 생각합니다. 그럼에도 불구하고 처음에는 검토 프로세스에 참여해야합니다.