같은 주문이 두 번 업로드되고 있어서 버그로 보고 막으려 했다. 하루치를 세니 412건이 두 번씩 올라가 있었다.
Table of contents
Open Table of contents
두 번 올리는 설계
중복 방지를 넣기 전에 왜 두 번인지부터 봤다. 1차는 주문 완료 시점에 올리고 2차는 배송 완료 후 최종 금액이 확정되면 올리는 구조였다.
주문 뒤에 부분 취소나 추가 배송비로 금액이 바뀔 수 있으므로 확정되면 다시 올리는 것이 설계였다. 막았으면 최종 금액이 영영 안 올라갔을 것이다.
기준을 좁힌 재집계
왜 중복으로 보였는지도 분명했다. 중복 여부를 주문번호로만 세고 업로드 종류를 안 봤기 때문이다.
주문번호와 종류를 함께 묶어 세니 중복이 0건이었다. 같은 종류로 두 번 올라간 것은 없었고 무엇을 중복으로 볼지가 문제였던 것이다.
기간을 넓혀 다시 세니 최종 업로드가 세 번인 건이 나왔다. 이것은 진짜 중복이었고 응답을 못 받고 다시 보낸 재시도가 둘 다 들어간 경우였다. 기준을 좁히니 가짜 중복이 사라지고 진짜 중복이 드러났다.
진짜 중복만 막기
방지 로직은 주문번호와 종류 둘로 확인하게 넣었다. 종류가 다르면 통과하므로 설계대로 두 번 올라가는 것은 그대로 두고 같은 종류의 반복만 막힌다.
이 판단을 코드만 보고 하지 않고 물어봤다. 확정 전과 확정 후를 둘 다 올리고 상대 쪽에서 최종 것으로 덮는다는 답을 받았다. 물어보지 않았으면 막았을 것이다.
의도의 기록
의도를 코드 주석으로 남겼다. 왜 두 번 올리는지와 상대가 어떻게 처리하는지와 무엇만 막는지를 적었다.
몇 달 뒤 다른 사람이 같은 것을 발견하고 그 주석을 보고 넘어갔다. 이상해 보이는 것이 의도라면 그 이유가 코드에 없을 때 반복해서 버그로 신고된다.
비슷한 것이 더 있는지도 찾았다. 같은 알림이 두 번 나가는 것과 같은 파일이 두 자리에 있는 것은 의도였고 같은 값이 두 테이블에 있는 것은 정리 대상이었다. 셋을 가르는 데 물어보는 것이 가장 빨랐다.
상대 쪽 처리 확인
우리가 두 번 올리는 것이 맞다고 해도 상대가 어떻게 처리하는지는 별개였다. 두 번째 것으로 덮는다는 말을 실제로 확인했더니 나중에 올린 금액으로 조회됐다.
순서가 뒤집히는 경우도 봤는데 시각이 아니라 도착 순서로 덮고 있어서 1차가 나중에 도착하면 옛 값이 남았다. 말로 확인한 동작을 순서가 뒤집힌 조건에서 한 번 더 재야 실제 보장 범위가 드러난다. 우리가 1차 응답을 받고 나서 2차를 보내도록 순서를 보장하게 바꿨다.
정리
- 이상해 보이는 것이 의도된 것일 수 있다
- 고치기 전에 왜 그런지 본다
- 무엇을 중복으로 볼지가 문제이므로 기준을 좁혀 다시 센다
- 기준을 바꾸면 진짜 중복이 드러난다
- 코드만 보고 판단하지 말고 물어본다
- 의도를 코드에 적으면 다음 사람이 또 버그로 보지 않는다
- 비슷한 것을 더 찾되 의도인지 물어서 가른다
- 상대가 어떻게 처리하는지는 순서가 뒤집힌 조건에서 확인한다