풀 요청이 클 때 더 나은 코드 검토를 수행하는 방법은 무엇입니까?

면책 조항 : 비슷한 질문이 있지만 큰 풀 요청을 검토하는 동안 직면 한 문제를 구체적으로 다루는 것을 찾지 못했습니다.

문제

내 코드 검토가 더 나은 방식으로 수행 될 수 있다고 생각합니다. 특히 20 개 이상의 파일에서 많은 변경 사항이있는 큰 코드 검토에 대해 이야기하고 있습니다.

명백한 지역 코드 문제를 파악하는 것은 매우 간단합니다. 코드가 비즈니스 기준을 충족하는지 이해하는 것은 다른 이야기입니다.

코드 작성자의 사고 과정을 따르는 데 문제가 있습니다. 변경 사항이 많고 여러 파일에 분산되어 있으면 매우 어렵습니다. 특정 변경 사항과 관련된 파일 그룹에 중점을 둡니다. 그런 다음 그룹을 하나씩 검토하십시오. 불행히도 내가 사용하는 도구 (Atlassian Bitbucket)는별로 도움이되지 않습니다. 파일을 방문 할 때마다 현재 검사중인 변경 사항과 관련이없는 것으로 밝혀 지더라도 파일이 표시된 것으로 표시됩니다. 말할 것도없이 일부 파일은 여러 번 방문해야하며 변경 사항은 개별적으로 검토됩니다. 잘못된 경로를 따라갈 때 관련 파일로 돌아 오는 것은 쉽지 않습니다.

가능한 해결책 및 왜 그들이 효과가 없는지

커밋으로 풀 요청을 검토하면 종종 크기 문제가 해결되지만 오래된 변경 사항을 자주 볼 것이기 때문에 마음에 들지 않습니다.

물론, 더 작은 풀 요청을 작성하는 것은 해결책처럼 보이지만, 그것이 큰 일입니다. 때로는 큰 풀 요청을 가져 와서 검토해야합니다.

코드의 논리적 측면을 전체적으로 무시할 수도 있지만 특히 경험이 부족한 프로그래머가 작성한 코드 인 경우에는 매우 위험 해 보입니다.

더 나은 도구를 사용하면 도움이 될 수 있지만 찾지 못했습니다.

질문

• 코드 리뷰와 비슷한 문제가 있습니까? 당신은 그들을 어떻게 대합니까?
• 더 나은 도구가 있습니까?

우리는 이러한 문제를 겪었고 아래 질문을 통해 우리에게 잘 작동했습니다.

홍보는하지 않는 한 가지 병합 할 수 있습니다 독립적으로 테스트 할 수 있습니까?

우리는 단일 책임 (SR)으로 PR을 중단하려고합니다. 처음으로 밀린 사람들은 비록 작은 것이라도 하나 라도 클 수 있다는 사실에 놀랐습니다 .

SR은 실제로 검토하기가 쉽고 예상 구현에 대한 지식을 유포합니다.

또한 더 많은 것이 추가되고 PR 처리 시간이 크게 줄어듦에 따라 증분 리 팩터가 가능합니다!

가능한 경우 SR로 분류하여 그것이 효과가 있는지 확인하십시오. 그렇게하는 연습을합니다.

때로는 큰 풀 요청을 피할 수 없지만 누가 어떤 책임을 지는지 분별할 수 있습니다.

풀 요청을 설득력있는 주장으로 취급합니다. 저자는 코드가 이런 식으로 작동해야한다고 설득하려고합니다.

다른 주장과 마찬가지로 하나의 명확한 아이디어가 있어야합니다. 그 중 하나 :

• 리 팩터,
• 최적화,
• 또는 새로운 기능.

그들이 명확하지 않다면, 스스로 이해하지 못할 가능성이 높습니다. 대화를 열고 그들의 논증을 하위 논증으로 나누도록 도와주십시오. 필요한 경우 완벽하게 괜찮습니다. 커밋을 다시 작성하고 더 이해하기 쉽고 직접적인 풀 요청을 제공하는 것이 유리합니다.

여전히 많은 풀 요청이 있지만 명확한 인수를 사용하면 적합하지 않은 것을 쉽게 볼 수 있습니다.

