인간 검토은(는) 무엇을 하나요?
각 변경 사항에 대해 물어보세요: 이 변경은 어떤 요구사항을 충족하는가, 어떤 동작을 변경하는가, 기존 메커니즘으로 대체할 수 있는가?
리뷰 전용 요청은 편집을 허가하지 않습니다. 프로젝트의 규칙과 사용자의 범위(테스트 및 게시 제한 포함)를 따르세요.
동작 추적
이전 및 새로운 실행 경로(호출자 및 우회 분기 포함)를 비교하세요. 객체 전달, 팩토리 전달, 그리고 호출을 구분하세요. 상태를 소유하는 주체, 로드 시점, 그리고 어떤 작업이 교체를 확인하는지 파악하세요.
중복 제거 전에 겉보기 중복을 조사하세요. 어떤 이전 변경이 이 작업을 필요하게 만들었는가? 새로운 구현이 암시적 시작 검사나 정리를 잃었을 수 있습니다. 작업이 두 번 발생한다고 주장하기 전에 분기를 확인하세요.
실패 시점, 재시도, 리소스 정리, 그리고 원래 원인이 사용자에게 도달하는지 확인하세요. 시작 시점에서 연결 설정으로 오류가 이동하면 두 경로 모두 결국 실패하더라도 동작이 변경될 수 있습니다. 내부 예외 유형을 호환성 요구사항으로 간주하기 전에 소비자를 확인하세요.
책임 레이어 단순화
먼저 수신 컴포넌트가 이미 지원하는 것을 검사하세요. 그 계약이 충분하다면, 수신자에 또 다른 책임을 추가하는 대신 호출자가 제공하는 것을 수정하세요. 단지 호출자를 비슷하게 보이게 하기 위해 공유 생성자로 작업을 옮기지 마세요.
추가된 각 작업, 필드, 분기, 또는 추상화를 현재 작업으로 정당화하세요. 제거의 경우 의존하는 호출자와 보장을 확인하세요. 기존 호환 계약을 선호하세요; 의미 있는 변환을 수행하거나 계약을 강제하는 어댑터는 유지하세요.
영향 받는 전체 경로에 걸쳐 상태와 작업을 추적하세요. 캐시 제거가 클로저에서 호출자가 동일한 값을 캡처하는 경우 오래된 상태를 고치지 않습니다. 반대로, 동적 제공자와 파일 기반 폴백은 의도적으로 다른 시점에 로드될 수 있습니다. 이들을 통합하면 회귀가 발생할 수 있습니다.
단순함을 독자가 추적해야 하는 개념, 상태 소유자, 간접 참조로 판단하세요. 더 작은 diff가 항상 더 명확한 설계는 아닙니다. 관련 없는 서식과 미래 작업을 위한 준비를 피하세요.
요구사항 테스트
각 테스트는 이름, 입력, 동작, 그리고 예상 결과를 통해 하나의 일관된 사례를 말해야 합니다. 해당 사례를 설정하는 설정과 단언만 유지하세요. 여러 단계가 보장에 필요한 경우(예: 실패 후 복구) 함께 속하지만, 관련 없는 사례는 그렇지 않습니다.
필요한 동작과 회귀를 구분하는 가장 작은 집합을 유지하세요. 내부 호출 횟수는 요구사항을 표현할 때만 의미가 있습니다(예: 한 번 로드). 주입된 실패가 실제로 발생했는지 확인하세요: 타임아웃이나 닫힌 소켓만으로는 잘못된 이유로 통과할 수 있습니다.
관련 동작별로 테스트를 정렬하여 독자가 다음 테스트에 유용한 컨텍스트를 가져가도록 하세요. 설명적인 주석 대신 구체적인 이름을 사용하세요. 주석을 코드를 먼저 개선하라는 신호로 취급하세요; 이름이나 구조로 명확히 표현할 수 없는 이유는 유지하세요.
사용자 정의 fixture, 대기, 단언, 또는 리소스 헬퍼를 추가하기 전에 기존 프레임워크나 기본 클래스 기능을 찾아보세요. 간단한 코드를 선호하세요. 반복적인 설정을 이해 가능할 때 공유하되, 시나리오별 입력과 동작은 가시적으로 유지하세요. 사례를 숨겨서 줄을 절약하는 콜백, 플래그, 또는 범용 헬퍼를 피하세요.
단언이 필요한 이벤트(지연이나 다른 스레드의 이전 이벤트가 아닌)를 동기화하세요. 실패 시 정리를 유지하세요. 최종 테스트를 diff 없이 순서대로 읽고, 대화 없이도 목적이 명확한지 확인하세요.
설명 및 전달
분명하지 않은 이유를 설명하고 그럴듯한 잘못된 단순화를 방지하는 주석을 유지하세요. 명백한 작업에 대한 설명은 제거하세요. API 계약을 정확하게 유지하고 사용자 지침을 실행 가능하게 유지하세요; diff 없이 편집된 섹션을 읽어 독립적으로 서 있는지 확인하세요.
사용자의 진단과 첫 인상을 모두 가설로 취급하세요. 지원되는 발견 사항을 트리거 시나리오, 결과, 증거, 그리고 가장 작은 유용한 수정과 함께 보고하세요. 결함을 미해결 질문 및 선택적 개선 사항과 분리하세요. 발견 사항이 없는 것은 유효한 결과입니다.
실질적인 재설계의 경우, 하나의 구체적인 실행, 무엇이 더 간단해지는지, 그리고 동작 또는 호환성 비용을 설명하세요. 합의된 범위 밖의 선택 사항은 사용자와 해결하세요; 일상적인 승인된 수정은 추가 승인 없이 계속하세요.
수정 후, 영향을 받는 전체 흐름과 최종 diff를 읽으세요. 각 줄에 대한 질문을 나열하지 말고, 결론, 실행된 검사, 그리고 남은 격차를 보고하세요.