속성처럼 쓴 메서드

값을 읽었는데 예상과 다른 것이 나왔고 그런데도 오류는 나지 않았다. 항목이 분명히 다섯 개인데 개수를 읽으면 0이 나오고 있었다.

Open Table of contents

값이 아닌 것을 읽은 이유

개수를 구하는 것이 메서드인데 그것을 속성처럼 접근하고 있었다. 그러면 존재하지 않는 속성이므로 널이 되고 숫자로 쓰이는 자리에서 0이 된다.

괄호를 붙이니 제대로 된 값이 나왔다. 문제는 없는 속성을 읽어도 예외가 안 나고 경고만 난다는 점이었다.

경고 수준 설정을 확인하니 알림과 경고를 둘 다 꺼 두고 있었다. 다시 켜니 문제의 자리가 속성 이름과 함께 바로 출력됐다.

경고를 끄면 이런 것이 조용히 지나가고 오류 대신 틀린 값이 남는다. 개발 환경에서 전부 켜니 경고가 수백 개 나왔고 한 번에 다 고칠 수는 없었다.

전부 한 번에 고치려니 위험한 것과 아닌 것이 섞여서 진도가 나가지 않았다. 그래서 성격에 따라 세 종류로 나눴다.

값이 틀리게 나오는 것과 동작에 영향이 없는 것과 곧 없어질 문법에 대한 경고다. 없는 속성 접근은 값이 틀리게 나오므로 먼저 고쳤고 문법 경고는 판을 올릴 때 같이 하기로 했다. 분류하고 나서 첫 종류만 그 주에 끝냈고 나머지는 목록에 두고 차례로 했다.

운영 환경에서는 다른 조합으로 뒀는데 경고는 켜되 화면에는 안 보이고 로그에만 남게 했다.

끄면 문제를 알 수 없고 화면에 보이면 안쪽 사정이 밖으로 나가기 때문이다. 로그에서 종류별로 세어 보니 한 자리에서만 4천 건 넘게 나는 것이 있었고 그것부터 고쳤다.

로그에서 사후에 보는 것보다 정적 분석으로 미리 잡는 쪽이 훨씬 빨랐다. 같은 것을 실행 전에 잡아 주므로 빌드에 붙여서 새로 들어오는 것까지 막았다.

타입을 명시하니 분석 도구가 더 잘 잡았고 자주 쓰는 것은 메서드로 감싸서 호출하는 쪽에서 괄호를 빠뜨릴 자리를 없앴다. 괄호 없이 쓴 비슷한 실수를 패턴으로 찾으니 열두 곳이 더 나와서 전부 고쳤다.