규칙을 넓히지 않았다

버그 하나를 막으려고 확인을 넣었는데 그 확인이 다른 것까지 막았다.

Open Table of contents

무엇을 막으려 했나

아이템을 두 번 쓰는 문제가 있었다. CCMenuItem 을 빨리 두 번 누르면 하나로 두 번 효과가 났다.

CCMenu 의 ccTouchBegan 은 상태가 kCCMenuStateWaiting 일 때만 터치를 받는다. 동시에 두 손가락으로 누르는 것은 그래서 막힌다. 빠르게 연달아 누르는 것은 별개 터치다. 그 사이에 상태가 돌아와 있다.

if (m_busy) return;
m_busy = true;
useItem(m_selected);
m_busy = false;

이걸로 막혔다. 그런데 같은 모양을 다른 화면에도 넣었다. 한 곳에서 통한 방법이니 다른 데도 넣어 두면 안전할 것이라고 봤다.

상점에서 여러 개를 빠르게 사는 것이 원래 되던 것이었는데 그것이 막혔다. 아이템 열 개를 연속으로 사려는데 하나씩만 산다.

한 번에 하나만 처리되는 것이 맞는 자리와 여러 번 눌러도 되는 자리가 다르다. 한 경우를 막으려고 만든 것을 전부에 넣으면 되던 것이 안 된다.

두 자리를 다시 보니 막아야 하는 이유가 달랐다. useItem() 은 같은 아이템을 두 번 쓰면 안 되는 것이고 상점 구매는 같은 상품을 여러 번 사도 되는 것이다.

if (m_selected.count <= 0) return;      // 개수로 막는다
useItem(m_selected);

플래그가 아니라 개수로 막았다. 개수가 0이면 못 쓰는 것이 원래 막고 싶었던 것이었다. 상점에서는 libcurl 로 보낸 요청의 응답을 기다리는 동안만 막았다. 응답이 오면 다시 누를 수 있다.

이름도 바꿨다. m_busy 는 무엇 때문에 바쁜지 모르는데 m_waitingPurchase 는 무엇을 기다리는지 드러난다.

이미 넣어 둔 같은 플래그가 다른 자리에도 있었다.

$ grep -rn "m_busy" --include=*.cpp Classes/

Classes/ 아래에서 셋이 나왔는데 전부 특별한 이유 없이 넣은 것이었다. 랭킹은 새로 고침을 여러 번 눌러도 되고 설정은 더더욱 상관없었다. 하나씩 봐서 필요한 것만 남겼다. 한 번 넣은 것을 빼는 것도 넣는 것만큼 봐야 했다.

이 뒤로 막는 것을 넣기 전에 셋을 물어보게 됐다. 무엇이 문제였는지를 묻는다. 그 문제가 이 자리에도 있는지 묻는다. 막으면 원래 되던 것 중 안 되는 것이 있는지 묻는다. 세 번째를 안 물어서 상점이 막혔다.