PR의 품질이 향상되지 않는 이유

PR의 품질이 향상되지 않는 이유

 

간단합니다. 나무 때문에 숲이 그리워집니다.

Pixabay를 통해

소프트웨어 엔지니어링 세계에서 Git의 편재는 주변의 도구 및 프로세스가 개발자 워크플로 및 소프트웨어 릴리스 패턴과 관련하여 몇 가지 패턴으로 다소 통합되었음을 의미합니다.

여기에는 다음이 포함됩니다.

이들 각각의 핵심은 풀 리퀘스트 또는 PR이며 많은 팀이 이 계층에서 코드와 제품 모두의 품질을 적용하려고 시도합니다.

뭔지 맞춰봐? 거의 작동하지 않습니다.

이 접근 방식이 훨씬 더 엄격하고 규율 없이는 거의 작동하지 않는 이유는 분명해야 합니다. PR 시점에서 코드는 이미 작성되었습니다. 참여하는 모든 사람은 매몰 비용 오류의 대상이 됩니다.

다시 말해, PR 시점에서 팀장이나 동료가 접근 방식이 차선책이거나 폐기되거나 주요 변경 사항을 요청해야 한다고 지적하지 않을 것입니다. 매몰 비용 오류 때문만이 아니라 PR 검토 자체가 검토자에게도 큰 맥락 전환이 될 수 있습니다.

대신, 대부분의 PR은 결국 다음에 초점을 맞춥니다.

• 명백하고 고립된 논리 오류
• 나쁜 습관과 스타일(하지만 이를 위해 린트 규칙을 사용할 수 있음)
• 안전하지 않은 관행(다시 린트 규칙, 정적 분석 도구 또는 CodeQL과 같은 도구를 대신 사용할 수 있음)
• 검토자가 그러한 논리가 시스템의 다른 곳에 존재할 수 있음을 알고 있는 경우 DRY 위반
• 또는 — 최악의 — 그냥 일상적인 동작입니다.

이러한 연습은 궁극적으로 귀찮은 일처럼 느껴지며 결함률 감소, 반복 속도, 아키텍처 개선 및 개발자 생산성 향상이라는 측면에서 차이를 만드는 코드 유형이나 제품 품질 개선으로 이어지지 않습니다.

종종 그러한 운동은 의식처럼 느껴지고 나무 대신 숲을 그리워합니다.

이 모든 것이 익숙하다면 계속 읽으십시오!

종종 PR이 코드 리뷰라는 잘못된 동등성이 있습니다. 실제로 PR의 맥락에서 코드를 검토하는 동안 PR은 ~ 아니다 코드 리뷰.

우선, 애플리케이션의 더 큰 흐름과 제품, 기능 또는 비즈니스 요구 사항에 대한 심층 검토의 맥락을 벗어나 코드 변경 사항을 검토하는 것은 종종 쓸모가 없습니다. 즉, 코드 작성 방법을 결정하려면 코드가 작성된 비즈니스 또는 제품 컨텍스트를 알아야 합니다.

그러나 매우 기본적인 수준에서도 주변 코드의 더 큰 컨텍스트와 데이터가 이를 통해 흐르는 방식을 이해하지 않고는 1줄 diff를 분리하여 올바른지 아니면 엣지 케이스를 놓치거나 더 많은 테스트 케이스가 필요한지 이해하는 것이 종종 불가능합니다. 암호.

더 작은 PR, PR 템플릿, 더 빈번한 PR, 드래프트 PR 등을 사용하여 검토자가 PR을 더 쉽게 만들려고 노력해도 제품 및 코드 품질에 의미 있는 영향을 미치지 않을 것이라고 가정합니다.

그 이유는 간단합니다. 코드가 조밀하고 많은 기능과 버그 수정이 복잡하므로 논리 및 비즈니스 요구 사항의 흐름에 대한 깊은 이해가 필요하며 다른 하위 시스템에서 작업하는 피어가 불가능할 가능성이 높거나 동일한 하위 이벤트가 발생합니다. -system — 코드가 다음과 같은지 알기 위해 정확한, 완전한그리고 고품질.

그리고 여기에서 우리는 질문의 진정한 핵심에 도달합니다. 코드와 제품 품질을 정확히 결정하는 방법?

이 질문에 답하려면 거의 모든 다른 산업이 품질을 달성하고 거의 보편적으로 사용되는 두 가지 수단을 고려하는 것이 좋습니다.

