생성 코드가 있는 여러 모듈 저장소를 승인 범위 안에서 고치기

## 편집 전에 루트와 폴더별 지침 읽기 먼저 변경할 수 있는 파일에 적용되는 저장소 지침을 찾으십시오. 생태계의 기본값을 가정하지 말고, 프로젝트 문서와 하위 디렉터리의 지침 파일을 로컬 규칙의 기준으로 취급하십시오. - 루트 지침과 대상 디렉터리에 있는 더 구체적인 지침을 모두 읽으십시오. - 작업과 관련된 저장소 개요, 기여 가이드, 개발 환경 설정, 테스트 지침, 릴리스 문서를 검토하십시오. - 저장소 전체 지침과 모듈별 지침이 다르면 대상에 가장 가까운 지침을 따르십시오. - 기억에 의존한 명령을 사용하지 말고, 유지 관리되는 프로젝트 파일에서 참조된 정책을 확인하십시오. - 담당자 지정 파일과 영향받는 영역의 검토 책임자를 식별하십시오. - 편집 전에 지원되는 워크플로, 필요한 승인, 검증 기대 사항을 기록하십시오. - 권위 있는 정보가 충돌하거나 중대한 결정이 해결되지 않은 경우에만 질문하십시오. ## 변경을 맡는 모듈과 검토 담당자 찾기 동작을 구현할 위치를 선택하기 전에 코드베이스가 어떻게 나뉘는지 이해하십시오. 다중 모듈 저장소에서는 빌드 경계, 종속성 매니페스트, 생성 영역, 예시, 테스트, 릴리스 단위가 디렉터리마다 다를 수 있습니다. - 공개 동작을 담당하는 모듈과 그 모듈이 의존하는 하위 수준 컴포넌트를 찾으십시오. - 직접 작성한 구현과 생성 코드, 템플릿, 사양, 픽스처, 예시를 구분하십시오. - 모듈 매니페스트를 검사하여 직접 및 간접 종속성 경계를 이해하십시오. - 담당 범위 규칙을 사용하여 코드, 서비스, 공유 인프라의 유지 관리자를 식별하십시오. - 변경이 하나의 패키지, 모듈 계열, 공유 호환성 표면 중 어디까지 영향을 미치는지 추적하십시오. - 병렬 구조를 새로 만들지 말고 기존 디렉터리 구성과 이름 지정 패턴을 따르십시오. - 검증된 종속성 때문에 연계 업데이트가 필요한 경우가 아니라면 관련 없는 모듈은 변경 범위에서 제외하십시오. ## 프로젝트가 정한 도구 버전과 작업 명령 사용하기 저장소와 대상 모듈이 선언한 도구 체인을 사용하십시오. 지원 버전, 작업 실행기, 생성기, 환경 준비 방식은 프로젝트의 결정이며, 로컬에 설치된 최신 버전에서 추론할 값이 아닙니다. - 유지 관리되는 정책이나 구성에서 현재 지원되는 언어 및 도구 버전을 확인하십시오. - 추가 설정을 수행하는 경우 직접 언어 명령보다 저장소에서 관리하는 작업을 우선하십시오. - 문서화된 워크플로가 지정한 모듈 또는 작업 공간 디렉터리에서 명령을 실행하십시오. - 정식 작업이 수행하는 환경 선택, 호환성 옵션, 생성 자산 및 기타 설정을 보존하십시오. - 문서화된 워크플로가 명시적으로 요구하는 경우에만 전역 필수 구성 요소를 설치하십시오. - 생성기와 컴파일러 버전을 프로젝트가 고정했거나 지원하는 버전에 맞추십시오. - 워크플로를 암묵적으로 바꾸지 말고 누락된 필수 구성 요소를 구체적인 차단 요인으로 보고하십시오. ## 릴리스, CI 변경, 인증 정보 사용 전에 허락받기 에이전트는 코드를 읽고, 동작을 설명하고, 변경을 제안하고, 승인된 편집을 구현하고, 테스트를 추가하고, 문서를 개선하며, 이슈 또는 검토 분석을 지원할 수 있습니다. 영향이 더 큰 작업에는 명시적인 사람의 권한이 필요합니다. - 승인 없이 릴리스를 실행하거나, 릴리스 단계를 승인하거나, 패키지를 게시하지 마십시오. - 다른 변경에 부수적으로 지속적 통합, 배포 파이프라인 또는 워크플로 제어를 수정하지 마십시오. - 명시적 승인 없이 라이선스, 법적 고지 또는 규정 준수 정책을 변경하지 마십시오. - 부여된 작업 범위를 넘어 인증 정보를 사용하거나 외부 서비스에 접속하거나 원격 상태를 변경하지 마십시오. - 상태 변경이 승인되지 않았다면 이슈 분류, 레이블 제안, 중복 탐지를 권고 사항으로만 취급하십시오. - 파괴적 작업이나 보호된 환경의 변경 전에 멈추고 필요한 결정을 요청하십시오. - 불필요한 확인을 요구하지 말고 범위 안의 일반적인 구현과 검증을 계속하십시오. ## 생성된 파일 대신 사양을 고치고 다시 생성하기 생성 패키지는 직접 작성한 코드와 다른 변경 경로를 요구합니다. 생성 결과를 수동으로 편집하면 대개 덮어쓰여지고 구현이 권위 있는 사양과 분리될 수 있습니다. - 저장소 표시, 매니페스트, 위치를 알려 주는 파일 또는 문서화된 디렉터리 규칙을 통해 생성 파일을 식별하십시오. - 프로젝트가 사양 기반 재생성을 요구한다면 생성 결과를 수동으로 수정하지 마십시오. - 문서상 권위 있는 정보가 사양, 템플릿 또는 생성기 입력이라면 그것을 변경하십시오. - 프로젝트가 정한 생성 명령과 필수 도구 버전을 사용하십시오. - 생성된 차이에서 예상하지 못한 파일, 불필요하게 광범위한 포맷 변경, 관련 없는 API 변경을 검토하십시오. - 저장소 패턴에 따라 수동 확장 지점을 생성 영역과 분리하십시오. - 재생성을 이용할 수 없거나 승인받지 못했다면 임시 편집을 지속 가능한 수정인 것처럼 숨기지 말고 제한 사항을 설명하십시오. ## 하위 호환성을 지키는 작은 변경 만들기 기존 코드 규칙을 따르고 호환성을 보존하는 집중된 변경을 우선하십시오. 두 방법 모두 요구 사항을 충족한다면, 범위가 좁고 검토 가능한 패치가 광범위한 리팩터링보다 안전합니다. - 도우미, 이름, 오류 패턴, 파일 위치를 선택하기 전에 인접한 구현을 읽으십시오. - 호환성을 깨는 변경이 명시적으로 승인되고 문서화된 경우가 아니라면 하위 호환성을 보존하십시오. - 내보낸 이름, 두문자어, 주석, 공개 API 문서에 관한 로컬 규칙을 따르십시오. - 비밀 정보를 노출하지 않으면서 유용한 맥락을 보존하는 설명적인 오류를 사용하십시오. - 필요한 저작권 및 라이선스 헤더를 그대로 유지하십시오. - 모듈 종속성 정책을 따르고 이미 로컬에서 제공되는 동작을 위해 외부 종속성을 추가하지 마십시오. - 검토자가 의도를 명확히 평가할 수 있도록 관련 없는 정리 작업을 요청된 변경과 분리하십시오. ## 대상 모듈을 먼저 빌드·테스트하고 필요할 때만 넓히기 먼저 영향받는 모듈을 실행하는 가장 작은 명령을 사용한 다음, 공유 동작이나 저장소 정책이 요구할 때만 검증 범위를 넓히십시오. 성공한 명령도 변경된 경로를 다룰 때만 의미가 있습니다. - 문서화된 작업 또는 언어 명령을 사용하여 대상 모듈을 빌드하십시오. - 더 넓은 패키지 또는 작업 공간 테스트 모음보다 직접 관련된 단위 테스트를 먼저 실행하십시오. - 모듈에서 요구하는 경우 타입 검사, 정적 분석, 포매팅, 생성 파일 검증을 추가하십시오. - 테스트 선택에 의도한 패키지와 사례가 실제로 포함되었는지 확인하십시오. - 통합 테스트나 실제 환경 테스트를 시도하기 전에 필요한 환경 변수를 검사하십시오. - 대상을 건너뛰었거나 이용할 수 없는 외부 상태에 의존한 명령을 근거로 검증했다고 주장하지 마십시오. - 실행한 명령, 관찰한 결과, 완료할 수 없었던 검사를 기록하십시오. ## 네트워크나 실행 순서에 의존하지 않는 테스트와 실행되는 예시 작성하기 테스트는 동작 변경을 입증하고 여러 장비에서 안정적으로 재현되어야 합니다. 예시는 저장소의 실행 가능한 예시 규칙을 따르면서 지원되는 사용법을 보여 주어야 합니다. - 모듈에 이미 정착된 어서션 라이브러리와 테스트 구조를 재사용하십시오. - 결함을 수정할 때는 수정 사항을 적용하기 전에 새 테스트가 의도한 이유로 실패하는지 확인하십시오. - 단위 테스트가 네트워크, 인증 정보, 시간에 민감한 상태, 실행 순서에 의존하지 않게 하십시오. - 픽스처는 지정된 테스트 데이터 위치에 저장하고 최소한으로 유지하십시오. - 실제 환경 테스트 설정은 승인된 환경 파일에 격리하고 비밀 정보를 절대 커밋하지 마십시오. - 진단을 실질적으로 개선하는 경우 어서션 메시지를 추가하십시오. - 예시를 예상된 이름 및 패키지 구조에 배치하고 문서화된 테스트 워크플로에서 컴파일되거나 실행되는지 확인하십시오. ## 동작이 바뀌면 모듈 설명과 변경 기록 업데이트하기 문서는 구현 표면의 일부입니다. 업데이트하지 않으면 사용자, 유지 관리자 또는 릴리스 도구가 변경을 불완전하거나 오해하기 쉬운 상태로 파악하게 되는 경우 문서를 함께 업데이트하십시오. - 설정, 지원 동작 또는 공개 사용법이 변경되면 모듈 개요를 업데이트하십시오. - 프로젝트의 문서 스타일에 따라 API 주석을 추가하거나 수정하십시오. - 사용자에게 보이는 변경을 필수 변경 기록에 남기십시오. - 저장소 정책에서 요구하는 경우 새로운 공개 API의 예시를 제공하십시오. - 설정, 생성, 마이그레이션, 릴리스 지침을 실제 명령과 동기화하십시오. - 참조가 여전히 유효하고 독자를 비공개 또는 오래된 위치로 안내하지 않는지 확인하십시오. - 동작과 워크플로가 바뀌지 않았다면 불필요한 문서 변경을 피하십시오. ## 승인된 브랜치에서 전체 diff를 확인한 뒤 변경 요청 올리기 저장소가 승인한 기여 경로를 사용하고 전체 변경을 쉽게 검토할 수 있게 만드십시오. 기여는 보호된 공유 이력을 바꾸지 않으면서 구현, 테스트, 문서, 근거를 연결해야 합니다. - 승인된 기본 브랜치에서 작업을 만들고 승인된 포크 또는 원격 저장소를 통해 게시하십시오. - 변경 요청을 열기 전에 브랜치의 전체 차이를 검토하십시오. - 설명적인 제목을 사용하고 관련 작업이 있으면 참조하십시오. - 향후 회귀를 막는 테스트와 정책에서 요구하는 문서를 포함하십시오. - 유지 관리자가 다른 이력 전략을 요청하지 않는 한 추적 가능한 후속 변경으로 검토 의견을 반영하십시오. - 필요한 모든 자동 검사를 확인하고 실패를 우회하지 말고 원인을 조사하십시오. - 명시적 승인 없이 보호된 브랜치, 릴리스 브랜치, 공유 이력을 변경하지 마십시오. ## 호환성을 깨는 변경과 생성 파일 오류가 없는지 코드 검토하기 코드 검토에서는 정확성, 호환성, 생성 무결성, 테스트 품질, 보안, 유지 관리성을 우선해야 합니다. 일반적인 스타일 체크리스트가 아니라 프로젝트별 지침을 적용하십시오. - 변경이 선택한 모듈에 속하고 해당 아키텍처를 따르는지 확인하십시오. - 미묘한 기본값 변경을 포함하여 API나 동작의 호환성을 깨는 변경을 찾으십시오. - 관련된 경우 테스트가 성공, 실패, 경계, 반복 가능성을 다루는지 확인하십시오. - 생성 파일이 승인된 소스와 생성 워크플로에서 만들어졌는지 확인하십시오. - 종속성과 매니페스트 변경에 정책 위반이나 불필요한 추가 사항이 있는지 검사하십시오. - 문서와 변경 기록이 완전하고 정확한지 확인하십시오. - 조사 결과를 담당자에게 전달하고 차단 결함과 선택적 개선 사항을 구분하십시오. ## 보안 문제는 비공개로 보고하고 테스트 결과와 함께 인계하기 보안 보고, 릴리스, 파이프라인 승인, 라이선스, 인증 정보에는 전용 처리 절차가 필요합니다. 보호된 작업은 권한을 가진 사람에게 맡기고, 일반 작업은 증거에 기반한 인계로 마무리하십시오. - 보안 취약점은 공개 이슈나 토론이 아니라 프로젝트의 비공개 채널로 보고하십시오. - 공개 결과물에 비밀 정보, 비공개 연락처, 민감한 재현 데이터를 절대 포함하지 마십시오. - 릴리스 실행, 배포 승인, 라이선스 결정은 명시적으로 권한을 받은 유지 관리자에게 맡기십시오. - 중요한 구현 선택을 설명하고 해당 프로젝트 지침과 연결하십시오. - 변경된 경로, 수행한 테스트, 관찰한 결과, 남은 제한 사항을 요약하십시오. - 추가 검토가 필요하면 적절한 코드 또는 서비스 담당자를 명시하십시오. - 외부 접근, 이용할 수 없는 도구, 승인 경계 때문에 완전한 검증이 불가능했던 경우 이를 명확히 밝히십시오.