한 채널의 재전송 대상 만여 건이 새 옵션 번호를 제대로 받게 하려 했다. 검토한 조치는 옛 option_code 컬럼을 NULL로 비운 뒤 신규 등록을 내는 것이었고 운영 데이터베이스를 건드리는 일이라 정말 필요한지 확인해야 했다.
Table of contents
Open Table of contents
문제 — 좁은 검색의 0건
channels/<이름>/ 디렉터리를 grep -rn으로 검색하니 setOptionCode() 호출이 0건이었다. 여기서 그 채널은 안 쓰니 조치가 불필요하다고 결론을 낼 뻔했다.
멈춘 이유가 둘이었다. 그 채널 디렉터리에 없어도 공통 Dispatcher에서 값을 채워 내려보낼 수 있고 그러면 채널 코드에는 안 보인다.
원인 — 가변 필드가 넓히는 범위
두 번째 이유가 필드 선언이었다. 그 필드가 readonly가 아니라 가변 public으로 선언돼 있었다.
readonly면 생성자만 보면 되는데 가변이면 런타임에 누구든 덮어쓸 수 있으므로 모든 대입 지점을 봐야 한다. 선언 한 글자가 확인해야 할 범위를 결정했다.
검증 — 두 축의 전수 확인
그래서 범위를 저장소 전체로 넓히고 두 축으로 확인했다. 첫째 축은 setOptionCode() 호출부 전수인데 다섯 곳이 나왔고 문제의 채널은 거기 없었다.
둘째 축은 $optionCode = 대입 지점 전수였다. 문제의 채널에서 마켓 등록 응답의 optionNo로 그 필드를 채우는 코드가 나왔고 상류에서 주입받는 것이 아니었다. 호출부 전수는 그 값을 만드는 코드가 어디 있는지를 막고 대입 지점 전수는 그 필드에 무엇이 들어가는지를 막으므로 둘 다 봐야 이 경로에서 그 값이 안 읽힌다고 말할 수 있다.
판단 기준 — 근거가 달라진 같은 결론
결과적으로 1차 결론과 같아서 그 채널은 그것을 안 썼다. 그런데 근거가 달라졌다.
1차 근거는 그 채널 디렉터리에 없다는 것이다. 최종 근거는 저장소 전체에서 setOptionCode() 호출부가 다섯 곳인데 그중에 없으며 그 필드가 등록 응답으로 채워진다는 것이다. 운영 데이터베이스를 안 건드리기로 결정하는 근거는 두 번째뿐이고 첫 번째로 결정했다가 실제로 쓰고 있었으면 만여 건이 잘못 등록됐을 것이다.
결과 — 안 한다는 결론과 진단 순서
두 가지 방법이 있었는데 1차 결론대로 바로 운영 조작을 건너뛰는 것과 두 축을 전부 확인한 뒤 결정하는 것이다. 뒤쪽을 골랐다. 이유는 첫 근거로는 운영 데이터베이스를 안 건드리기로 결정할 수 없어서다. 대신 저장소 전체를 두 번 훑는 시간을 감수했다. 결론은 이 채널에서 option_code를 비우는 것이 무의미하므로 그 목적의 운영 조작은 하지 않는다는 것이었다. 반대로 option_code 관련 조치는 나머지 다섯 채널에서만 효과가 있다는 것도 함께 적었다.
진단 순서도 정했는데 이 채널이 그 계열인지를 먼저 가르고 계열이면 그 컬럼 조치가 유효하며 아니면 다른 원인을 찾는다. 이 분류를 먼저 하지 않으면 안 쓰는 채널에서 그 컬럼을 계속 뒤지게 된다.
앞선 다른 조사에서도 디렉터리 검색으로 결론을 냈다가 지적받은 적이 있어서 같은 실수를 반복한 셈이다. 그래서 channels/ 하위 디렉터리 grep만으로 안 쓴다를 단정하지 않고 두 축으로 확인한다는 규칙으로 못 박았다.
정리
- 좁은 범위 검색의 0건은 여기 없다는 뜻이지 안 쓴다는 뜻이 아니다
- 상류에서 값을 채워 내려보내면 채널 코드에는 안 보인다
- 필드가
readonly가 아니면 모든 대입 지점을 봐야 한다 grep으로 호출부 전수와 대입 지점 전수 두 축을 확인한다- 각 축이 다른 것을 막으므로 하나만 보면 구멍이 남는다
- 결론이 같아도 근거가 다르면 다른 결론이다
- 안 한다도 결론이고 어디서는 효과가 있는지를 같이 적는다
- 분류를 먼저 하지 않으면 엉뚱한 곳을 계속 뒤진다