출력이 지정된 제품 디자인을 충족했습니까?라는 질문만큼 간단합니다. 식품 제조 라인, 기계 조립 라인, 제약 제조, 건설, 웨딩 드레스를 재봉하는 재봉사, 소프트웨어 엔지니어링 등 의미 있는 품질은 사양과 테스트를 통해서만 달성할 수 있음이 분명합니다.

이들은 같은 동전의 양면입니다. 사양이 없으면 테스트는 의미가 없습니다. 테스트 없이 사양을 확인할 수 없습니다. 사양은 테스트 전략을 결정하고 테스트는 사양이 올바르게 구현되었는지 확인합니다.

마찬가지로, 사양이 없는 코드 검토는 설계 및 개발된 비즈니스 컨텍스트 없이 구현의 정확성이나 적합성을 결정하는 것이 거의 불가능하기 때문에 공허한 연습입니다(만약 설계되었다면!). 사양이 없으면 코드 리뷰는 잘못된 것에 초점을 맞춥니다.

그래서 방법 ~할 수 있다 코드와 제품 품질을 의미 있게 개선합니까? 그냥 넘어가는 PR보다 더 의미 있는 코드 리뷰를 얻으려면 어떻게 해야 할까요?

사양 프로세스 수정

애자일 시대에 아무도 이것을 듣고 싶어하지 않지만 많은 코드 및 제품 품질 문제의 근원은 깨진(또는 존재하지 않는) 제품 사양 프로세스에서 비롯됩니다. 종종 이것은 기능이나 제품을 완전히 탐색하고 문서화하는 엄밀함이 부족한 게으르거나 경험이 부족한 제품 팀의 결과입니다.

이것은 종종 "우리는 민첩하므로 프로토타입을 만들고 검토하고 반복하겠습니다"로 나타납니다. 매몰비용의 오류가 다시 한 번 발생하여 프로토타입이 출하된 제품이 되는 경우가 많습니다.

사양이 충분하지 않으면 가장 적합한 아키텍처를 결정하거나 테스트 절차를 정의하는 것이 "에지 케이스"가 많기 때문에 불가능한 작업입니다. 시작할 강력한 사양이 없으면 문제의 범위가 구현 팀에 완전히 공개되지 않았기 때문에 당면한 문제를 해결하기 위해 적용할 올바른 디자인 패턴을 결정하는 것이 종종 불가능합니다.

개인적으로 저는 Basecamp의 Shape Up 모델을 지지합니다. 나는 그것을 사용했다. 나는 그것이 효과가 있다는 것을 안다.

이 모델은 엔지니어링 팀이 전체 컨텍스트에서 작업할 수 있도록 조직 내의 제품 기능이 작업 매개변수를 완전히 캡슐화하기 위해 더 많은 책임과 엄격함을 미리 수용할 것을 요구합니다. 반대로 사양을 주의 깊게 검토하고 타당성, 절충안 및 일정을 결정하는 엔지니어링 기능도 필요합니다.

사양이 있으면 컨텍스트 없이 코드를 검토하는 대신 코드 검토의 목표가 구현이 사양을 충족하는지 여부를 결정하는 것이 되기 때문에 코드 검토를 훨씬 더 의미 있게 만들 수 있습니다.

기술 설계 요구 및 검토

일단 작성되고 잘려진 코드를 검토하는 것보다 소프트웨어 엔지니어링 분야는 다른 산업이 출력 품질 문제를 관리하는 방식을 이해함으로써 많은 것을 배울 수 있는 것처럼 보일 것입니다. 즉, 설계를 검토하십시오.

청사진 없이 집이나 고층 빌딩을 짓는다고 상상해 보십시오. 모든 구성 요소의 CAD 모델 없이 Tesla를 구축한다고 상상해 보십시오. 엄청난 힘을 견뎌야 하는 각 부품의 엄격한 설계와 사양 없이 SpaceX 로켓을 만드는 것을 상상해 보십시오. 불가능해 보일 것입니다.

그러나 우리는 소프트웨어를 기술 설계와 아키텍처에 대해 전혀 신경 쓰지 않는 것이 당연하다고 생각합니다.

소프트웨어 엔지니어링 분야의 애자일은 코드에 자주 적용되며, 그러나 드물게 디자인에. 훨씬 저렴하지 않을까요 디자인을 반복하다 나중에 깨진 버그가 있는 코드를 수정하기 위해 시간을 보내기 전에?

물론 설계의 엄격함은 해당 영역에 따라 다릅니다. Fast Company는 좋은 기사를 가졌습니다. 그들은 올바른 것을 씁니다. NASA 내 소프트웨어 엔지니어링:

