18. 플러터 버전 업데이트 / DB 구조 수정 / 테스트 코드 추가

말출을 나오면서 컴퓨터를 하나 새로 장만했다.

60만원대 정도로 적당히 샀는데, 게임도 잘 돌아가고 개발 환경도 아주 좋아졌다ㅎㅎ

 

밖에서 개발하는 김에 오랜만에 입대직전까지 진행했던 이 프로젝트를 이어서 해보려고 했다.

아아... 플러터 SDK 버전이 달라서 그런지 스택오버플로우를 검색해가며

Gradle 파일을 수정해봤는데 뭔가 문제가 있는 듯 하다.

이전에 개발하면서 사용했던 라이브러리 일부도 deprecated 되면서 사용을 권장하지 않게 되었다.

2년동안 방치했더니 그동안 너무 많은 것이 바뀌어버렸다.

 

이걸 하나하나 수정을 하기에는 힘들어 보이기도 하고,

이 프로젝트를 너무 오랫동안 방치한 탓에 나도 이 프로젝트의 코드 구조를 까먹어 버린 상태라

이왕 이렇게 된 거 다시 구조도 복기할 겸 코드를 새 플러터 프로젝트에 옮겨 보기로 했다.

 

지금까지 작성한 코드 양이 꽤 많았던지라 기본적인 레이아웃을 옮기는데 3일 정도 걸렸다.

DB 연동, 로그인, 등등은 다시 구현을 해야하고

제일 중요한 코드 에디팅 기능도 아직 만들다 말았다.

 

그러다 이전에 작성한 코드를 보면서 문득 든 생각

데이터베이스에 코드(Chord) 데이터를 저장하는데 너무 불필요한 공간을 많이 차지하는 것 같다.

 

지금 Chord 정보를 저장하는 클래스에는

이렇게 코드 정보를 저장하고 있는데, 데이터베이스에서도 이 정보를 같은 형태로 저장하고 있다.

 

그런데 보통 자주 사용하는 코드는

C, G, F 처럼 root 데이터만 저장되는 코드

C/E , F/A 처럼 root, base 데이터만 저장되는 코드

Dm7, Am, 처럼 마이너나 세븐만 저장되는 코드

 

이런식으로 단순한 코드가 정말 많이 저장된다.

그런데 데이터베이스에는 저 수많은 데이터들이 없는 건 없다고 -1 로도 저장을 하고 있는 것이다.

 

그래서 이걸 어떻게 해결할까 생각하다가 단순 무식하게 그냥 문자열로 저장하자고 생각해버렸다.

하지만 이렇게 저장하면 다른 문제가 생긴다.

 

내가 저렇게 Chord 클래스를 쓴 이유는

코드를 입력하고 수정하는 Chord Keyboard 에서 저 세분화된 데이터를 모두 다루기 때문이다.

하지만 문자열로 데이터를 저장하면 이제는 DB에서 가져온 문자열을 저 데이터로 모두 변환해야만 한다.

 

그래서 오늘 한 작업은 문자열로부터 Chord 를 파싱해서 데이터를 추출하고 Chord 객체를 만드는 것이다.

그래서 요렇게 팩토리 생성자를 하나 만들어주고

Switch 문과 엄청난 if - else 반복 노가다로 코드 문자열을 파싱해서 Chord 객체를 생성하도록 했다.

그런데 이렇게 코드가 복잡해진다면 분명 문제가 생길 가능성이 크다.

그래서 그 동안 많이 들어봤지만 귀찮아서, 몰라서 안해왔던 테스트 코드 작성을 한번 해보기로 했다.

원래 Chord Class 에는 해당 코드 정보로부터 Chord String 으로 변환하는 기능이 있었는데

오늘 내가 추가한 건 Chord String 으로부터 Chord 객체를 만드는 것이었다.

그럼 테스트는 간단하게 String -> Chord -> String 을 해서 그 결과가 같은지 비교하면 되지 않을까?

 

다행히 이렇게 적은 수의 테스트케이스 만으로도 중요한 오류를 디버깅할 수 있었다.

이제는 (겨우 12개지만) 모두 통과된다.

테스트 케이스를 만들어서 넣는 것도 일인 것 같다.

 

커밋 메세지에도 처음으로 테스트 코드 작성했다고 뿌듯하게 작성해봤다 ㅎㅎㅎ

 

근데 다른 사람들이 자주 쓰는 커밋 메세지 컨벤션을 보니까 테스트 코드는 커밋을 따로 빼네...

다음부터는 테스트 코드 커밋을 분리해서 커밋해야겠다