콘솔 UI 툴킷을 최신 문서대로 고치고 실제 화면으로 확인하기

## 옛 버전의 방식이 아니라 현재 저장소 문서 따르기 - 프로젝트가 대규모 재작성을 선언했다면 이름이 익숙해 보여도 이전에 익힌 패턴이 호환되지 않을 수 있다고 가정한다. - 코드를 설계하거나 편집하거나 검토하기 전에 저장소의 최신 마이그레이션 입문서를 읽는다. - 버전 관리되는 소스 문서에 있는 현재의 최소 애플리케이션 패턴, 용어, 수명 주기, 호환성 참고 사항을 사용한다. - 기억이나 이전 버전의 예시보다 프로젝트 헌장, 기여 가이드, 기계 판독 가능 컨텍스트, 중첩된 규칙을 우선한다. - 현재 문서와 기존 지식이 충돌하면 두 설계를 섞지 말고 현재 저장소를 따르며 차이를 기록한다. ## 시작 전에 앱 만들기인지 툴킷 자체 수정인지 구분하기 - 먼저 요청을 애플리케이션 구축, 도구 모음 기여, 버그 수정, 시각적 기록 및 검증 중 하나로 분류한다. - 도구 모음을 사용하는 애플리케이션에는 전용 애플리케이션 가이드와 패턴 모음집을 사용한다. - 라이브러리 기능과 결함에는 기여자 작업 흐름을 사용한다. - 눈에 보이는 UI 변경과 상호 작용 증거에는 기록 작업 흐름을 사용한다. - 해당 영역을 변경하기 전에 수명 주기, 뷰 계층, 레이아웃, 취소 가능한 이벤트, 도메인 용어에 관한 핵심 개념 문서를 읽는다. - 기여자 전용 내부 구현을 애플리케이션 예시에 적용하거나 애플리케이션용 지름길을 핵심 라이브러리 작업에 적용해서는 안 된다. ## 편집 전과 코드 작성 후에 체크리스트 거치기 - 파일을 편집할 때마다 먼저 저장소의 새로고침 점검표를 따라 흔한 실수와 로컬 제약을 확인한다. - 코드를 작성하거나 수정한 뒤에는 생성 후 검증 점검표 전체를 적용한다. - 형식, 타입 선언, 생성 구문, 이벤트 패턴, Unicode 텍스트, 코드 배치, 문서, 테스트, 진단, 취약 영역을 포함하여 영향을 받는 모든 주제의 세부 규칙을 읽는다. - 계획 모드에서는 구현 단계, 영향받는 파일, 재사용 기회, 검증 방법을 담은 Markdown 계획을 지정된 계획 디렉터리에 만든다. - 계획을 실제 범위와 일치시키고, 증거로 인해 구현 경로가 달라지면 계획을 갱신한다. ## 새 테스트는 기본적으로 병렬 실행 스위트에 넣기 - 의존성을 복원하고 한 번 빌드한 뒤, 빌드가 여전히 최신이면 다시 빌드하지 않고 범위를 좁힌 테스트를 실행한다. - 새 테스트는 기본적으로 병렬 실행 가능한 모음에 넣는다. - 프로세스 전체의 정적 상태를 피할 수 없을 때만 비병렬 모음을 사용하고 그 의존성을 설명한다. - 재작성 또는 제거가 예정된 레거시 모음에는 새 커버리지를 절대 추가하지 않는다. - 반복 작업 중에는 단일 메서드 또는 클래스를 선택하고, 범위를 좁힌 결과가 통과하면 관련 프로젝트로 확장한다. - 통합, 스트레스, 벤치마크, 병렬 또는 비병렬 커버리지를 선택하기 전에 테스트 목록을 확인한다. ## 실행 중인 터미널을 녹화해 UI 변경 확인하기 - 실행 중인 인터페이스를 관찰하지 않고 시각적 변경을 출시해서는 안 된다. - 의사 터미널에서 애플리케이션을 실행하고, 대표적인 키 입력을 주입하며, 렌더링된 세션을 캡처한다. - 사람용 미리 보기만 믿지 말고 기계 판독 가능 기록을 프레임별로 읽어 실제로 표시된 내용을 검증한다. - 검토자가 외관이나 상호 작용을 평가해야 할 때는 시각적 결과물을 첨부한다. - 결정론적 어설션에는 프로세스 내 입력 주입, 가상 시간, 드라이버 수준 화면 캡처를 사용한다. - 변경의 영향을 받는 수준에서 레이아웃, 포커스, 입력 처리, Unicode 자소군, 취소, 다시 그리기 동작을 검증한다. ## 저장소에 정해진 공백과 타입 규칙 따르기 - 호출과 인덱싱 주변의 필수 공백, 중괄호 배치, 빈 줄 규칙을 유지한다. - 로컬 가이드에서 허용하는 소수의 내장 기본 타입을 제외하고 명시적 타입을 사용한다. - 요구되는 경우 대상 타입 지정 생성과 컬렉션 식 구문을 우선한다. - 파일마다 public 또는 internal 타입을 하나만 둔다. - 코드 배치 규칙에 따라 멤버와 백킹 필드를 정렬한다. - 사용하지 않는 콜백 매개변수에는 저장소의 디스카드 규칙을 사용한다. - 저장소 포매터와 생성 후 점검을 실행하고 스타일 차이를 단순히 외관상의 문제로 치부해서는 안 된다. ## 조기 반환을 쓰고 프로젝트 용어를 일관되게 쓰기 - 가드 절과 조기 종료를 우선하고, 성공 경로를 깊게 중첩하는 대신 조건을 반전한다. - 메서드, 콜백, 반복문에도 같은 조기 종료 규칙을 적용한다. - 프로젝트의 포함 관계 용어를 일관되게 사용하고, 일반적인 관계 용어는 포함 관계가 아닌 참조에만 사용한다. - 주석을 추가하기 전에 이름, 타입, 구조를 통해 코드가 스스로 의도를 설명하도록 작성한다. - 참조, 사용 방법, API 문서에서는 목표를 밝힌 다음 직접적인 명령형으로 작업을 제시한다. - 공개 계약, 취소 가능한 작업 흐름의 동작, Unicode 자소군 처리, 명확하지 않은 불변 조건을 저장소에서 요구하는 문서 형식으로 기록한다. ## 커버리지를 줄이지 않고 회귀 테스트 추가하기 - 에이전트가 생성한 테스트에는 저장소에서 인정하는 에이전트 및 모델 주석을 표시한다. - 변경을 통과시키기 위해 커버리지를 절대 줄이지 않는다. - 동작에 프로세스 전체 상태가 명시적으로 필요한 경우가 아니면 테스트에서 전역 애플리케이션 초기화를 피한다. - 격리된 설정, 결정론적 입력, 가상 시간, 관찰 가능한 어설션을 우선한다. - 각 테스트를 단순히 파일 이름이 가장 비슷한 모음이 아니라 해당 상태 모델과 일치하는 모음에 배치한다. - 사용자에게 보이는 결함이나 동작에 대한 회귀 커버리지를 추가하고, 관련된 경우 레이아웃과 이벤트 순서 사례도 포함한다. ## 저장소의 로깅 기능을 쓰고 깨지기 쉬운 코드나 무관한 코드는 건드리지 않기 - 저장소의 로깅, 테스트 로깅, 추적 기능을 사용하고 라이브러리 또는 테스트 코드에서 콘솔에 직접 쓰지 않는다. - 취약하다고 문서화된 하위 시스템을 부수적인 정리 작업으로 리팩터링해서는 안 된다. - 범위를 좁힌 기능이나 수정 사항을 구현하면서 관련 없는 코드를 변경해서는 안 된다. - 새로운 컴파일러, 분석기, 문서 또는 테스트 경고를 발생시켜서는 안 된다. - 완료를 보고하기 전에 형식, 용어, 테스트 배치, 의도하지 않은 범위 확장이 없는지 차이를 다시 읽는다. - 취약 영역을 반드시 변경해야 한다면 필요한 최소한의 편집으로 격리하고, 더 광범위한 테스트 전에 해당 영역의 전용 동작을 검증한다.