그러나 소프트웨어가 얼마나 많은 일을 하느냐가 소프트웨어를 주목하게 만드는 것은 아닙니다. 놀라운 점은 소프트웨어가 얼마나 잘 작동하는지입니다. 이 소프트웨어는 충돌하지 않습니다. 다시 부팅할 필요가 없습니다. 이 소프트웨어는 버그가 없습니다. 그것은 인간이 성취한 것만큼 완벽합니다.

코드가 원샷의 일부인 경우, 한 세대 미션에서 이러한 시스템은 거의 완벽을 위해 노력해야 합니다.

대부분의 팀에서 이것은 분명히 너무 엄격하지만 "디자인 없음"을 의미하지는 않습니다.

더 나은 코드 작성

아이러니하게도 코드 품질 향상에 대한 답은 거의 확실합니다.더 나은 코드 작성". 그렇게 하는 가장 좋은 방법은 PR이나 코드 리뷰가 아닙니다. 왜냐하면 그 시점에서 코드는 이미 작성되어 있고(이는 코드 리뷰 및 코드 품질과 관련하여 생각하는 근본적인 논리적 결함입니다) 팀은 "리팩토링을 합시다. 이것은 더 깨끗한 코드와 더 나은 디자인으로"(절대 일어나지 않을 것입니다) 그 시점에서 배송에 대한 압력이 너무 높기 때문입니다. 사실, 그 코드는 결코 재작성되지 않을 것입니다(모든 제품에는 아무도 감히 건드릴 수 없는 코드 더미가 있습니다).

이것은 쉬운 일이 아니며 고용 프로세스와 팀 구성에 더 많은 노력이 필요합니다. 모든 작업을 무료로 분담하는 것이 아니라 핵심 프레임워크 비트와 API를 더 많은 경험을 가진 소수의 사람들이 처리해야 한다는 의미입니다.

공정하게 말하면 팀이 없습니다. 항상 첫 번째 컷에서 바로 얻을 수 있습니다. 그것은 요점이 아니다. 핵심은 유연하고 변화하는 비즈니스 요구 사항에 유연하게 적응할 수 있는 방식으로 시스템을 구축하는 것입니다.

더 많은 팀 중심 개발

버그 수정이나 팀의 기능에 대해 함께 작업하는 개발자는 시스템의 해당 영역에서 비즈니스 요구 사항 및 코드 흐름의 더 큰 맥락을 더 잘 이해할 수 있으므로 서로에게 더 의미 있는 피드백을 제공할 수 있습니다. 코드 조각이 해결하고 있는 특정 비즈니스 문제에 대한 맥락적 이해가 없는 검토자를 끌어들입니다.

개발 작업을 소규모 팀으로 구성하는 것은 자동으로 각 작업 단위에 더 많은 관심을 기울이고 구현되는 기능의 더 큰 맥락을 이해하는 여러 개인이 있도록 하는 방법입니다.

대화형 코드 검토

diff를 개별적으로 보는 것보다 제출자가 제품 또는 기능의 더 큰 맥락에서 코드를 살펴보고 이루어진 절충점에 대해 논의하는 대화식 코드 리뷰를 갖는 것은 리뷰어로부터 훨씬 더 의미 있는 피드백으로 이어질 수 있습니다.

종종 코드가 더 큰 시스템이나 상태 머신의 흐름 내에서 상호 작용하기 때문에 diff 또는 변경 세트를 볼 때 보이지 않는 의사 결정 프로세스의 뉘앙스가 있습니다.

개발자나 팀이 구현하는 동안 고려한 기술적 설계 결정과 과제를 단계별로 진행하게 하면 단순히 PR을 검토하는 것보다 훨씬 더 생산적일 수 있습니다.

코드 검토에서 테스트에 중점

구현의 세부 사항을 살펴보는 것 외에도 테스트 전략을 검토하여 테스트 전략이 충분한 적용 범위를 제공하는지 확인하는 것이 훨씬 더 중요합니다. 요구 사항 커버리지 보다는 암호.

코드 리뷰의 양은 그 특성상 엣지 케이스를 설명하지 않습니다. 사양에 없는 경우입니다. 마찬가지로, 테스트(자동 단위 테스트 또는 자동화된 종단 간 테스트)가 코드 검토에서 충분한지 여부를 평가하려면 테스트 적용 범위를 결정할 수 있는 충분히 상세한 기능 사양이 있어야 합니다.

코드 검토는 개발자가 사양을 설명하는 적절한 테스트 케이스를 설계하고 구현했는지 여부에 초점을 맞춰야 합니다. 그러나 물론 이것은 그러한 테스트 케이스의 적용 범위를 결정하기 위해 그러한 사양이 먼저 존재해야 함을 요구합니다.