리뷰 리마크 해결하기
소스 코드의 올바른 위치에 설명 주석을 삽입하여 코드 리뷰 리마크를 해결합니다. 이렇게 하면 향후 리뷰어가 동일한 문제를 제기하지 않도록 근거를 제시할 수 있습니다.
입력
두 입력 모두 대화 맥락에서 추론합니다. 모호한 경우에만 질문하세요.
입력 1 — 리마크.
리뷰어의 발견 사항: 보통 위치(파일:줄)와 우려 사항 설명이 포함된 테이블 행입니다.
해당 테이블은 일반적으로 dakubo-display-pr-remarks 또는 dakubo-review-commit-range 스킬에서 제공됩니다. 대화에 테이블이 없고 이러한 스킬 중 하나를 사용할 수 있다면, 해당 스킬을 사용하여 테이블을 만드세요. 그렇지 않다면 사용자에게 리마크를 물어보세요.
입력 2 — 설명. 개발자의 응답: 코드가 현재 상태로 올바른 이유, 그 뒤에 숨은 설계 결정, 수용한 트레이드오프, 또는 리뷰어가 놓치고 있던 큰 그림 맥락입니다. 이는 리마크를 직접 반박하지 않을 수도 있습니다. 단지 리뷰어의 관점을 바꾸는 데 그칠 수도 있습니다.
프로세스
- 입력 1의 위치에 있는 파일을 읽습니다.
- 리마크가 대상으로 삼는 정확한 구조물(메서드, 블록, 필드, 라인)을 식별합니다.
- 다음 조건을 충족하는 주석을 작성합니다:
- 입력 2(근거/결정/맥락)의 핵심을 담습니다.
- 간결해야 합니다. 최대 1~4줄.
- 주석 내에서 리뷰어, PR, 리마크 번호를 언급하지 않습니다 (주석은 리뷰보다 오래 남습니다).
- 코드가 이미 말하는 내용을 반복하지 않습니다. 읽기만으로는 명확하지 않은 이유(WHY)만 추가합니다.
- 설명을 더 명확하게 하는 데 도움이 된다면 리마크의 우려 사항을 다루어도 되지만, 이는 선택 사항입니다.
- 대상 구조물 바로 위에 주석을 배치하거나, 후행 주석이 자연스러운 경우 인라인으로 배치합니다.
- 편집을 적용합니다.
출력
주석이 추가된 파일과 줄을 확인합니다. 한 문장이면 충분합니다.
하지 말아야 할 것
- 사용자가 명시적으로 요청하지 않는 한 코드를 다시 작성하지 마십시오.
- 코드가 하는 일을 단순히 다시 설명하는 주석을 작성하지 마십시오.
- 주석 내에서 "리뷰어가 말하길…" 또는 "PR #N"을 참조하지 마십시오.
- 약 4줄보다 긴 주석을 추가하지 마십시오. 설명에 더 많은 내용이 필요하다면 설계 문서나 커밋 메시지에 속하며, 인라인 주석으로 적합하지 않습니다.