있었는데 안 찾아본 것

교환 재출고 건의 구매확정 동기화가 미구현이라는 전제로 작업을 잡았다. 자동으로 처리하는 것이 없으니 만들어야 한다고 봤다.

Open Table of contents

미구현이라는 전제

작업 중에 구매확정은 정산 과정에서 처리되는 것 아니냐는 지적이 들어왔다. 그 문장이 내 전제를 검증 대상으로 만들었다.

없다는 판단은 어디서 왔는지 돌아보니 증상에서 추측한 것이었다. 교환 건이 확정되지 않는다는 사실만 있었고 자동화가 없다는 것은 확인한 적이 없었다.

관련 키워드로 코드를 검색하니 자동 구매확정 배치가 바로 나왔다. 스케줄러에도 등록돼 매일 돌고 있었다.

미구현이 아니라 이미 있고 실행되고 있었다. 만들기 전에 몇 초짜리 검색을 한 번 돌리는 것으로 중복 구현을 피했다.

그러면 왜 우리 건은 처리가 안 되는지가 다음 물음이 된다. 대상 조회 조건을 보니 상태 조건에는 교환 재출고가 포함돼 있고 다른 컬럼이 비어 있어야 한다는 조건이 하나 더 있었다.

교환 재출고로 생긴 항목이 그 컬럼에 값을 갖는다면 대상에서 빠진다. 없다면 만들어야 하고 안 된다면 조건을 보면 되는데 증상은 둘 다 처리가 안 됨으로 같게 보인다.

그 조건이 실제로 배제하는지는 데이터를 조회해야 확정된다. 배제하는 것이 맞으면 조건 한 줄을 고치는 작은 작업이고 아니면 다른 원인을 찾아 범위를 다시 잡아야 한다.

구현 범위가 완전히 달라지므로 이 확정 없이 착수하면 큰 기능을 만들다가 조건 한 줄이었다는 것을 알게 된다. 그래서 배치가 존재하고 돈다는 것은 확정으로 적고 그 조건이 배제하는지는 미검증으로 나눠 적었다.

이 검증의 계기는 밖에서 들어온 한 문장이었다. 전제는 전제이기 때문에 스스로 의심하기가 어렵다.

앞서 다른 조사에서는 정말 미착수인 경우도 있었고 여기서는 이미 있는 경우였다. 둘 다 코드가 없어 보인다에서 시작했으므로 확인하기 전에는 어느 쪽인지 알 수 없다.