컬럼 값과 정책의 대응표

정산 주기를 나타내는 컬럼에 숫자만 들어 있어서 값이 무엇을 뜻하는지를 코드에서 찾아야 했다. 값이 셋이었고 그 값을 쓰는 코드를 보니 주간과 격주와 월간을 뜻하고 있었다.

Open Table of contents

값 하나에 딸린 넷

각각이 정확히 언제 정산하는지는 코드를 더 따라 읽어야 알 수 있는 상태였다. 그래서 값별로 이름과 정산일과 대상 기간과 최소 금액을 하나의 표로 정리해 적었다.

거기에 주의 사항도 붙였는데 정산일이 공휴일이면 다음 영업일이라는 것과 최소 금액 미만은 이월된다는 것과 격주 기준일이 별도 컬럼을 따른다는 것이었다. 값 하나에 딸린 것이 넷 이상이므로 그것을 다 적어야 판단할 수 있다.

문서를 만들고 코드와 대조했더니 최소 금액은 맞는데 이월 처리가 달랐다. 문서에는 월간이 이월 없음이라고 적혀 있는데 코드는 월간도 이월하고 있었다.

최소 금액이 0으로 돼 있어 실제로 걸릴 일이 없었으므로 그동안 안 드러난 것이었다. 정책을 적으면서 코드와 대조하는 과정 자체가 이 불일치를 찾아낸 셈이다.

코드 여기저기에 흩어져 있던 숫자를 상수로 모으고 정책도 값으로 뒀다. 주기별로 이름과 정산일과 기간과 최소 금액과 이월 여부를 함께 반환하는 형태로 만들었다.

화면에서도 그것을 읽어 협력사가 자기 정산 조건을 볼 수 있게 하니 문의가 줄었다. 문서 표도 코드에서 뽑게 해서 코드를 고치면 문서가 따라 바뀌게 했고 코드에 없는 주의 사항만 손으로 적었다.

정책을 반환하는 자리에 모르는 값이 들어오면 예외를 던지는 분기를 뒀다. 그러면 새 값을 넣는 순간 그 자리에서 바로 걸리게 된다.

정책을 정하지 않은 채 값만 늘리는 것을 막으려고 넣은 장치다. 값이 늘어난 뒤에 정책을 찾는 것보다 값을 넣을 때 정책을 요구하는 쪽이 낫다.

정산 주기 정책은 바뀔 수 있는데 최소 금액이 오르거나 정산일이 바뀌는 식이다. 그렇게 바뀔 때 언제부터 적용할 것인지가 곧바로 문제가 된다.

그래서 정책을 조회할 때 시점을 함께 받아 그 시점의 정책을 돌려주도록 만들었다. 이렇게 하지 않으면 과거 정산을 다시 계산할 때 지금 정책이 적용돼 금액이 달라지므로 정책에는 적용 시점이 함께 있어야 한다.