변경 이유와 리뷰 요청

리뷰어가 재현할 수 있게 씁니다

성능 개선은 코드가 짧아졌다는 설명으로 검토하기 어렵습니다. 리뷰어는 어떤 사용자 문제가 있었고 왜 이 변경이 그 문제에 맞는지 판단해야 합니다. 첫 문장은 “같은 행사 목록을 다시 갱신할 때 카드 전체가 재생성됐다”처럼 구체적으로 씁니다. 이어서 “현재 목록의 같은 내용 카드를 재사용한다”는 최종 동작을 적습니다. 근거 없는 체감 속도 약속은 제목에도 넣지 않습니다.

이번 제출물은 미션의 REVIEW.md와 performance.json입니다. 작성자는 동작 코드뿐 아니라 실행 방법과 제한을 함께 전달합니다. 성능 기록의 raw·median·구간·환경을 연결하고 리뷰 설명에는 결과를 해석한 이유를 씁니다. 같은 수치를 여러 문서에 복사하면 갱신 때 서로 어긋날 수 있으므로 원자료 파일을 기준으로 삼고 설명에는 필요한 결론만 남깁니다.

변경 범위는 책임별로 적습니다. measurement는 구간과 중앙값을, dom은 카드 재사용을, components는 이미지 비율을, lifetime은 정리를, results는 실제 연결을 맡습니다. 테스트 파일은 이 계약의 반례를 추가합니다. 읽는 사람이 앱 전체 구조를 기억해야만 이해할 수 있는 표현은 피합니다. 어떤 파일이 왜 바뀌었는지 한 문장씩 연결하면 검토 순서를 정하기 쉽습니다.

수치의 비교 조건을 빼면 작은 중앙값이 설득력이 없습니다. 같은 1000개 행사·동일 반복 구간·첫 렌더 제외·같은 런타임이라는 조건을 붙입니다. 브라우저 화면과 네트워크 조건이 없는 Node 모델 기록은 그 사실을 명시합니다. 모델 시간의 변화와 이미지 레이아웃 안정성은 다른 증거입니다. 한 값으로 전체 사용자 품질이 개선됐다는 문장을 쓰지 않습니다.

개선 여부는 실제 기록으로 결정합니다. 전후 중앙값이 비슷하거나 후가 더 크면 미개선과 가능한 이유를 남깁니다. 캐시 관리·signature 계산이 생성 감소의 이익을 상쇄할 수 있습니다. 실제 앱은 로딩에서 목록을 비우므로 같은 카드 재사용 범위도 좁습니다. 이 제한을 알려야 리뷰어가 채택·수정·보류를 선택할 수 있습니다. 성능 작업의 완료와 최적화 채택은 같은 판단이 아닙니다.

검증 항목에는 실행한 명령·종료 코드·검사 범위·미실행 범위를 씁니다. npm test는 모델과 문서·계산·API·요청 순서 회귀입니다. npm run measure는 실제 Node 원자료 생성입니다. npm run test:e2e는 별도의 실제 브라우저 흐름입니다. 마지막 명령을 실행하지 않았다면 PENDING이라고 남깁니다. 자동 검사가 읽어 준 성공 문구를 수동 모바일 관찰로 바꾸어 적지 않습니다.

리뷰 전 diff에서 관련 없는 편집을 찾습니다. 이번 작업의 변경 경로만 지정해 git diff --stat와 git diff --check를 읽고 필요한 파일의 diff를 확인합니다. 이 devinkr 저장소에서는 커밋과 푸시를 하지 않습니다. 별도 실습 저장소에서 리뷰 흐름을 연습할 수 있지만 이번 제출에는 변경 파일·검증 기록만 있으면 됩니다. 다른 작성자의 파일을 되돌리는 방식으로 범위를 줄이지 않습니다.

추적되지 않은 파일은 git diff에 나타나지 않을 수 있습니다. git status --short로 새 파일을 확인하고 내용을 직접 읽어 제출 목록에 포함합니다. 비교가 필요하면 독립된 실습 폴더의 원본과 수정본을 git diff --no-index로 비교합니다. 차이가 있을 때 이 명령의 종료 코드 1은 차이 발견이며 테스트 실패와 같은 의미가 아닙니다. 공백 오류와 의미 있는 코드 변경도 구분해 읽습니다.