툴링은 조직 및 프로세스에 따라 다릅니다. BitBucket은 예산, 하드웨어, 요구 사항, 기존 프로세스, 비즈니스 규칙 및 BitBucket을 수용하기 위해 이미 수행 한 다양한 소프트웨어 적응에 이르기까지 모든 것에 달려 있는지 여부에 관계없이 적절한 도구입니다. 동작을 구성 할 수 있는지 확인하기 위해 문서를 살펴보고 플러그인 커뮤니티에 버리거나 플러그인을 만들어서 참여시킬 수 있습니다.

전체 풀 요청을 검토하지 말고 모든 커밋을 검토하십시오. 이 방법으로 풀 요청을 이해하면 더 나은 이해를 얻을 수 있습니다 .¹

커밋이 작 으면 그러한 검토를 수행해도 문제가되지 않습니다. 커밋을 통해 하나씩 변경 사항을 따르고 전체 그림을 얻습니다. 때때로 변경 사항을 검토하여 나중에 커밋을 취소 할 수있는 단점이 있지만 이는 큰 문제가되지 않습니다.

커밋이 큰 경우 해당 커밋을 수행 한 사람과 커밋해야합니다. 큰 커밋이 왜 문제가되는지 설명하십시오. 변경 사항을 거의 커밋하지 않는 이유에 대한 다른 사람의 주장을 들어보십시오. 예를 들어, 커밋 전 후크가 너무 오래 걸리기 때문에 커밋을하지 않는 것이 좋습니다.이 경우이 문제를 먼저 해결해야합니다.

커밋으로 풀 요청을 검토하면 종종 크기 문제가 해결되지만 오래된 변경 사항을 자주 볼 것이기 때문에 마음에 들지 않습니다.

당신은 그러나 이것은 사소한 문제이며, 코드를 검토하는 데 시간을 덜 낭비해야합니다. 이는 단일 파일을 검토 할 때 코드가 변경된 이유를 알아내는 데 낭비하는 시간보다 나중에 약간의 커밋이 취소됩니다.

"자주"는 모호하지만 풀 요청의 최종 개정에 대한 방법을 찾지 못한 코드를 검토하는 데 너무 많은 시간을 소비하는 경우 두 가지 기술을 사용할 수 있습니다.

• 커밋 메시지를 읽고 모든 커밋을 한 번 빠르게 진행하십시오. 이런 식으로, 특정 커밋을 연구 할 때 나중에 어딘가에 커밋 메시지가보고있는 변경 사항이 되돌려 졌다고 말한 것을 기억할 것입니다.

• 파일의 최신 버전을 나란히 볼 수 있습니다 (많은 경우, 많은 커밋의 경우 (1) 파일이 크게 다를 수 있으며 (2) 파일 이름이 바뀌거나 큰 코드 블록이있을 수 있음) 다른 곳으로 이동하면 일치하는 파일을 찾기가 어렵습니다).

• 커미터에게 커밋이 합리적 일 때 커밋을 스쿼시하도록 요청하거나, 한 커밋이 다른 커밋의 일부를 취소하는 특정 커밋 메시지 규칙이 있고, 다음 커밋을 고려하여 검토를 수행하십시오.

^{¹ 예를 들어, 일부 변수의 이름이 변경된 파일을보고 있다고 가정합니다. 그것은 무엇을 말합니까? 이 변경 사항을 어떻게 검토해야합니까? 그러나 커밋으로 커밋을 검토하는 경우 단일 커밋이 20 개의 파일에서 동일한 변수로 이름이 바뀌 었으며 주석은 적절한 비즈니스 용어를 사용하기 위해 이름이 변경되었음을 나타냅니다. 이 변경은 완벽하게 이해되며 검토가 가능합니다.}

풀 요청을 검토하여 달성하려는 작업을 수행하고 대안이 있는지 확인하십시오.

예를 들어

• 표준 준수
• 기능 점검이 올바른지
• 한 사람 이상이 코드를 이해하도록하십시오
• 후배 훈련

등

이들 중 일부는 다른 것들에 의해 더 잘 제공 될 수 있으며, 이유를 이해하는 것만으로도 수표의 범위를 제한 할 수 있습니다.

예를 들어, 모든 줄을 확인하여 교육 변경 사항을 제안하고 토론 할 수 있다면 노인이 수행하는 대규모 PR에서는이를 건너 뛸 수 있습니다

코드를 이해해야하는 경우 큰 기능에 대한 쌍 프로그래밍을 수행하고 코드 검토를 표준 검사로 제한 할 수 있습니다.

품질 관리에 대한 계층화 된 접근 방식이있는 한 모든 PR에 대한 모든 사항을 확인할 필요는 없습니다.