🎉 Play Store Download (v.1.0.1)
소감
오늘 플레이스토어에 내가 개발에 참여한 앱을 처음으로 릴리즈 해봤다.
가수들이 새 노래를 낼 때 녹음하면서 하도 많이 듣다보니 안 듣고싶다고 하는데 딱 이 느낌이다. 나 역시 몇달에 걸쳐 너무나 많은 빌드를 해왔기 때문에 지쳤다. 당분간 쉬고싶다. 리뷰가 달리면 그제서야 실감이 날 것 같다.
1월부터 쉴 새 없이 개발을 해왔다. 시행착오가 많았고 비효율적으로 작업이 이루어진 부분도 있었다. 5만큼 피곤해도 될 걸 8만큼 피로를 느꼈다.
처음부터 어떠한 task들이 있을 거라고 견적이 잡혔으면 스트레스가 덜했을 텐데 거의 다 왔다고 느꼈는데 계속 이슈가 생겼고 작업이 늘어나면서 피로감이 누적됐다.
힘들었다. 나는 데모데이 때 제 역할을 다 못해냈어서 그것들 보충하고 새 기능까지 추가 개발하느라 더 체감되는 양이 많았던 것 같다.
기억이 날아가기 전에 이번 프로젝트를 회고하려고 한다. 우선 이정도 규모의 프로젝트 릴리즈 경험이 있다는 건 특별하다. 학부생들끼리 모여서 하는 만큼 흐지부지 되기 쉬운데 꺼질듯 아슬했던 불꽃이 죽지 않고 살아남았다. 특히 우리 안드로이드 팀은 타 팀에 비해 인력도 부족했고 시기적으로 둘 다 바빴는데 끝내 해냈다.
어려웠던 것
1) 리사이클러뷰 item 다중삭제 구현
sopt 세미나에서 리사이클러뷰 selection 라이브러리를 알게 됐고 이번 기회에 사용을 해봤다. 처음에는 selection 라이브러리를 활용해서 기능 구현을 했다가 몇가지 이슈가 있어서 안 쓰는 방향으로 리팩토링을 했다. item 삭제 시 인덱스가 밀리는 문제가 발생했다.
가령 인덱스가 [0], [1], [2]인 3개의 data가 있고 [1]을 삭제하면 data가 2개로 줄면서 [2]이 새로운 [1]이 돼야 하는데 이게 갱신이 안 된 형태로 여전히 [2]로 남아있어서 indexOutOfBounds 에러가 떴다.
인덱스 말고 리사이클러뷰 item 고유의 id 값을 기준으로 currentList에서 filter를 해주는 식으로도 코드를 짜봤는데 해결이 안 됐다.
차선으로 selection 라이브러리의 활용을 유지하되 삭제를 할 때마다 어댑터를 매번 초기화하고 서버로부터 data를 새로 받아오는 방법을 선택했다.
그런데 좀 아쉬웠다. 매번 data를 새로 받아와야 하다보니 사용성이나 성능이 떨어질 수밖에 없기 때문이다. "어떻게든 일단 기능 구현은 해냈으니 그냥 이대로 릴리즈할까"라는 생각도 들었는데 결국 타협하지 않고 리팩토링을 했다.
selection 라이브러리를 버린 결정적 이유 중 하나는 내가 라이브러리에 대한 이해가 충분치 않다보니 이슈가 생겼을 때 원인 파악을 명확히 해낼 수 없다는 것이었다.
그렇다고 이 라이브러리를 자세히 공부해보자니 다중삭제 기능 구현에 selection 라이브러리가 필수가 아닌데 너무 큰 리소스 투자라고 느껴졌다. 또 팀원과의 구현 방법도 통일을 해야 서로의 코드를 관리해주기가 수월한데 나 혼자 selection 라이브러리를 활용하는 방향으로 코드를 짜면 팀원이 나중에 내 코드를 봐줄 수가 없다. 이런 이유들로 selection 라이브러리를 버렸다.
팀원과 구현 방법을 통일하면서 기존의 코드를 리팩토링하는 것도 꽤나 고생이었다. 왜냐하면 페이지의 여러 기능들이 selection 라이브러리와 연결이 돼있어서 코드를 다 새로 짜줘야 했기 때문이다.
2) 동기-비동기
어려웠다기보다는 기억에 남아서 적어보려고 한다. 유저가 터치로 코스 좌표를 다 찍고 '완성하기' 버튼을 누르면 네이버맵sdk에 들어있는 takeSnapshot 메서드를 통해 화면을 캡쳐하고 캡쳐한 이미지와 유저가 찍은 좌표를 서버로 보내야 했다.
중요한 것은 post 함수에 RequestBody로 넣을 data들의 세팅이 먼저 이루어진 후에 서버에 request를 보내는 것이었다. 그런데 계속 data가 가공 및 세팅이 되기도 전에 서버에 request를 보내는 함수가 실행이 됐다.
분명 코드는 위에 적은 것부터 순차적으로 실행이 되는 것으로 알고 있는데 당황스러웠다. 내가 모르는 개념이 있는 건가 혼란스러웠고 일단은 핸들러의 postDelayed 메서드를 통해 인위적으로 서버에 request 보내는 함수 실행을 늦췄다.
그래서 기능이 동작하게는 해놨는데 찝찝했다. 0.3초의 delay를 주었지만 이는 기기나 네트워크 환경에 따라 충분하지 못할 수 있기 때문이다. 또는 더 빠르게 동작시킬 수 있는데 무조건적으로 0.3초를 delay 시켜야 한다는 것도 문제가 된다고 느꼈다.
팀원에게 물어봤지만 명확한 답을 얻진 못했고 안드로이드 오픈 채팅방에 질문 글을 올렸다. 그리고 답을 얻었다. 안면도 없는 사이에 코드까지 봐주셔서 너무 감사했다.
createMbr() -> viewModel.uploadCourse() 순으로 실행이 돼야 하는데 createMbr() 안에 들어있는 takeSnapshot가 콜백 함수라 비동기적으로 처리된다는 것이 원인이었다. 그래서 순차적으로 코드를 작성해도 takeSnapshot()이 끝나는데 시간이 걸리니까 viewModel.uploadCourse()가 먼저 실행이 되는 것이었다.
takeSnapshot이 콜백함수라는 걸 인지 못했었다. 다음번에는 코드를 순차적으로 적는 것뿐만 아니라 동기/비동기적으로 동작하는 함수인지까지 확인을 하고 코드를 짤 것이다.
좌측의 코드가 리팩토링 전이고 우측의 코드는 원인을 파악한 후 고친 코드이다.
3) 효율적인 작업
데모데이 버전에서 많은 것들이 추가되진 않았다. 그런데 왜 이렇게 예상보다 시간이 오래 걸렸는지, 더 효율적으로 작업할 순 없었을지 생각을 해보고 있다.
3-1) 너무 잦은 UI 수정
어렵다기보단 경험이 부족했던 탓이다. 디자인 파트와 충분한 얘기를 나눈 후에 작업을 시작했어야 했는데 당시에는 그래야 하는지 몰라서 못 그랬다. UI를 다 짜놨는데 후에 여러 디바이스에서 테스트를 해보는 과정에서 반응형 처리가 잘 안 돼있다는 걸 알고는 전체적으로 수정 작업을 한 번씩 다 거쳐야 했고 이 과정에서도 시행착오가 있어 시간 소모가 꽤 컸다. 다음번에는 어떻게 대응을 해야 할지 방향이 잡혔기 때문에 이번처럼 리소스 낭비는 없을 것이다.
3-2) 비효율적인 리팩토링
개발을 하면서 조금씩 리팩토링을 했었다. 일단 짜놓고 나중에 리팩토링을 하잔 생각이었고 실제로 그렇게 했다. 그런데 몇달동안 "이정도는 그냥 시작이 조금 늦어지더라도 처음에 설계를 잘하고 코드를 짰으면 더 빨랐겠는데" 이런 생각이 계속 들었다. 단기적으로는 빨라보여도 전체적으로는 시간을 더 잡아먹었단 생각이다.
앞으로의 계획
결코 쉽지는 않았지만 네이버 맵 api, 티맵 api 같은 건 사실 처음이 낯선 것이지 사용법을 익히고 그대로 사용하는 거라 하나의 경험이 늘었을 뿐 내 실력이 성장했다고는 생각 안 한다.
3~4월까지는 괜찮았는데 최근에는 내가 원하는 만큼 충분히 고민하고 코드를 짤 수 있는 여유가 없었다. "어떻게든 구현해내는 것"에만 집중한 경향이 있었다. 서비스를 만들어낸 지금부터가 개선해나가면서 공부해볼 수 있는 기회라고 느낀다.
우선 해보고싶은 건 다른 사람들의 프로젝트 코드를 보면서 어떤 식으로 짰나 나와는 다른 방향에 대한 시야를 트고 싶다.
'Android > 회고' 카테고리의 다른 글
| [회고] Runnect 앱잼 (0) | 2023.01.17 |
|---|