여러 언어가 섞인 큰 저장소에서 필요한 빌드와 테스트만으로 코드 변경하기

## 조사하고 계획한 뒤 가장 작은 변경을 만들고 테스트하기 모든 변경에 반복 가능한 다음 절차를 사용하세요. 1. 요청 사항, 관련 코드, 종속 항목 인터페이스, 기존 테스트, 알려진 실패 유형을 조사합니다. 2. 상위 수준의 구현 계획을 세우고 그 전제, 경계 사례, 운영 위험을 검토합니다. 3. 유사한 코드를 살펴 저장소의 구성, 명명, 오류 처리, 테스트 패턴을 파악합니다. 4. 사용자가 요청한 경우에만 계획을 제시하고, 그렇지 않으면 구현을 계속합니다. 5. 요청을 충족하는 가장 작고 일관된 변경을 구현합니다. 6. API 정확성, 명확성, 성능, 가독성, 의도하지 않은 범위 확장 측면에서 결과를 검토합니다. 7. 서식 지정, 대상이 지정된 빌드, 관련 테스트를 실행한 뒤 실패 사항을 반복해서 수정합니다. 초안 작성을 완료로 간주하지 마세요. 구현과 그 구현이 직접 영향을 미치는 동작을 검토하고 검증한 뒤에만 변경이 준비된 것입니다. ## 편집 전에 가장 가까운 비슷한 코드의 방식 따르기 저장소 수준의 기여 지침과 변경할 파일에 적용되는 경로별 지침을 모두 읽으세요. 형제 클래스, 인접 패키지, 유사한 테스트, 관련 워크플로 등 가장 가까운 정상 동작 사례를 찾고, 작업에 의도적인 차이가 필요한 경우가 아니면 기존 구조를 따르세요. 권위 있는 인터페이스나 기존 사용 사례를 통해 종속 항목 API와 경계 사례를 확인하세요. 새 테스트를 만들기 전에 현재 테스트를 찾고, 별도의 병렬 테스트 기반을 새로 만들지 말고 추가 검증 범위를 저장소의 기존 프레임워크에 통합하세요. 조사 범위를 요청된 동작에 집중하세요. 관련 없는 이름 변경, 디렉터리 이동, 대규모 서식 변경, 아키텍처 정리를 변경 작업에 섞지 마세요. ## 테스트 전에 쓸 수 있는 도구와 하드웨어 확인하기 명령을 선택하기 전에 실제로 사용할 수 있는 컴파일러, 런타임, 빌드 도구, 컨테이너, 가속기, 자격 증명을 파악하세요. 사용할 수 없는 기능과 제품 오류를 구분해야 합니다. 필요한 장치가 없거나, 컨테이너 런타임이 지원되지 않거나, 도구 체인이 없다는 사실만으로 코드에 결함이 있다고 입증되지는 않습니다. 재현성에 필요하고 지원되는 경우 저장소의 표준 컨테이너나 개발 환경을 사용하세요. 그렇지 않으면 현재 환경에서 실행할 수 있는 의미 있는 검사를 모두 수행하고, 다른 컴퓨터나 사용자 작업이 필요한 최소한의 남은 명령을 파악하세요. 실행할 수 없는 테스트가 통과했다고 절대 주장하지 마세요. 정확한 제약, 해당 테스트 없이 완료한 검증, 남은 위험을 보고하세요. ## 변경이 영향을 주는 부분만 빌드하고 테스트하기 수동으로 구성한 명령 시퀀스보다 저장소가 제공하는 프리셋과 도우미 스크립트를 우선하세요. 지원되는 프리셋을 확인하고 변경된 구성 요소와 언어 수준에 맞는 것을 선택한 뒤, 관련 빌드 대상, 단위 테스트, 통합 테스트, 컴파일러 검사만 실행하세요. 종속 관계 정보를 사용하여 공유 부분이나 종속성이 높은 부분의 변경으로 영향을 받는 하위 구성 요소를 포함하세요. 국소 변경에서는 관련 없는 패키지를 다시 빌드하지 마세요. 전체 빌드와 전체 테스트 모음은 여러 영역에 걸친 변경, 릴리스 게이트, 저장소 정책이 명시적으로 요구하는 경우에만 사용하세요. 선택한 범위가 충분한 이유를 기록하세요. 범위를 좁힌 검사는 변경과의 관계가 명확한 경우에만 가치가 있습니다. ## 언어와 하드웨어 아키텍처마다 맞는 방식으로 테스트하기 각 언어나 패키지 계층을 자체 인터페이스에 따라 다루세요. 네이티브 라이브러리에는 컴파일러, 언어 표준, 아키텍처 설정이 필요할 수 있고, 스크립트 언어 패키지에는 런타임 버전, 추가 종속 항목, 패키지별 테스트 진입점이 필요할 수 있습니다. 한 생태계의 매개변수를 다른 생태계에 전달하지 마세요. 아키텍처에 민감한 코드에서는 호스트 전용 검사, 컴파일 전용 검사, 시뮬레이터 또는 가상 대상, 물리적 하드웨어가 필요한 테스트를 구분하세요. 기본적으로 모든 변형을 컴파일하지 말고, 변경된 동작과 지원되는 호환 범위를 기준으로 대표 아키텍처를 선택하세요. 공유 구성 요소가 변경되면 종속 관계 그래프를 조사하고 호환성 회귀가 드러날 가능성이 가장 큰 사용 측 구성 요소를 검증하세요. ## 싼 확인부터 먼저 하고 느린 빌드를 섣불리 멈추지 않기 대규모 빌드, 자동 생성된 테스트 매트릭스, 하드웨어 기반 테스트 모음에는 상당한 시간이 걸릴 수 있다고 예상하세요. 현실적인 시간 제한을 설정하고, 지원되는 캐시를 사용하며, 반복 작업 중에는 아키텍처와 대상을 제한하고, 위험이나 릴리스 단계가 비용을 정당화하는 경우에만 검증 범위를 넓히세요. 오래 걸린다는 사실만으로 작업이 멈췄다고 볼 수 없습니다. 느리다는 이유만으로 실행 중인 빌드나 테스트를 취소하지 마세요. 구체적인 실패 증거, 명시적인 운영 한도, 사용자 지시가 있는 경우에만 중단하세요. 비용이 적은 피드백을 먼저 받을 수 있도록 검증을 단계화하세요. 서식 지정과 정적 검사, 대상 컴파일, 호스트에서 실행할 수 있는 테스트, 전문 환경 또는 하드웨어에 의존하는 테스트 모음 순으로 진행합니다. 초기 반복에서 더 작은 하위 집합을 사용하더라도 최종적으로 필요한 검증 범위는 유지하세요. ## 작업 중에는 CI를 줄이되 병합 전에는 전체 CI 실행하기 변경 감지와 작업 매트릭스를 사용하여 영향을 받는 구성 요소와 관련된 작업을 실행하세요. 임시 오버라이드 매트릭스나 건너뛰기 제어는 특히 인프라 변경이나 종속성이 높은 영역에서 초기 반복 비용을 줄일 수 있지만, 항상 확인 가능하고 감사 가능한 상태로 유지해야 합니다. 축소된 CI 검증 범위를 병합 차단 조건으로 취급하세요. 병합 전에 저장소가 요구하는 전체 구성을 복원하고, 임시 오버라이드나 건너뛰기 제어가 없는 상태에서 실행을 성공시키세요. 명시적인 지시 없이 다른 기여자의 오버라이드를 제거하거나 그 범위를 변경하지 마세요. 워크플로가 설정을 제거하는 대신 빈 값을 요구한다면 오버라이드 구성을 구조적으로 유효하게 유지하세요. 필수 작업이 실패하거나 축소된 검증 범위가 계속 활성화되어 있을 때 결과 집계가 안전하게 실패 상태로 종료되는지 확인하세요. ## 포매터와 린터를 실행하고 실행하지 못한 확인도 보고하기 커밋하기 전에 변경된 파일을 대상으로 저장소의 포매터, 린터, pre-commit 검사를 실행하세요. 공통 스타일 지침을 먼저 적용한 다음, 영향을 받는 경로에 따라 선택되는 언어, 디렉터리, 테스트별 규칙을 적용하세요. 최종 diff를 검토하여 의도하지 않은 파일, 생성된 산출물, 일관되지 않은 명명, 오래된 주석, 누락된 테스트가 없는지 확인하세요. 보고하는 증거가 전달한 내용과 일치하도록 마지막 편집 후 대상 검증을 다시 실행하세요. 실행한 정확한 검사, 그 결과, 실행하지 않은 검사, 실행할 수 없었던 이유, 그에 따른 잔여 위험을 보고하세요. 필요한 하드웨어, 도구, 권한, CI 검증 범위가 없었다면 변경이 완전히 검증되었다고 절대 설명하지 마세요.