충돌 표식을 발견하면 양쪽 의도를 먼저 설명합니다. 같은 renderList에서 한쪽은 카드 재사용을, 다른 쪽은 안전한 제목 표시를 지켰을 수 있습니다. 한쪽을 전부 택하면 다른 계약을 잃습니다. 독립된 실습 복사본에서 필요한 행동을 결합하고 제목 안전성·href 갱신·빈 목록·포커스 회귀를 재실행합니다. 현재 공동 작업 저장소의 다른 변경을 충돌 연습 대상으로 삼지 않습니다.

AI의 개선 제안도 리뷰 대상입니다. 공개 교육용 행사 fixture와 필요한 작은 함수만 전달하고 자격증명과 운영 데이터를 넣지 않습니다. 제안된 API가 실제 존재하는지 문서로 확인하고 실행합니다. id만 캐시하라는 제안에는 제목과 URL 변경 반례를 넣습니다. WeakMap이면 누수가 없다는 주장에는 다른 강한 참조와 현재 소유권을 설명하며 검증되지 않은 결론을 채택하지 않습니다.

AI를 썼다면 무엇을 맡겼고 무엇을 직접 검증했는지 기록합니다. 예를 들어 반례 목록 제안은 참고했지만 중앙값 구현과 캐시 경계는 테스트와 코드로 확인했다고 씁니다. 쓰지 않았다면 미사용으로 적습니다. 도구가 생성한 긴 설명을 그대로 붙이면 실제 변경과 어긋날 수 있습니다. 최종 파일을 기준으로 리뷰 설명을 다시 쓰고 학습자가 주요 분기를 자신의 말로 설명합니다.

리뷰 의견은 행동·근거·제안으로 작성합니다. “캐시가 위험하다”보다 “href가 signature에서 빠져 검색 조건 변경 뒤 상세 복귀 URL이 옛 값을 유지할 수 있습니다. URL 변경 반례를 추가해 주세요”가 실행 가능합니다. 반대로 이미 포함된 반례를 모르고 요구하지 않도록 테스트부터 읽습니다. 취향에 따른 이름 변경과 사용자 계약 결함을 구분하고 우선순위를 표시합니다.

작성자의 답변은 반영 여부와 새 근거를 붙입니다. 의견을 수용했다면 변경 위치와 검사 명령을, 보류했다면 현재 범위와 후속 조건을 씁니다. 모든 의견에 “수정했습니다”라고만 쓰면 리뷰어가 다시 전체 diff를 찾아야 합니다. 모델 시간이 나빠졌다는 지적에는 새 측정 결과를 원자료와 함께 제시하고 수치를 지우거나 기대값을 바꾸어 논쟁을 끝내지 않습니다.

되돌릴 방법도 작게 정의합니다. 카드 재사용이 실제 브라우저에서 문제를 만들면 기존 전체 생성 경로로 바꾸되 이미지 비율과 정리 계약까지 함께 버릴 필요가 있는지 판단합니다. 변경을 책임별로 나눈 이유입니다. 배포나 운영 재시작은 이번 과제가 아닙니다. 리뷰 설명에는 수정의 적용 범위와 안전하게 비교할 독립된 실습 경로만 적습니다.

제출물 평가는 자동·사람 검토를 나눕니다. 테스트는 기대 동작과 일부 입력 경계를 확인합니다. 사람이 보는 기준은 문제와 변경의 연결·측정 해석의 정직함·미확인 범위·관련 없는 수정 여부·설명 가능성입니다. REVIEW.md에 제목만 채워도 자동 모델은 통과할 수 있으므로 사람 기준을 생략하지 않습니다. 작은 성능 수치보다 재현과 한계를 명확히 설명하는 자료가 검토에 유용합니다.

완료 전에 리뷰어 역할로 새 폴더에서 실행 절차를 읽습니다. 필요한 런타임과 의존성 설치, 테스트와 측정 파일 위치, PENDING 후속 관찰을 찾을 수 있는지 확인합니다. 원래 제보의 행동을 따라 변경의 범위를 설명하고 남은 위험을 한 문장으로 적습니다. 더 읽기의 테스트·디버깅 장은 조사 방법을 넓히며 이번 REVIEW.md는 최종 행사 탐색 프로젝트의 실제 근거로 남깁니다.

API와 명령 세부 확인: Git diff 문서를 참고합니다.