문서에 없고 동작에만 있는 규칙

외부 시스템의 반품 관련 인터페이스를 공식 문서대로 구현했는데 동작이 예상과 계속 달랐다. 어긋나는 자리를 하나씩 관측해서 규칙을 다시 세웠다.

Open Table of contents

상태에 따라 갈리는 목록

같은 건이 어떤 목록에서는 조회되고 어떤 목록에서는 안 나왔다. 준비 단계에서 요청한 것은 두 목록에 다 있고 배송 지시 이후에 요청한 것은 한쪽에만 있었다.

문서에는 각 목록이 무엇인지만 적혀 있고 어떤 건이 어디에 들어가는지가 없었다. 두 목록을 다 조회하고 합치면서 중복을 제거하는 방식으로 처리했다.

특정 유형만 골라 조회하는 방법이 없어서 전부 받아 거르는 수밖에 없었다. 거르는 조건은 사전 환불 여부와 완료 확인 유형과 취소 수행 주체 세 필드의 조합이었다.

각 필드는 혼자서는 아무것도 알려 주지 않는다. 실제 데이터를 여러 건 받아 상태별로 필드값을 표로 만들고 나서야 그 조합이 보였다.

가장 곤란한 것은 철회되면 목록에서 항목 자체가 없어지는 동작이었다. 받아서 처리하는 중인데 다음 조회에서 안 보이면 삭제인지 조건 불일치인지 우리 조회가 틀린 것인지 알 수 없다.

비슷한 다른 도메인은 상태만 바뀌고 목록에는 남으므로 여기만 다른 설계였다. 최초 접수 때 식별자를 저장해 두고 철회 이력을 따로 조회하는 인터페이스를 붙여서 사라진 이유를 확인하게 했다.

스키마에 있는데 값이 항상 0인 배송비 필드가 있었다. 이름만 보면 실제 금액이 들어올 것 같아서 그대로 쓰면 배송비를 항상 0으로 계산하게 된다.

개수를 뜻하는 필드도 개별 항목 수량이 아니라 접수 건에 포함된 전체 합이었다. 오류가 나지 않고 값만 틀리는 부류이고 이름이 자연스러울수록 확인 없이 쓰게 된다.

발견할 때마다 항목별로 문서에 모았더니 다섯 줄짜리 목록이 됐다. 공식 문서보다 이 목록이 구현에 더 쓸모가 있었으므로 실질적인 명세는 관측한 동작 쪽이었다.

다만 표본이 적으면 우연히 그렇게 보였을 수 있어서 다른 사람이 원문과 대조하게 했다. 대조에서 대부분 맞았고 하나는 조건이 더 좁아서 그것을 반영했다.