얼쑤의 성장 화면에서는 음정, 박자, 길이 점수가 처음보다 어떻게 바뀌었는지 보여줍니다. 같은 곡을 느리게 분 연주와 빠르게 분 연주, 혹은 같은 녹음을 서로 다른 기준으로 채점한 점수를 나란히 두면 점수는 달라질 수 있습니다. 비교에 넣을 연주를 정하는 일이 점수를 빼는 계산보다 먼저였습니다.
최근 전체 곡 연주가 비교 기준
먼저 채점이 끝나 평가가 있는 전체 곡 연주 중 가장 최근 것을 고릅니다. 그 연주와 곡, 악보 버전, 채점 모델 버전, BPM과 BPM 단위가 같은 연주만 비교 대상으로 둡니다. BPM 단위도 같은 이유는 숫자가 같아도 어떤 박을 기준으로 세느냐에 따라 실제 빠르기가 달라지기 때문입니다. 중간부터 끝까지 분 연습 구간은 마지막 음에 도달했어도 전체 곡 연주에서 뺐습니다.
비교 대상 중 가장 오래된 연주와 최근 연주의 점수를 각각 반환했습니다. 시각이 같은 행은 ID로 순서를 정했습니다. 조건에 맞는 기록이 최근 연주 한 건뿐이면 비교값을 비워 둡니다. 선택한 날짜 범위는 기간 요약에 적용하고, 연주 점수 비교와 곡별 최고점은 회원의 전체 기록에서 계산했습니다. 곡별 최고점은 다른 질문에 답합니다. 그 목록에서는 전체 곡 연주 중 실제로 받은 최고점을 보여주므로 모델과 BPM을 같은 기준으로 묶지 않았습니다.
곡별 최고점 목록은 곡마다 행을 하나로 묶습니다. MAX(total_score)로 표시할 점수를 구하고, 목록의 순서는 가장 최근 연습 시각인 MAX(started_at)을 기준으로 정했습니다. 시각이 같으면 곡 ID를 두 번째 정렬 키로 사용합니다. 최고점을 기록한 날짜와 목록에서 곡이 앞에 오는 기준은 서로 다릅니다.
조건이 다른 연주가 빠지는지 검증
실제 HTTP와 MySQL을 연결한 검사에는 BPM, BPM 단위, 악보 버전, 채점 모델을 각각 바꾼 과거 연주를 넣었습니다. 네 조건 중 하나라도 다르면 항목별 성장의 첫 연주로 선택되지 않았습니다. 완료 상태와 전체 곡 범위도 따로 검사했습니다. 두 SQL 조건을 각각 확인하기 위해 추가한 테스트 데이터는 별도 글에 정리했습니다. SQL 조건을 빼도 테스트가 통과한 이유
곡별 목록에서는 SQL의 정렬을 바꾼 변형이 통합 검사를 통과하지 못했습니다. 점수가 맞더라도 계약에 어긋난 순서로 반환하면 검사에서 발견할 수 있었습니다.
당시 전체 곡을 확인할 때는 현재 곡의 음표 수를 사용했습니다. 악보 개정으로 음표 수가 달라지면 이전에 전체 곡을 불었던 기록도 여기서 빠질 수 있습니다. 이 검증이 확인한 것은 정해진 조건에 따라 비교 대상을 고르는 일입니다. 점수 변화에서 연습 효과를 따로 추정하지는 않았습니다.

댓글
댓글과 반응은 GitHub 계정으로 로그인해 남길 수 있어요.