더 낫다고 바꿀 이유가 되지는 않았다

쓰던 것보다 나은 파서를 찾아서 바꾸자고 했다가 안 바꿨다.

Open Table of contents

무엇이 나은지 정리했다
얼마나 걸리는지 세어 봤다
안 하기로 하고 적어 뒀다
준비만 해 둔 것
정리

무엇이 나은지 정리했다

그때 쓰던 것은 엔진이 데리고 온 libxml2 였다. CCFileUtils 가 plist 를 읽을 때 CCSAXParser 가 SAX 로 훑는 구조다.

새로 본 것과 항목별로 비교했다. APK 에 붙는 크기와 읽는 속도와 쓰는 방법과 문서가 전부 새 것이 나았다. 전부 나으니 바꾸는 것이 당연해 보였다. 그때는 비교표에 얻는 것만 있고 드는 것이 없었다.

얼마나 걸리는지 세어 봤다

얼마나 걸리느냐는 물음에 답을 못 해서 그 자리에서 세어 봤다. 쓰는 파일이 다섯이었는데 getInt() 를 부르는 방식이 파일마다 달랐다.

OldParser p; p.parse(str); int v = p.getInt("key");
OldParser::quickInt(str, "key", 0);

바꾸는 데 사흘쯤 걸린다는 계산이 나왔다. 얻는 것도 숫자로 봤다. 읽는 시간이 18밀리초에서 11밀리초가 되고 크기가 60킬로바이트 줄어든다. 그것도 켤 때 한 번 일어나는 일이다.

사흘을 써서 7밀리초를 줄이는 셈이었다. 그 사흘로 할 다른 것이 있었다.

안 하기로 하고 적어 뒀다

지금 안 한다는 것과 영영 안 한다는 것은 다르다. 잰 숫자와 판단과 다시 볼 조건을 같이 적었다.

새 것이 11ms / 120KB, 지금 것이 18ms / 180KB. 교체 비용 약 3일.
지금은 안 한다. 차이가 켤 때 7ms 뿐이다.

다시 볼 조건
  - 파싱이 게임 중에도 필요해질 때
  - 지금 것에서 못 다루는 형식이 나올 때
  - 사용처를 정리할 일이 따로 생길 때

언제 다시 볼지를 안 적으면 반년 뒤에 같은 이야기를 처음부터 한다.

준비만 해 둔 것

바꾸는 것과 별개로 호출 방식이 제각각인 것은 지금도 문제였다. DataParser 라는 자리를 하나 두고 안쪽에서는 여전히 옛 것을 부르게 했다.

int DataParser::getInt(const std::string& raw, const char* key, int def) {
    OldParser p;
    if (!p.parse(raw)) return def;
    return p.getInt(key, def);
}

이렇게 두니 나중에 바꿀 때 이 파일 하나만 고치면 된다. 사흘이 반나절이 됐다.

두 달 뒤 서버가 JSON 으로 주기 시작해 libxml2 로는 못 읽게 됐다. 그때가 바꿀 이유가 생긴 시점이었다. 적어 둔 것을 꺼내 반나절에 끝냈다. 미리 안 바꾼 것과 바꿀 준비를 해 둔 것은 다른 이야기다.

그 두 달 동안 그때 바꿨으면 좋았겠다는 생각이 몇 번 들었다. 적어 둔 숫자를 다시 보니 7밀리초가 문제가 된 적이 없었다. 숫자가 없었으면 느낌으로 판단했을 것이다.

정리

더 낫다고 바꿀 이유가 되지는 않는다
비교표에 얻는 것만 있고 드는 것이 없으면 판단이 안 된다
사용처를 세어 본다. 방식이 제각각이면 그만큼 는다
얻는 것을 숫자로 보고 켤 때 한 번인지 계속인지를 가른다
안 하기로 했으면 언제 다시 볼지 같이 적는다
바꾸지 않아도 DataParser 같은 자리로 모으는 것은 지금 할 수 있다
형식이 JSON 으로 바뀌자 그때 바꿀 이유가 생겼다
적어 둔 숫자가 있으면 나중에 느낌으로 판단하지 않는다