준비 섹션을 다듬다

하나의 모델이 다섯 가지를 담고 있었다

준비 섹션에는 다섯 카테고리가 있습니다. 재료, 도구, 장소, 인력, 자격. 처음에는 이 다섯 가지를 하나의 PreparationItemModel로 다뤘습니다. 필드를 전부 넣어두고, 카테고리에 따라 쓰는 것만 쓰는 방식이었습니다.

재료에는 수량과 단위가 있고, 장소에는 주소가 있고, 인력에는 전문성이 있습니다. 하지만 모델에는 이 모든 필드가 한데 섞여 있었습니다. 장소 아이템에도 수량 필드가 있고, 재료 아이템에도 주소 필드가 있었습니다. 쓰이지 않을 뿐.

코드를 읽을 때 어떤 필드가 어떤 카테고리에 속하는지 모델만 봐서는 알 수 없었습니다.

분리하기로 했다

MaterialItemModel, ToolItemModel, VenueItemModel, PersonnelItemModel, QualificationItemModel. 각 카테고리가 자기 필드만 갖도록 나눴습니다.

서버의 응답 모델도, 클라이언트의 타입도, 직렬화도 모두 분리했습니다. 공유 베이스 클래스 없이 각각 독립적으로.

처음에는 베이스 클래스를 만들어서 상속하려 했습니다. 공통 필드(order, title, description, link, checked)가 있으니까요. 하지만 생각해보니, 각 모델이 독립적인 게 읽기에 더 명확했습니다. 공통 필드가 반복되더라도.

화면도 분리했다

모델을 나누고 나니, 화면도 하나로 두기 어색했습니다.

create-preparation-item 하나가 카테고리를 파라미터로 받아서 조건부로 필드를 보여주고 있었습니다. browse-preparation-item도 마찬가지. 컴포넌트 안에 다섯 가지 분기가 얽혀 있었습니다.

create-material-item, create-tool-item, create-venue-item, create-personnel-item, create-qualification-item. 각각의 화면은 자기 카테고리의 필드만 보여줍니다. 조건 분기가 사라지고, 각 파일이 단순해졌습니다.

리스트 컴포넌트도 마찬가지입니다. PreparationInput 하나가 다섯 카테고리를 루프 돌던 구조에서, MaterialsInput, ToolsInput 등 다섯 개로 나눴습니다.

파일은 많아졌지만, 각 파일은 짧고 명확해졌습니다.

캐시 버그

분리 작업 중에 버그를 발견했습니다. 수량과 단위가 저장이 안 되는 문제.

서버는 200 OK를 반환하고 있었습니다. MongoDB에도 정상적으로 저장되고 있었습니다. 그런데 앱을 다시 열면 값이 사라졌습니다.

원인은 두 곳이었습니다.

첫째, 서버의 TaskResponseModelFactory에서 준비 아이템을 응답으로 변환할 때 카테고리별 고유 필드(quantity, unit, address, specialty, issuer)를 매핑하지 않고 있었습니다. 서버는 저장했지만, 응답에 포함시키지 않았던 겁니다.

둘째, 클라이언트의 toJSON()에서도 같은 필드들이 빠져 있었습니다. SQLite 캐시에 저장할 때 이 필드들이 누락되어, 캐시에서 읽으면 null이 되었습니다.

서버와 클라이언트, 양쪽 다 같은 실수. 기본 필드(order, title, description, link, checked)만 매핑하고, 나중에 추가된 카테고리별 필드를 빠뜨린 겁니다.

리스트 표시

카테고리별 고유 정보를 리스트에서도 보여주기로 했습니다. 이름 옆에 수량이나 단위를 붙이는 방식입니다.

처음에는 이름과 수량을 이어붙여서 하나의 텍스트로 보여줬습니다. “라면 2개”처럼. 하지만 다른 카테고리와 스타일이 달라서, 이름은 진한 색으로, 부가정보는 연한 색으로 나란히 표시하는 방식으로 통일했습니다.

장소의 주소는 길어질 수 있어서 표시하지 않기로 했습니다. 필요하면 아이템을 열어서 확인하면 됩니다.

돌아보면

공유 모델 하나로 시작하는 건 빠릅니다. 하지만 카테고리마다 다른 필드가 생기면, 그 하나의 모델이 점점 어색해집니다. 어떤 필드가 어디에 쓰이는지 코드를 읽어봐야 알 수 있고, 직렬화에서 빠뜨리기도 쉽습니다.

분리하면 파일은 늘어나지만, 각각이 명확해집니다. 그리고 명확한 코드에서는 버그가 숨을 곳이 줄어듭니다.