재스테이킹 건의 만기 자동 정산이 미구현이라는 전제로 작업을 잡았다. 자동으로 처리하는 것이 없으니 StakingSettleJob 을 새로 만들어야 한다고 봤다.
Table of contents
Open Table of contents
배경 — 미구현이라는 전제
작업 중에 만기 정산은 일정산 과정에서 처리되는 것 아니냐는 지적이 들어왔다. 그 문장이 내 전제를 검증 대상으로 만들었다.
없다는 판단은 어디서 왔는지 돌아보니 증상에서 추측한 것이었다. 재스테이킹 건이 정산되지 않는다는 사실만 있었고 자동화가 없다는 것은 확인한 적이 없었다.
검증 — 검색 몇 초에 나온 배치
두 가지 방법이 있었다. 전제대로 새 배치를 설계부터 시작하는 것과, grep -rn 'MATURED' src/ 로 코드부터 한 번 검색해 보는 것이다. 뒤쪽을 골랐다. 이유는 검색은 몇 초이고 설계는 며칠이라서다. 대신 검색어가 틀리면 없다고 잘못 결론 낼 수 있는 것을 감수했고 그래서 키워드를 셋으로 늘렸다.
StakingSettleJob 이 바로 나왔고 @Scheduled(cron = "0 10 0 * * *") 로 매일 돌고 있었다. 미구현이 아니라 이미 있고 실행되고 있었다. 만들기 전에 몇 초짜리 검색을 한 번 돌리는 것으로 중복 구현을 피했다.
판단 기준 — 없다와 안 된다는 다르다
그러면 왜 우리 건은 처리가 안 되는지가 다음 물음이 된다. 대상 조회 조건을 보니 status = 'MATURED' 에 재스테이킹이 포함돼 있고 parent_stake_id IS NULL 이어야 한다는 조건이 하나 더 있었다.
재스테이킹으로 생긴 건이 parent_stake_id 에 값을 갖는다면 대상에서 빠진다. 없다면 만들어야 하고 안 된다면 조건을 보면 되는데 증상은 둘 다 처리가 안 됨으로 같게 보인다.
조건이 배제하는지의 실측
그 조건이 실제로 배제하는지는 stakes 를 조회해야 확정된다. 배제하는 것이 맞으면 WHERE 한 줄을 고치는 작은 작업이고 아니면 다른 원인을 찾아 범위를 다시 잡아야 한다.
구현 범위가 완전히 달라지므로 이 확정 없이 착수하면 큰 기능을 만들다가 조건 한 줄이었다는 것을 알게 된다. 그래서 배치가 존재하고 돈다는 것은 확정으로 적고 그 조건이 배제하는지는 미검증으로 나눠 적었다.
전제를 의심하게 한 지적
이 검증의 계기는 밖에서 들어온 한 문장이었다. 전제는 전제이기 때문에 스스로 의심하기가 어렵다.
앞서 De-Fi 어댑터 조사에서는 정말 미착수인 경우도 있었고 여기서는 이미 있는 경우였다. 둘 다 코드가 없어 보인다에서 시작했으므로 확인하기 전에는 어느 쪽인지 알 수 없다.
정리
- 미구현이라는 전제를 먼저 검증한다
- 없다는 판단이 증상에서 추측한 것일 수 있다
grep검색은 몇 초이므로 만들기 전에 찾는다- 있으면
WHERE조건을 보고 왜 안 걸리는지 확인한다 - 없다와 안 된다는 증상이 같고 대응이 다르다
- 배제 여부를 실측으로 확정한 뒤 구현 범위를 정한다
- 확정한 것과 가설을 나눠 적는다
- 전제는 스스로 의심하기 어려우므로 지적을 계기로 쓴다