코드 개선에 앞서 디자인을 준비하고 문제가 무엇인지 알아보았다.

디자인은 다음과 같이 했다. 그런데 이 모든 걸 한 번에 업데이트에서 진행하기에는 기간이 오래 걸리므로 일부 기능을 차후 업데이트로 미루었다. 기본적으로 필요한 것들조차 없는 상황이었기에 필수 요소를 업데이트 요건으로 넣되 앱의 개성 중 중요한 것들을 포함하기로 했다.

Figma에서 작업했고 Components도 만들어서 사용해보고 이것저것 조화롭게 구성하기 위해 노력했다. 아래 그림은 최종적인 목표 상태인 디자인이다. 지금 업데이트를 고려하는 부분에는 없는 요소들도 포함되어있다.

업데이트 전에 먼저 계획을 세우기 위한 첫 단계로서 브랜치로 기존 버전(앱 스토어에 올라간 버전)을 안정 버전 브랜치로 분리하였다. 일종의 배포 버전을 관리하는 기능이 별도로 있었던 것 같아서 이 부분은 찾아보는 중이다.

그리고 깃허브의 기능을 적극 활용하여 마일스톤과 프로젝트 기능을 이용하기로 했다. 아래 사진은 Monthly Piece의 깃허브 프로젝트 페이지 갈무리 사진이다.

전개편 (1) 이후에 첨부한 사진이라 그런지 전개편 (1) 내용을 이유로 적어둔 이슈들이 눈에 보인다. Notion에서 사용하던 방식과 유사해 금새 익숙해졌다. 다만, 레포지토리 이슈 템플릿에 마일스톤과 프로젝트에 추가하는 기능이 없어 이슈 생성 후 별도의 작업이 필요하다.

마일스톤으로는 아래 사진과 같이 7월 31일까지 완료하겠다는 의지로 만들어두었다. 이렇게 마감기한과 마일스톤에 이슈를 추가하여 진행도를 확인할 수 있다.

여담

나는 버전 관리 규칙을 내 방식대로 정했다. 버전이 X.Y.Z라고 했을 때, X는 이전 데이터와의 연동에 문제가 발생할 수 있어 앱 사용에 있어 사용자의 백업을 요구할 때, Y는 UI요소가 뷰 간 이동 혹은 삭제되는 경우, Z는 UI 요소의 삭제나 뷰 간 이동이 아닌 단순 추가 혹은 사용자가 알아낼 수 있는 UI 변경이 없는 경우에 숫자가 바뀐다.

예시로 데이터 파일 관리를 효율적으로 하게 바뀌어 사용자는 그냥 체감으로 '이전보다 빨라졌다.'라고 느낀다면 소규모 업데이트인 Z, 지금의 업데이트처럼 UI 요소가 삭제 혹은 뷰 간의 이동을 통해 변경되는 수준이면 Y 업데이트이다.

+a: 지금은 자동화를 했다. 마일스톤과 이슈 관리를 자동화 하는 기능이 있으니 활용하자. 진짜 편하다.