같은 자원인데 경로마다 규칙이 달랐다

랭킹을 보여 주는 화면이 메인 요약과 랭킹 목록 두 곳이었는데 요약에는 나오고 목록에는 안 나오는 사용자가 있었다.

Open Table of contents

부르는 주소가 달랐다

두 화면이 서로 다른 주소를 부르고 있었다. Spring 컨트롤러도 각각이었고 그 아래 iBatis 쿼리도 따로였다.

top()   → 점수 상위 5명, 조건 없음
list()  → 점수 순, 탈퇴하지 않은 사용자만

한쪽 SQL 에만 탈퇴 조건이 있었다. 탈퇴한 사용자가 상위에 있으면 요약에는 나오고 목록에는 안 나온다. 같은 것을 주는 경로가 둘이면 규칙도 둘이 된다.

처음부터 둘이었던 것은 아니다. 메인 요약이 나중에 붙었고 그때 기존 목록 쪽을 안 쓰고 새로 만들었다.

이유는 있었다. 목록 쪽은 페이지 정보와 전체 개수를 같이 돌려주는데 요약에는 그것이 필요 없다. 다섯 개만 필요한데 COUNT(*) 가 같이 돈다. 필요 없는 것을 안 하려고 새로 만들었고 그것이 규칙을 둘로 만들었다.

조건을 맞추는 것만으로는 부족했다. 다음에 조건이 하나 더 생기면 또 두 곳을 고쳐야 한다.

iBatis 쪽을 하나로 모으고 응답 형태만 나눴다. 조건과 정렬은 공통이고 COUNT(*) 를 부르는지만 다르다. 성능 이유도 살리고 규칙도 하나가 됐다.

같은 자원을 주는 경로가 여럿인 곳을 찾아봤다. 사용자의 아이템을 주는 경로가 셋이었고 각각 전부와 장착한 것과 판매 가능한 것을 준다.

이건 의도된 차이였다. 다만 판매 가능의 정의가 한쪽 SQL 에만 있었다. 그 정의를 공통 자리로 옮겼고 나중에 판매 불가 조건이 하나 늘었을 때 한 곳만 고쳤다.

JSON 응답의 필드 이름도 세 경로가 조금씩 달라 앱이 각각 다르게 읽고 있었다. 하나로 맞추면서 옛 이름도 당분간 같이 내보냈다. 앱이 업데이트되기 전에는 옛 이름을 읽기 때문이다. 판올림이 충분히 퍼진 뒤에 옛 이름을 뺐다.