cancel:out-of-stock 배치가 교환과 반품 재출고 건까지 대상으로 삼는 것이 맞는지를 판단해야 했다. 이것은 기획 판단 사항이라고 적어서 넘기려던 참에 지적을 받았다.
Table of contents
Open Table of contents
조사 — 코드에 박힌 정책
정책이면 데이터베이스나 코드에 기록된 것이 있을 것이라는 지적이었다. 비슷한 판단을 전에 누군가 이미 내렸을 수 있다는 뜻이었다.
재출고 건을 식별하는 reship_parent_id 컬럼이 있으므로 그것을 참조하는 곳을 grep -rn 으로 저장소 전체에서 찾았다. ShipmentObserver 에서 재출고면 작업을 아예 안 만들고 있었고 주석에 그 이유까지 적혀 있었다.
두 개의 선례
FakeInvoicePenalty 산정에서도 같은 reship_parent_id IS NULL 조건으로 재출고 건을 명시적으로 제외하고 있었다. 첫 출고만 패널티 대상이라는 주석이 그 자리에 붙어 있었다.
즉 이 시스템에는 reship_parent_id 가 있는 건을 첫 출고와 다르게 취급하고 자동 처리 대상에서 뺀다는 정책이 이미 있었다. 백지에서 기획할 사안이 아니라 근거가 될 선례가 둘 있는 사안이었다.
원인 — 분류가 조사를 대신한 것
내가 왜 조사 없이 바로 넘기려 했는지도 함께 봤다. 비즈니스 판단이라고 분류한 순간 거기서 조사를 멈춘 것이다.
분류가 조사를 대신했다. 그런데 그 비즈니스 판단이 전에 이미 내려졌을 수도 있으므로 넘기기 전에 이미 답이 있는지를 봐야 한다. 정책은 문서에만 있는 것이 아니라 if 분기와 주석과 상수 이름과 제외 목록에 박혀 있다. 코드에 박힌 것이 실제로 도는 정책이라 문서보다 강하다.
주의 — 선례와 결정의 구분
선례 둘을 찾았지만 그것이 이번 건에 그대로 적용되는지는 별개 문제였다. 확인하지 못한 것이 하나 있었는데 문제의 배치 자체가 그 식별자를 참조하는지였다.
grep 결과에 CancelOutOfStock.php 가 없었지만 다른 이름의 JOIN 으로 걸러내고 있을 수도 있어서 배치 코드를 열어 봤어야 했다. 그래서 선례 둘이 있으므로 제외하는 쪽이 정책과 일관되지만 그 배치가 이 식별자를 참조하는지는 미확인이라고 적었다. 실제로 제외할지는 열린 결정이라고도 적었다.
결론 — 근거를 모으는 일
보고에는 두 가지 방법이 있었는데 선례 둘을 근거로 제외를 권고하는 것과 두 선택지를 근거와 함께 나란히 적고 결정을 남기는 것이다. 뒤쪽을 골랐다. 이유는 배치가 그 식별자를 참조하는지가 미확인이라서다. 대신 읽는 쪽이 결정을 한 번 더 내려야 하는 것을 감수했다. 적은 선택지는 reship_parent_id 가 있는 자식을 대상에서 제외하는 쪽과 현행을 그대로 유지하는 쪽이다.
앞쪽이 기존 정책과 일관된다는 근거는 제시했지만 그것으로 결정을 내린 것은 아니다. 근거를 모아 주는 것과 결정하는 것은 다른 일이고 조사자가 할 일은 앞의 것이다.
정리
- 정책성 판단은 기획으로 넘기기 전에
grep -rn으로 코드를 검색한다 - 정책은
if분기와 주석과 상수와 제외 목록에 박혀 있다 - 코드에 있는 것이 실제로 도는 정책이라 문서보다 강하다
- 비즈니스 판단이라는 분류가 조사를 대신하게 두지 않는다
- 선례를 찾아도 이번 건에 그대로 적용되는지는 별개다
- 확인 못 한 것은 미확인으로 적는다
- 결정은 열린 채로 남긴다
- 근거를 모으는 것과 결정하는 것은 다른 일이다