코드베이스 감사
감사의 가치는 순위와 증거에 있으며, 길이가 아닙니다. 파일 경로, 쿼리 결과, PR 번호, 또는 행 수가 없는 발견은 가설입니다. 그렇게 표시하십시오.
감사는 문서가 아닌 코드와 프로덕션에 근거합니다
프로젝트 노트, 계획, 상태 문서는 체크포인트이지 권위가 아닙니다. 이 문서들부터 시작하여 무엇이 주장되었는지 파악한 후, 실제 라이브 커밋, 데이터베이스 상태, PR 확인, 브랜치 헤드와 대조하여 검증하십시오.
문서와 코드가 일치하지 않을 때, 그 불일치 자체가 하나의 발견 사항입니다 — 종종 감사에서 가장 가치 있는 발견이 됩니다.
프로덕션에 대한 주장은 프로덕션에 대한 쿼리가 필요합니다. 구체적인 실행을 위해 검증 게이트 스킬과 페어링하십시오.
구조
# <범위> 감사 (YYYY-MM-DD)
## TL;DR
<핵심 3가지와 가장 먼저 할 일.>
## 파트 1 — 당신이 보지 못하는 것 (블라인드 스팟, 순위순)
## 파트 2 — 누락된 기능 (순위순, 각각 대략적인 노력 추정치 포함)
## 파트 3 — 개선이 필요한 기존 기능 (순위순)
## 파트 4 — 아키텍처 변경 (순위순, 평이한 영어로)
## 파트 5 — 내가 앞으로 30일을 운영한다면
## 검증 목록 (감사 중 발견된 불일치 사항)
모든 항목에 순위를 매기십시오. 40개의 발견 항목이 순위 없이 나열된 것은 실행 불가능한 40개의 항목 목록일 뿐입니다.
휴면 스캐폴드를 확인한 후 추정하세요
각 갭에 대략적인 노력 추정치를 첨부하고, 그 비용이 저렴하거나 비싼 이유를 설명하십시오.
가장 가치 있는 단일 감사 발견은 일반적으로 다음과 같습니다: 고가치 '갭'의 대부분은 몇 주가 아니라 며칠 만에 해결 가능한데, 그 이유는 스캐폴드(골격)가 이미 리포지토리에 존재하지만 호출자가 없기 때문입니다. 이미 80% 완성된 기능은 완전히 새로운 기능과는 완전히 다른 의사 결정을 요구합니다.
무언가가 없다고 선언하기 전에 먼저 grep 하십시오. 호출자가 없는 함수가 전형적인 사례입니다 — 코드는 존재하지만 아무도 호출하지 않으며, 모든 상태 문서는 해당 기능이 없다고 설명합니다.
검증 목록
모든 감사는 해결하지 못한 불일치 사항으로 끝납니다. 각 항목은 다음을 명시합니다:
- 무엇이 주장되었는지
- 무엇이 관찰되었는지
- 그것을 해결할 쿼리나 확인 방법
이 섹션이 다음 세션에서 실제로 사용하는 부분입니다. 짧아도 작성하십시오.
명시적으로 수행할 가치가 없는 섹션
검토했지만 의도적으로 거부한 항목을 이유와 함께 명시하십시오.
백로그에 항목만 추가하는 감사는 백로그를 쓸모없게 만듭니다. 검토하고 기각한 발견 사항은 언급조차 하지 않은 발견 사항보다 가치가 있습니다. 다음 감사에서 다시 제기되는 것을 방지하기 때문입니다.
보류된 항목은 갭이 아닙니다
명시적으로 의도적으로 연기되었거나, 명시적인 인간의 결정을 위해 보류된 모든 항목은 의도적으로 보류된 것입니다. 이를 갭으로 나열하지 마십시오.
의도적인 보류를 발견 사항으로 다시 표면화하는 것은 보류된 결정이 실수로 실행되는 방식입니다.
출력
감사는 프로젝트가 보관하는 위치에 작성하십시오. 이전 감사를 대체하는 경우, 어느 감사이며 무엇이 변경되었는지 명시하십시오. 감사 폴더는 단순한 더미가 아닌 연속적인 시퀀스로 읽을 수 있어야 합니다.