한 번 고침에 남은 이력 셋

가격을 일괄로 보정하면서 화면에 변경 내역이 보이도록 이력도 남겨야 했다. 이력을 몇 건 어떤 내용으로 넣어야 하는지가 문제였다.

Open Table of contents

이력을 몇 건 넣어야 하는가

추측하지 않고 화면에서 정상으로 수정된 상품 하나를 골라 이력을 조회했다. 한 번의 수정에 대해 이력이 세 건 남아 있었다.

한 건은 변경 전후 값이 담긴 것이고 다른 한 건은 같은 문구인데 데이터가 비어 있었으며 마지막은 가격 정보 수정이라는 별개 문구였다. 수동으로 재현할 때 개수를 안 맞추면 화면에서 정상 건과 다르게 보인다.

이 대조로 넣어야 할 이력의 개수와 각각의 문구와 데이터 형태가 한 번에 나왔다. 코드를 따라가 이력이 어디서 몇 번 남는지 추적하는 것보다 훨씬 짧은 길이었다.

정상 경로가 건드리는 테이블도 이력과 가격 이력과 수수료율과 전송 작업까지 넷이었다. 하나라도 빠지면 화면이나 후속 처리가 어긋난다.

세 번째 이력의 데이터를 열어 보니 발송 여부를 뜻하는 이름의 필드에 큰 정수가 들어 있었다. 참과 거짓을 담는 자리라면 나올 수 없는 값이었다.

찾아보니 방금 만들어진 가격 이력 레코드의 식별자였다. 이름은 불리언을 암시하는데 내용은 다른 테이블의 식별자였다.

이것을 확인하지 않고 발송했으니 참에 해당하는 값을 넣었다면 그 자리에 엉뚱한 수가 들어간다. 삽입은 성공하고 화면 이력 목록에도 정상으로 뜬다.

눌러서 상세를 열 때만 연결이 없다는 것이 드러나고 넣는 시점에는 아무 신호가 없다. 이름이 값의 종류를 암시해도 실제 값의 분포를 한 줄로 확인하는 습관이 여기서 나왔다.

가격 수정 흐름은 여러 서비스를 거치므로 코드로 추적하면 이력이 어디서 몇 번 남는지 따라가는 데 시간이 든다. 정상 건 하나를 조회하면 그 결과가 바로 나온다.

그래서 수동 작업 절차를 가격 갱신과 가격 이력 삽입과 그 식별자를 담은 이력 삽입 순서로 정했다. 앞 단계에서 나온 식별자가 뒤 단계에 들어가므로 순서 자체가 고정된다.