과정 소개 이미지가 비어 있는 상태로 그룹 교육 포털에 게시된 건이 있었다. 이미지가 아직 준비되기 전에 publish_course() 가 나갔을 것이라는 후보가 하나 있었다.
Table of contents
Open Table of contents
증상 — 빈 채로 나간 이미지
이런 종류의 문제는 준비가 끝날 때까지 전송을 미루는 장치를 넣어서 막는다. 그것을 새로 만들어야 하는 줄 알고 어디에 넣을지를 보고 있었다.
만들기 전에 비슷한 것이 이미 있는지 grep -rn "hold\|ready" local/dlp/ 로 찾아봤는데 문제의 어휘로 검색했다. 보류(hold)라는 말과 준비(ready)라는 말로 grep 해 보니 hold_until_ready() 라는 자리가 나왔다.
이미 있던 보호 장치
찾은 hold_until_ready() 를 읽어 보니 정확히 그 일을 하는 장치였고 image_ready 가 아니면 publish 를 보류했다가 cron 이 나중에 만드는 구조였다. 새로 설계할 필요 없이 이미 검증된 것이 있었다.
거기 달린 주석에 왜 그렇게 하는지가 적혀 있었고 그것이 지금 겪는 문제와 같은 상황을 가리키고 있었다. 변수 이름만 봤으면 같은 문제라는 것을 못 알아봤을 것이다.
원인 — 배선이 한 경로에만 있었다
그런데 grep -rn "hold_until_ready" 로 그 장치를 부르는 자리를 세어 보니 course_import.php 한 경로뿐이었고 우리가 문제를 겪은 경로에는 안 걸려 있었다. 장치가 없는 것이 아니라 배선이 안 된 것이었다.
그러면 같은 문제가 그 경로에만 남아 있는 것이 설명된다. 왜 어떤 건은 괜찮고 어떤 건은 비어서 나갔는지도 이것으로 갈렸다.
조치 — 새로 만들지 않고 이어 붙이기
새 장치를 만드는 것 대신 있는 hold_until_ready() 를 course_edit.php 경로에도 이어 붙이는 쪽을 골랐다. 이유는 작업량이 크게 줄고 이미 돌고 있는 방식이라 위험도 낮아서다.
두 경로가 같은 방식을 쓰게 되니 나중에 그 방식을 고칠 때 한 곳만 고치면 된다. 각각 다른 장치를 두었으면 그때마다 두 번씩 고쳐야 했을 것이다.
주석이 알려 준 것
이 건에서 결정적이었던 것은 그 장치에 달려 있던 주석이었다. 무엇을 하는지가 아니라 왜 그렇게 하는지가 적혀 있어서 같은 문제라는 것을 알아볼 수 있었다.
그래서 내가 붙인 쪽에도 같은 성격의 주석을 남겼다. 새로 만들기 전에 문제의 어휘로 먼저 찾아보는 것을 순서로 삼은 것도 이 건에서 나왔다.
정리
- 막는 장치가 이미 있을 수 있다
- 새로 만들기 전에 문제의 어휘로
grep한다 - 있어도 한 경로에만 배선돼 있을 수 있다
- 그러면 같은 문제가 다른 경로에 남는다
- 수정이 새 장치가 아니라 기존 것의 확장이 된다
- 두 경로가 같은 방식이면 나중에 한 곳만 고친다
- 왜 그렇게 하는지 적힌 주석이 같은 문제임을 알려 준다
- 변수 이름만으로는 왜 그런지 모른다