sellers.settlement_cycle 에 숫자만 들어 있어서 값이 무엇을 뜻하는지를 코드에서 찾아야 했다. 값이 1 과 2 와 3 셋이었고 그 값을 쓰는 코드를 보니 주간과 격주와 월간을 뜻하고 있었다.
Table of contents
Open Table of contents
배경 — 값 하나에 딸린 넷
각각이 정확히 언제 정산하는지는 코드를 더 따라 읽어야 알 수 있는 상태였다. 그래서 값별로 이름과 정산일과 대상 기간과 min_amount 를 SETTLEMENT.md 한 표로 정리해 적었다.
거기에 주의 사항도 붙였는데 정산일이 공휴일이면 다음 영업일이라는 것과 최소 금액 미만은 이월된다는 것과 격주 기준일이 cycle_anchor_date 컬럼을 따른다는 것이었다. 값 하나에 딸린 것이 넷 이상이므로 그것을 다 적어야 판단할 수 있다.
원인 — 적으면서 나온 불일치
문서를 만들고 코드와 대조했더니 최소 금액은 맞는데 이월 처리가 달랐다. 문서에는 월간이 이월 없음이라고 적혀 있는데 코드는 월간도 이월하고 있었다.
min_amount 가 0 으로 돼 있어 실제로 걸릴 일이 없었으므로 그동안 안 드러난 것이었다. 정책을 적으면서 코드와 대조하는 과정 자체가 이 불일치를 찾아낸 셈이다.
조치 — 값과 정책을 코드로
두 가지 방법이 있었는데 숫자를 그대로 두고 문서만 유지하는 것과 SettlementCycle 열거형으로 모으고 정책도 코드 값으로 두는 것이다. 뒤쪽을 골랐다. 이유는 문서만 두면 코드가 바뀔 때 문서가 따라오지 못해서다. 대신 settlement_cycle 을 읽는 자리를 전부 찾아 고치는 작업을 감수했다. 주기별로 이름과 정산일과 기간과 min_amount 와 carry_over 를 함께 반환하는 policy() 로 만들었다.
화면에서도 그것을 읽어 협력사가 자기 정산 조건을 볼 수 있게 하니 문의가 줄었다. 문서 표도 코드에서 뽑게 해서 코드를 고치면 문서가 따라 바뀌게 했고 코드에 없는 주의 사항만 손으로 적었다.
주의 — 새 값을 막는 장치
policy() 에 모르는 값이 들어오면 InvalidArgumentException 을 던지는 default 분기를 뒀다. 그러면 새 값을 넣는 순간 그 자리에서 바로 걸리게 된다.
정책을 정하지 않은 채 값만 늘리는 것을 막으려고 넣은 장치다. 값이 늘어난 뒤에 정책을 찾는 것보다 값을 넣을 때 정책을 요구하는 쪽이 낫다.
검증 — 적용 시점이 있는 정책
정산 주기 정책은 바뀔 수 있는데 최소 금액이 오르거나 정산일이 바뀌는 식이다. 그렇게 바뀔 때 언제부터 적용할 것인지가 곧바로 문제가 된다.
그래서 policy(Carbon $at) 로 시점을 함께 받아 그 시점의 정책을 돌려주도록 만들었다. 이렇게 하지 않으면 과거 정산을 다시 계산할 때 지금 정책이 적용돼 금액이 달라지므로 정책에는 적용 시점이 함께 있어야 한다.
정리
- 컬럼에 숫자만 있으면 무엇을 뜻하는지 코드를 찾아야 한다
- 값에 딸린 정책까지 적는다
- 정산일과 기간과 최소 금액과 예외를 함께 적는다
- 적으면서 코드와 대조하면 안 맞는 것이 나온다
- 값을 상수로 모으고 정책도 값으로 둔다
- 정책을 화면에서 보여 주면 문의가 준다
- 문서를 코드에서 뽑아야 따로 두어 갈리지 않는다
- 정책에는 적용 시점이 함께 있어야 한다