Jev Review
jev_review를 가벼우면서도 반복 가능한 시니어 엔지니어링 리뷰 루프로 사용하세요. 기본 코딩 에이전트는 구현, 검증 및 최종 판단을 담당하며, Jev Review는 제공된 변경 사항을 평가하되 파일을 절대 수정하지 않습니다.
리뷰 주기
복잡한 작업의 경우, 최종 한 번의 대규모 리뷰보다 작업 중 여러 번의 집중 리뷰를 선호하세요:
- 동작, 모듈, API 경계, 마이그레이션 단계 또는 테스트 전략 완료 등 판단할 수 있을 만큼 충분한 구현 조각이 완료된 후 호출하세요.
- 새로운 제어 흐름, 상태 처리, 의존성, 공개 계약 또는 보안 민감 동작이 나타날 때 호출하세요.
- 정당한 피드백을 적용한 후, 이전 결과를
previousEvaluation으로 전달하여 Jev가 개선 및 회귀를 식별할 수 있도록 다시 호출하세요. - 최종 전달 전, 최신 리뷰가 최종 구현을 다루고 있는지 확인하세요.
중간 리뷰는 전체 테스트 스위트를 기다릴 필요가 없습니다. 실용적인 경우 빠른 관련 검사를 실행하고 그 상태를 repositoryContext에 포함시키세요. 최종 리뷰 전에는 저장소의 일반적인 검증을 실행하세요. 동일한 호출을 반복하거나, 형식만 변경된 리뷰를 수행하거나, 일관된 구현 상태 없이 호출하지 마세요. 빈번한 집중 리뷰는 유용하지만, 빈 리뷰는 그렇지 않습니다.
워크플로우
- 사용자의 실제 요구사항과 제약 조건을 이해합니다.
- 저장소, 그 규칙 및 영향을 받는 동작을 검사합니다.
- 요청된 변경 사항의 일관된 구현 조각을 만듭니다.
- 실용적인 경우 빠른 테스트, 타입 검사, 린터 또는 기타 검증을 실행합니다.
- 현재 조각을 평가하는 데 필요한 컨텍스트만 포함하여
jev_review를 호출합니다. - 신뢰도가 낮은 결과, 취약한 차원, 우선순위 문제 및 회귀를 검토합니다.
- 코드와 사용자의 작업이 뒷받침하는 피드백을 결정합니다. 평가를 모든 수치를 최적화하라는 지시가 아닌 증거로 취급하세요.
- 피드백이 실제 가치를 식별하는 곳에서 구현을 개선하며, 정확성, 인지 복잡도, 변경 용이성, 결합도, 모듈화, 추상화 품질, 테스트 및 보안을 우선시합니다.
- 다음 일관된 조각에 대해 구현, 검증 및 리뷰 루프를 반복합니다.
- 리뷰 기반 또는 기타 실질적인 변경 후,
jev_review를 다시 호출하고 이전 구조화된 평가를previousEvaluation으로 전달합니다. - 최종 전달 전에 저장소의 일반적인 검증을 실행하고, 최신 평가가 더 이상 최종 상태를 다루지 않는 경우 최종 상태를 리뷰합니다.
- 중요한 위험이 해결되고 추가 변경이 실질적인 가치를 거의 더하지 않을 때 중단합니다.
컨텍스트 선택
다음과 같은 형식의 집중 호출을 선호하세요:
{
"task": "사용자가 요청한 동작 및 관련 수용 제약 조건",
"diff": "구현 diff",
"files": [
{
"path": "src/example.ts",
"content": "diff를 이해하는 데 주변 코드가 필요한 경우에만 포함"
}
],
"repositoryContext": "관련 아키텍처, 규칙, 테스트 결과 또는 불변 조건",
"previousEvaluation": {}
}
Jev가 입력 제한을 초과했다고 보고하면 관련 없는 파일 내용을 줄이거나 구현을 일관된 리뷰 조각으로 분할하세요. 변경 사항을 올바르게 판단하는 데 필요한 계약, 호출자 또는 테스트를 제거할 정도로 코드를 무분별하게 자르지 마세요.
대부분의 리뷰에서는 task와 diff를 사용하세요. diff에 필요한 주변 동작이 부족한 경우에만 전체 파일을 추가하세요. 평가자가 추론할 수 없는 간결한 사실(예: 확립된 패턴 또는 검증 결과)을 위해 repositoryContext를 사용하세요.
기본적으로 전체 저장소를 보내지 마세요. 관련 없는 파일, 생성된 출력, 벤더 코드, 비밀, 자격 증명, 개인 키, 환경 파일 및 관련이 없는 잠금 파일 변경 사항은 제외하세요.
결과 해석
- 정확성과 사용자 요구사항이 모든 점수보다 우선합니다.
- 낮은 신뢰도 점수는 컨텍스트를 검사하라는 신호이지 코드를 재작성하라는 이유가 아닙니다.
applicable: false로 표시된 조건부 메트릭은 조치가 필요하지 않습니다.priorities를 사용하여 가장 중요한 취약 차원을 찾은 후, 코드를 변경하기 전에 실제 코드를 검사하세요.- 평가를 비교할 때는 의미 있는 회귀와 해결되지 않은 취약 메트릭을 조사하세요. 작은 점수 변화를 쫓지 마세요.
- 계속 테스트, 타입 검사, 린터, 보안 도구 및 인간의 판단에 의존하세요. Jev Review는 이를 보완할 뿐 대체하지 않습니다.
점수 게임 금지
더 높은 점수가 불필요한 추상화, 투기적 아키텍처, 범위 확장, 기존 동작 위반, 건전한 코드 재작성, 증거 없는 비관습적 아키텍처, 의미 없는 테스트, 불필요한 주석, 또는 응집력 있는 코드를 단순히 파일을 줄이기 위해 분할하는 것을 절대 정당화하지 않습니다.
짧은 함수, 작은 파일, 단일 목적 클래스, 중복 제로, 더 많은 추상화, 더 많은 테스트, 더 많은 주석이 본질적으로 더 좋다고 가정하지 마세요. 이 저장소와 이 작업에서의 결과를 평가하세요.