부수효과를 원하는지로 도구를 고른다

상태값이 잘못된 레코드가 여럿 있어서 일괄로 고쳐야 했다. 평소 원칙대로 애플리케이션 계층으로 짰다가 실행 직전에 멈췄다.

Open Table of contents

실행 직전에 본 옵저버

이 모델에는 상태 변경을 감지하는 옵저버가 걸려 있었다. 상태가 바뀌면 연동된 채널마다 전송 작업을 만드는 코드였다.

정정 대상이 수백 건이고 각각 채널이 여럿이니 실행하면 작업이 수천 개 쏟아진다. 정정 자체는 성공하지만 그 작업들이 외부로 나가면서 2차 사고가 된다.

직접 질의로 값을 바꾸면 옵저버가 타지 않으므로 부수효과 없이 값만 바뀐다. 평소에는 애플리케이션 계층을 거치는 것이 원칙이라 이 방식을 피한다.

그런데 이번에는 그 부수효과 자체가 문제였다. 원칙이 막으려던 것과 지금 막아야 하는 것이 반대 방향이었다.

두 경우를 놓고 보니 기준이 하나로 정리됐다. 이 변경의 전파를 원하면 애플리케이션 계층이 맞고 원하지 않으면 직접 질의가 맞다.

정정 스크립트는 대개 후자인데 이미 잘못된 상태를 바로잡는 것이지 그 변경을 외부에 알리려는 것이 아니기 때문이다. 정상 업무 흐름은 전자이므로 같은 갱신이라도 목적에 따라 도구가 반대가 된다.

직접 질의로 가면 옵저버가 하던 일 중 필요한 것도 안 되는데 이 경우 변경 이력 기록이 그랬다. 그래서 옵저버가 쓰는 형식을 그대로 재현해 이력을 손으로 넣었다.

전부 채울 필요는 없고 필요한 것만 채우면 된다. 우회는 부수효과를 통째로 끄는 것이므로 그중 무엇이 필요했는지를 따로 세어야 한다.

절차를 확정하기 전에 각 단계를 코드로 검증하면서 관련 규칙 셋을 같이 확인했다. 특정 플래그가 서면 모든 작업 생성이 차단되므로 나중에 재등록하려면 그 플래그를 먼저 풀어야 한다.

실행 분기가 아예 없는 작업 종류도 있었는데 만들어지기만 하고 아무것도 하지 않는 이력 표시용이었다. 시도 횟수 상한이 셋이라 그보다 큰 값을 세우면 재시도 대상에서 영구히 빠지는데 이것을 모르면 왜 실행이 안 되는지를 엉뚱한 곳에서 찾게 된다.