있다는 것이 맞다는 것은 아니다

변환 결과가 제대로 만들어졌는지 점검하는 도구를 만들어 돌렸더니 대부분 정상이었다. 그런데 점검을 통과한 항목인데 화면에서 비율이 깨져 보였다.

Open Table of contents

이름만 확인하던 점검

파일을 열어 보니 기대하는 이름의 파일은 있는데 치수가 지금 규칙과 달랐다. 옛 규칙으로 만들어진 것이었고 규칙이 바뀐 뒤에도 그대로 남아 있었다.

점검 코드는 기대하는 이름이 목록에 있는지만 보고 있었다. 그 파일이 지금 규격에 맞는지는 확인하지 않았다.

이름이 있으면 통과이므로 내용이 틀린 것은 검사 자체를 지나간다. 점검이 통과했다는 사실이 결과가 맞다는 근거가 되지 못했다.

있다는 것과 맞다는 것을 같은 검사로 다루면 틀린 것이 정상으로 집계된다. 무엇을 검사하고 있었는지를 다시 정의해야 했다.

제대로 만들어졌는가를 존재와 규격과 내용과 최신 넷으로 나눴다. 원래 검사는 첫째만 하고 있었다.

파일 헤더에서 치수를 읽어 규칙과 대조하는 검사를 추가하고 원본 수정 시각이 변환본보다 나중이면 낡은 것으로 보는 검사도 넣었다. 내용 일치는 비용이 커서 이번에는 넣지 않고 그 판단을 기록에 남겼다.

규격을 검사하려면 규칙이 무엇인지 알아야 하는데 그것이 변환 코드 안에만 있었다. 짧은 축의 길이에 따라 세 구간으로 갈리는 규칙을 읽어서 정리했다.

같은 규칙을 변환하는 쪽과 점검하는 쪽이 모두 알아야 하므로 원래는 한 곳에 두고 공유하는 것이 맞다. 당장은 양쪽에 두되 주석으로 연결해 어느 한쪽만 바뀌는 것을 막았다.

이 김에 도구 전체를 코드와 대조하니 의도와 다른 것이 몇 개 나왔다. 처리 순서가 설계와 다르지만 의존 관계가 충족되어 결과가 같은 것도 있었다.

그것은 결함이 아니라 기능이 같은 차이로 판정하고 기록만 남겼다. 반대로 호출부가 하나도 없는 폴백 경로도 찾았는데 있는 것처럼 보이는 코드가 읽는 사람을 안심시키므로 미구현으로 명시했다.