모든 코드를 검토해야합니까?

현재 개발 프로세스를 수정 중이며 커밋 피어의 100 %를 검토 해야하는지 궁금합니다.

코드 검토에 대한 경험은 무엇입니까?

• 당신은 그들에게 "많은"시간을 보내는 경향이 있습니까 (예 : 하루에 1/2 시간), 아니면 최대 5/10 분 동안 탈지합니까?
• 하루 / 주 / 스프린트 / 프로젝트 당 고정 된 시간이 있습니까?
• 가장 중요한 것은 코드의 100 %가 피어 리뷰 대상이되어야하는지 또는 100 %가 필요하지 않다고 생각 하는가?

각 스토리마다 '코드 검토'작업이 있습니다. 해당 스토리의 개발에 이상적으로 관여하지 않는 사람은 해당 스토리와 관련된 모든 코드 변경 사항을 검토합니다. 잘 작동한다.

많은 시간? 그리 많지는 않지만 코드의 양에 달려 있습니다. 명백한 오류, 오타, 기본 논리 온 전성 검사, 포착되지 않은 예외 등을 찾고 있습니다.

버그를 발견하는 품질 단계이므로 일부 가치가 있습니다. 시간을 할당하는 것이 최선의 방법이 아닐 수도 있습니다. 무언가가 상당히 복잡한 경우 코드를 검토해야합니까?

그건 그렇고, 다른 사람이 코드 검토를 수행하는 것이 중요합니다.

리뷰에서 코드의 양이 얼마나 많은지에 대한 더 중요한 문제는 리뷰가 얼마나 효과적인지입니다. 리뷰에서 문제가 거의 또는 전혀 발견되지 않으면 전체 범위에 도달하는 것은 쓸모가 없습니다.

먼저 리뷰의 효과를 높이고 적용 범위를 결정하십시오.

코드뿐만 아니라 디자인에서도 검토를 수행해야합니다.

또한 리뷰는 테스트 및 도구를 대체하지 않습니다.

• 리뷰는 실행 코드를 건조시킬 수 있습니다
• 리뷰는 코드 분석을 포함 할 수 있습니다
• 리뷰는 재사용 및 가독성 검토
• 리뷰는 효율성의 일부 측면을 조사 할 수 있지만 실제 실행 시간 측정 및 병목 현상 발견을 대체하지는 않습니다.
• 정적 코드 분석을위한 도구가 있습니다
• 코딩 규칙을 테스트하기위한 도구가 있습니다. 검토 시간을 낭비하지 마십시오.
• 습식 실행 코드의 단위, 시스템 및 통합 테스트
• 단위, 시스템 및 통합 테스트 테스트를 자동으로 반복 할 수 있으며 일반적으로 코드 검토는 일회성입니다.
• 단위 테스트는 높은 코드 적용 범위를 가져야하며 주요 성공 시나리오와 최종 조건을 모두 테스트해야합니다. 코드 검토는 부분적으로 만 수행 할 수 있습니다.
• 통합 테스트는 단위 또는 시스템이 함께 작동하는 능력을 테스트합니다. 코드 검토는이를 대체 할 수 없습니다
• 전체 시스템의 시스템 테스트 기능 테스트, 코드 검토는 이것을 대체 할 수 없습니다

매월 (또는 스프린트 당) 사전 설정 시간을 검토하여 검토하십시오. 다음과 같은 휴리스틱을 사용하여 다음 전용 슬롯에서 검토 할 코드를 선택하십시오.

• 보고 된 알 수없는 버그가 포함 된 코드
• 최근 코드에서 버그가 발견되었습니다.
• 성능 문제가있는 코드 (병 목)
• 새로운 개발자가 작성한 코드
• 이전에 익숙하지 않은 사람이 최근에 업데이트 한 레거시 코드
• 새로운 분야의 코드
• 새로운 개발자가 배우고 자하는 기존 코드
• 복잡한 문제를 해결하는 코드
• 분석 도구에 의해 복잡한 것으로 식별 된 코드

또한 작성자가 아닌 코드 (또는 디자인 또는 테스트)를 검토하고 있습니다.

다음과 같은 독서 자료를 추천합니다.

선택적 숙제 없음 리뷰
동료 코드 검토의 최고의 비밀

때에 따라 다르지.

소프트웨어가 수행하는 작업에 따라 다릅니다.

• 전자식 심박 조율기 또는 우주 왕복선을 제어한다면 확실히 그렇습니다.

• 만약 그것이 프로토 타입이라면, 아마도 아닐 것입니다.

또한 리소스의 수준, 개발자의 경험 및 코드 검토에서 원하는 내용에 따라 다릅니다. (다른 사람의 코드를 검토하는 일반 개발자는 아마도 스타일 문제를 발견하고 미묘한 알고리즘 버그를 놓칠 것입니다 ... 특히 코드 검토가 번거로운 일이라는 점을 명심하십시오.)

내 조언은 정확성이 중요하고 발견되지 않은 오류 비용이 높은 코드에 대한 코드 검토 노력을 절약하는 것입니다.

먼저 다음 질문에 답해야합니다. 왜 코드를 검토합니까?

이 답변을 통해 어떤 코드를 검토해야하는지 파악할 수 있습니다.

일부 코드 검토는 테스트가 수행하거나 수행 한 작업을 정확하게 수행합니다. 그것이 리뷰의 목표라면, 테스트가 거의 없다면 100 %에 가까워지는 것이 좋습니다. 그러나 테스트 도구를 사용하면 모든 코드를 검토 할 필요가 줄어 듭니다.

