검토를 돌 때마다 결과를 적었다

같은 코드를 여러 번 돌아가며 봤는데 세 번째 회차에서 첫 회차와 같은 것을 다시 찾았다.

Open Table of contents

증상 — 볼 때마다 처음부터 보던 방식
조치 — 회차마다 적었다
대응 — 안 본 영역 목록
판단 기준 — 찾은 것의 성격
검증 — 무엇으로 확인했는지
사전 준비 — 다음 회차와 한 문서
정리

증상 — 볼 때마다 처음부터 보던 방식

회차별로 무엇을 봤는지 순서대로 돌아봤다.

1회차   설정 파일 훑음. 하드코딩된 값 몇 개 발견
2회차   쿼리 훑음. 인덱스 없는 조회 발견
3회차   설정 파일 다시 훑음. 같은 하드코딩 발견  ←

1회차에서 config/db.php 의 하드코딩을 찾고도 고치지도 적지도 않고 넘어갔다.

3회차에 같은 자리를 다시 찾고 나서야 이거 전에 봤는데가 떠올랐다. 기억에 의존하면 며칠만 지나도 어디까지 봤는지가 흐려진다.

조치 — 회차마다 적었다

그래서 REVIEW.md 에 회차마다 날짜와 본 영역과 찾은 것을 적기 시작했다.

[1회차] 2019-04-20 설정
  ( ) config/db.php 에 운영 주소 하드코딩 (13행)
  ( ) config/app.php 에 API 키 (41행)  ← 급함
  (x) 로그 경로가 상대 경로 (fixed 2019-04-20)

[2회차] 2019-04-23 쿼리
  ( ) orders.channel_order_no 인덱스 없음
  (x) N+1 조회 3곳 (fixed 2019-04-23)
  확인함: 슬로우 쿼리 로그에 다른 문제 없음

[3회차] 2019-04-27 배포·운영
  ( ) 배포 후 확인 절차 없음
  확인함: 설정 파일은 1회차에서 봤음. 남은 것 2건

확인함 을 적으니 다시 안 봤고 orders.channel_order_no 처럼 남은 것도 목록으로 보인다. 다만 확인함 에는 무엇으로 확인했는지가 붙어야 한다. 슬로우 쿼리 로그는 MySQL 5.7 매뉴얼대로 long_query_time 을 넘긴 문장만 남기므로 거기 없다는 것이 빠른 문제까지 없다는 뜻은 아니다.

찾은 것만 적으면 config/app.php 처럼 확인했는데 문제가 없던 자리가 빠져 다음 회차에 또 보게 된다. 결국 검토 기록의 절반은 다음에 볼 것을 줄이기 위한 것이었다.

대응 — 안 본 영역 목록

무엇을 봤는지만 적으면 아직 안 본 것이 무엇인지 모른다.

[아직 안 본 것]
  프런트엔드 코드
  배치 스크립트 (crontab 에 있는 것)
  시험 코드

프런트엔드 와 배치 스크립트 와 시험 코드 가 남아 있었다.

이것을 안 적던 전에는 대충 다 본 것 같다는 느낌으로 끝났다. crontab 에 걸린 배치 스크립트 쪽은 세 회차 동안 한 번도 안 열린 채로 남아 있었다.

판단 기준 — 찾은 것의 성격

찾은 것을 성격에 따라 넷으로 나눴다.

급함     지금 고쳐야 한다 (보안·데이터 손실)
중간     이번 주에
낮음     시간 날 때
안 함    확인했지만 고치지 않기로 함 (이유 적음)

안 함 이라는 칸이 필요했는데 안 고치기로 한 것을 안 적으면 다음 회차에 또 찾는다.

(안 함) legacy/order/list.php 의 중복 코드
        이유: 3개월 뒤 삭제 예정. 지금 고칠 이유 없음

legacy/order/list.php 처럼 이유를 함께 적어야 같은 것을 다시 논의하지 않는다.

검증 — 무엇으로 확인했는지

고쳤다고 적어 놓고 실제로는 확인을 안 한 것이 있었다.

(x) N+1 조회 3곳 (fixed 2019-04-23)
    확인: 쿼리 로그에서 412 → 3 (2019-04-24)

쿼리 로그 에서 무엇을 보고 확인했는지까지 적었다.

고쳤다는 말과 확인했다는 말은 다른데 N+1 한 건은 고쳤다고 적었으나 확인해 보니 한 곳이 남아 있었다.

사전 준비 — 다음 회차와 한 문서

다음 회차에 무엇을 볼지도 미리 정해 뒀다.

[4회차 예정] 배치 스크립트
  crontab 에 있는 것 전부 열거
  각각 무엇을 하는지, 실패하면 어떻게 되는지
  로그를 남기는지

범위를 안 정하면 눈에 띄는 것부터 보다가 흩어진다.

회차마다 새 문서를 만드는 것과 한 문서에 붙이는 것 두 가지 방법 중 뒤쪽을 골랐다. 이유는 새 문서를 만들면 앞의 것을 안 보게 된다는 점이다. 대신 문서가 길어져 위쪽 요약이 없으면 현재 상태를 못 찾는 것을 감수했다. 그래서 REVIEW.md 한 문서에 계속 붙였다.

[코드 점검] 2019-04 ~
  현재 상태: 4회차 중 3회차 완료
  남은 지적: 급함 1, 중간 4, 낮음 8
  안 본 영역: 프런트엔드, 시험 코드

문서 위쪽의 현재 상태 한 줄만 봐도 어디까지 왔는지 안다.

그 아래에는 회차별 기록이 순서대로 쌓이고 검토가 여러 회차로 나뉘는 순간부터 회차 사이를 잇는 이 기록이 필요했다.

정리

검토 결과를 안 적으면 같은 것을 다시 찾는다
회차마다 무엇을 봤고 무엇을 찾았는지 적는다
확인했지만 문제없던 것도 적어 다시 안 본다
안 본 영역을 적는다
안 적으면 대충 다 본 것 같다로 끝난다
찾은 것을 성격으로 나눈다
안 고치기로 한 것과 그 이유를 남긴다
고친 것은 무엇으로 확인했는지 적는다
고쳤다는 것과 확인했다는 것은 다른 말이다
다음 회차 범위를 미리 정한다
한 문서에 계속 쓰고 위에 요약을 둔다