대부분의 좋은 리뷰는 지식을 공유하고 리뷰에서 개발자 (코드를 작성한 사람 또는 코드를 검토 한 사람)의 기능을 향상시키는 데 중점을 둔 것으로 보입니다. 이를 검토의 주된 이유로, 코드의 100 %를 검토하는 것은 과도 할 수 있습니다.

완벽한 세상에서, 요구 사항 사양에서 사용자 설명서, 테스트 케이스에 이르기까지 적어도 한 사람이 저자가 검토하고 모든 사람을 동료가 검토합니다. 그러나 간단한 책상 점검이라도 검토하는 데 시간과 비용이 소요됩니다. 즉, 검토 대상 및 검토시기를 선택해야합니다.

검토 할 항목의 우선 순위를 정하고 검토 방법을 선택하고 적절한 수준의 세부 정보를 사용하여 최대한 검토하려고합니다. 우선 순위 결정은 요구 사항을 검토해야하고, 설계 및 생산 코드를 검토하고, 테스트 사례를 검토해야한다는 등의 인공물 유형을 기반으로 할 수 있습니다. 이 범위 내에서 고위험 또는 고 가치 구성 요소가 검토에서 우선 순위를 받거나보다 공식적인 검토를 받도록 지정할 수도 있습니다.

지금까지는 구성 요소의 우선 순위가 어느 정도인지 다시 설명합니다. 내가 검토하는 데 10-15 분을 보냈던 시간이 있었고 여러 사람이 코드를 개별적으로 읽은 다음 30-45 분 지속되는보다 공식적인 검사 프로세스를 수행하기 위해 방에 갔다 (크기에 따라 다름) 모듈).

결국 시간, 비용, 범위 및 품질 사이의 균형입니다. 모든 것을 가질 수 없으므로 가능한 곳을 최적화해야합니다.

제안으로, 검토를 전혀 계획하지 않는 경우 검토 범위와 목표에 대한 공유 지침을 작성하여 검토로 인해 팀 구성원간에 불필요한 마찰이 발생하지 않도록하십시오.

일관된 팀은 더 나은 프로젝트를 구축합니다. 사람들은 말도 안되거나 완벽 요청에 대한 관계를 잃을 수도 있습니다. 항상 이런 사람이나 다른 사람에 대해 불평하고 다른 사람들에게 버그를 범하는 사람은 항상 있습니다.

피어 리뷰를 위해 하루에 한 시간을 예약하지만 항상 필요한 것은 아닙니다. 우리의 코드베이스는 수십 개의 제품에서 공유됩니다. Google의 정책은 한 제품에 고유 한 코드를 조금만 변경해도 검토없이 체크인 할 수 있다는 것입니다. 보다 복잡한 단일 제품 변경에는 검토가 필요하지만 동료에게 책상에 전화를 걸어 한 번 비명을주는 것처럼 비공식적 일 수 있습니다. 공유 코드를 변경하려면 다른 제품의 개발자를 포함하여보다 공식적인 검토가 필요합니다. 우리의 정책은 내가 일했던 다른 회사들과 비교하여 상당히 좋은 균형을 이루고 있다고 생각합니다.

중심 역할이 적은 일부 동료보다 일일 검토에 더 많은 시간을 소비하지만 검토 정책 이전에 개발자가 버그를 추적하는 것보다 더 많은 시간을 쉽게 낭비 할 수 있기 때문에 부당한 시간으로 생각하지 않습니다. 소개 된 다른 제품에.

우리는 코드에 대해 100 % 리뷰를했습니다. 테스트, 특히 100 % 코드 범위 테스트보다 훨씬 저렴합니다. 우리는 그들에게 너무 많은 시간을 소비하지 않고 하루에 한 시간 이상을 검토하면 생산성이 떨어집니다. (30 분은 많지 않습니다 ).

프로세스를 제로화 할 때 메모를하십시오. 무엇을 찾았습니까? 품질 관리팀은 나중에 무엇을 찾았나요? 고객이 찾은 것은 무엇입니까? 그 버그가 왜 당신을 탈출 했습니까?

팀 구성 및 구현 아이디어 공유를 위해 정기적으로 코드를 검토합니다. 이런 식으로 동료들로부터 많은 것을 배울 수 있습니다.

체크인 할 때마다 피어 코드 검토가 필요합니다. 동료가없는 경우 체크인 후 검토를 준비합니다. 검토자는 소스 제어 체크인 주석에 표시됩니다.

이것들은 많은 시간이 걸리지 않으며, 동료들 사이에서 이루어지기 때문에 독성이있는 성인-어린이 측면이 없습니다.

코드 검토는 IMO가 필요합니다. 99.999 ... %의 시간이 항상 옳지는 않을 수도 있으므로 정확한지 확인해야합니다. 정해진 시간이 있습니까? 아니요. 그러나 코드를 확인하는 데 시간이 걸립니다. 보통 나는 동료에게 같은 일을합니다.

코드 검토는 어려워 보일 수 있지만 올바르게 수행하면 유용한 도구입니다. 설계 및 구현 실수에 대한 첫 번째 방어선이됩니다. 배치 한 모든 기능에 대해 코드 검토를 수행하지 않으면 최대한 빨리 시작해야합니다.

동료 검토에 소요되는 시간은 코드 검토를 수행하고 응답하기 위해 총 예상 개발 시간의 5-10 %를 남겨 두는 것이 좋습니다.

올바른 코드 검토를 수행하는 데 도움이되는 백서가 있습니다. 단계별 가이드이며 직면 할 수있는 일반적인 함정과 그 해결 방법에 대해 설명합니다. 당사 웹 사이트에서 다운로드 할 수 있습니다 .