프로젝트(나모)의 팀 블로그에서 작성한 내용을 가지고 왔습니다.
🔗 원본 링크: https://namo-log.vercel.app/pm-blog
안녕하세요, 돌아온 나모의 안드로이드 개발자 코코아입니다.
현재 3기 나모의 Android 개발은 저와 짱구 둘이서 진행하고 있습니다.
도메인이 바뀐 것을 적용하면서 기존 코드들을 리팩토링하며 재출시하는 것이 현재의 목표입니다.
오늘은 나모 Android 팀에서 리팩토링을 하면서 어떤 부분들을 수정하고 있는지에 대해 적어 보려고 하는데요,
리팩토링 관련해서 나누었던 이야기들에 대해서도 함께 다루려고 합니다!
1. 서로의 코드 리뷰하기
저는 1기부터 안드로이드 개발에 참여하고 있었고, 짱구는 올해 초에 새로 들어왔습니다. 당연히 나모의 코드를 처음 본 짱구가 프로젝트 코드를 보면서 ‘이거 왜 이렇게 했지?’라고 의문을 가지는 부분이 많았는데, 기존에는 출시가 급해서 상호 코드 리뷰 문화를 두지 않았었고, 그래서 저 또한 기존 코드에 대해 알지 못했습니다.
그래서 이번에 짱구와 리팩토링을 시작할 때 ‘서로의 코드를 리뷰한 후, 반드시 pr 머지는 상대방이 진행한다’라는 규칙을 세웠습니다.
짱구와 나눈 pr 리뷰
이를 통해 pr 리뷰 과정에서 서로의 코드를 세세하게 살펴보고, 피드백하면서 더 나은 코드를 만들어 나갈 수 있었습니다.
2. 클린 아키텍처 적용
아키텍처 관련한 부분은 짱구와 둘이 의견을 얘기하면서 진행하고 있습니다.
이건 이미 이전에 짱구가 한 번 포스트로 적은 내용이라, 자세한 설명은 넘어가도록 하겠습니다.
한 번에 완벽하게 하기보다는, 이번에는 우선적으로 클린 아키텍처 + MVVM 구조를 적용하고, 나머지 작업은 차츰 진행하고자 합니다.
클린 아키텍처의 경우에도 아직 뷰에 ui가 아닌 로직들이 들어있는 부분도 있고, 개선할 사항이 많습니다!
완벽하게 적용된 게 아니기 때문에 이 부분도 리팩토링을 진행하며 꾸준히 개선해 나갈 예정입니다.
다음번의 리팩토링 작업은 클린 아키텍처 보충 및 DataBinding과 DataStore 사용이 될 것 같습니다.
3. 코딩 규칙 맞추기
이번 리팩토링 과정에서 많은 공을 들이고 있는 부분입니다.
이번에 리팩토링을 진행하면서 프로젝트 전반적인 코드를 살펴보면서 바꿔야 할 부분을 많이 발견했습니다.
1번의 ‘코드 리뷰’ 과정을 통해서도 수정할 부분을 많이 찾았는데요, 명명 규칙이 서로 다르다든가, deprecate 된 코드를 사용하고 있다든가 하는 부분이 매우 많았습니다.
특정 기능과 화면은 각자 맡아서 작업하지만, 이런 프로젝트 전반적으로 바뀌어야 할 부분은
디스코드에서 상의 후 노션 리팩토링 보드에 따로 적어두고, 날을 잡아 같이 해결하는 식으로 진행했습니다.
저희는 각자 작업하던 부분이 끝나갈 때쯤 ‘0요일에 공사할까?’ 식으로 공사 날짜를 잡아서,
노션에 정리해 두었던 리팩토링 TODO 페이지를 참고하면서 이슈를 파서 작업합니다.
현재까지는 2번의 대규모 공사가 있었습니다.
지금부터 각각의 공사에서 어떤 부분들을 바꾸었고, 어떤 이야기들을 나눴는지를 설명드리겠습니다.
🛠️ 1차 대규모 공사 - 룸디비 갈아엎기
첫 번째 대규모 공사는 룸디비에 대한 공사였습니다.
짱구와 제가 그때 작업하고 있던 부분이 룸디비와 서버 통신을 모두 사용하고 있던 부분(일정, 기록)이라서,
만장일치로 가장 먼저 갈아엎을 작업이 룸디비로 결정되었습니다.
이전에는 룸디비 테이블명이 CategoryTable, diary_table 식으로 카멜과 스네이크 케이스가 혼동되어서 사용하고 있었기에, 이에 대해 일괄적으로 스네이크 케이스를 적용하는 등 룸디비에 대한 코드에 일관성을 두고자 했습니다.
앱 내에 저장되는 일정, 기록, 카테고리에 대해 Schedule, Diary, Category 엔티티의 스타일을 모두 맞춰주었습니다.
또한, 나모에서는 로컬과 서버의 데이터를 동기화하기 위해 룸디비에 state와 isUpload 필드를 두고 있었기에,
이에 대해서도 스타일을 맞출 필요성을 느끼고 있습니다. 그동안 하드코딩 되어있는 부분이나 룸디비를 봐도 어떤 값이 들어있는지 확인하기 어려웠거든요.
예를 들어, state에는 DEFAULT, ADDED, EDITED, DELETED 이 4가지가 있었는데
이들이 strings.xml 파일에 저장된 값이라, 룸디비에는 int 타입으로 들어가고 있었습니다.
해당 데이터가 어떤 상태인지, 서버에 잘 올라간 것인지 확인해 보기가 힘들었습니다.
그래서 상태를 strings.xml 파일에 저장해두지 말고 enum class로 상태를 String 그대로 관리하자는 의견이 나왔고,
결론적으로 작성된 코드가 위의 사진입니다.
룸디비 작업의 일환으로 앱 내에서 가장 많이 쓰이는 카테고리에 대한 리팩토링도 진행하게 되어서, 관련 포스트도 첨부합니다.
이 과정을 통해 그동안 규칙이 없이 쓰여 불편했던 룸디비의 코드를 깔끔하게 정리할 수 있었습니다.
🛠️ 2차 대규모 공사 - 패키지 구조와 파일명 갈아엎기
이 작업도 코딩 규칙을 맞추는 일환으로 진행되었습니다.
나모의 현재 ui 폴더에는 크게 schedule, diary, group, custom으로 나눠집니다.
이는, 아래의 바텀네비게이션을 기준으로 폴더를 나눈 것이었습니다.
문제가 생기는 부분은 기획, 디자인과 관련되었다고도 할 수 있는데요,
나모는 기본적으로 일정이 개인캘린더에서 쓰는 모임 일정과 그룹캘린더에서 쓰는 모임 일정으로 나누어지고,
기록의 경우에도 개인의 모임 기록과 그룹의 모임 기록이 있습니다. (조금 복잡하죠?)
이해를 돕기 위해 개인과 그룹의 모임 기록 화면을 가져왔습니다.
그룹에서 모임 일정을 잡고, 모임 일정에 대한 기록(우측 사진)을 추가하고 나면,
참석자들 개개인의 모임 기록(좌측 사진)에 추가되는 구조입니다.
이와 관련해 일정과 기록이 서로 다른 제스처를 취하고 있는 것을 발견했습니다.
일정은 개인에서 쓰는 일정은 schedule 폴더 안에, 그룹에서 쓰이는 일정은 group 폴더 안에 들어갔습니다.
그런데 기록은 group 폴더 안에 기록과 관련된 파일이 있는 게 아니라, diary 폴더 안에 personalDiary, moimDiary로 폴더가 한 번 더 나뉘었습니다.
짱구 이전에 기록 쪽을 맡았던 개발자분이 작업해 주신 부분이었는데요,
diary는 개인 기록 + 개인의 모임 기록을, group 안에는 그룹의 모임 기록을 담기로 결정했답니다.
바텀네비게이션을 기준으로 해당 화면이 어디에 속하느냐를 기준으로 잡고 분류했습니다.
그편이 나중에 유지보수할 때 더 편하겠다, 라는 생각으로 내린 결정이었습니다.
마치며
이처럼 나모 Android 팀에서는 리팩토링을 진행하면서 ‘코딩 컨벤션’을 직접 정의해 나가고 있습니다.
또한, 유지보수의 측면에서도 많이 생각하고 있는데요,
어떻게 해야 나중에 구조를 한 번에 바꾸기 수월할까, 하는 그런 부분들에 대해 고민하고 하나씩 바꿔나가는 중입니다.
그동안 맡은 작업만 진행했었기 때문에 규칙의 필요성을 몸소 느낄 경우는 없었는데,
이번에 제가 진행하지 않았던 다른 기능을 맡아서 작업하고, pr 리뷰를 하는 과정을 통해
코딩 컨벤션을 처음부터 세워놓아야 할 필요성을 절실히 깨닫게 되었습니다.
(그런 의미로 다음번에는 나모 Android 팀이 세운 코딩 컨벤션에 대한 콘텐츠를 들고 오겠습니다.)
그렇지만 코드를 점차 나은 형태로 만들어 나가는 즐거움 또한 느끼고 있습니다.
그동안 처음으로 진행한 프로젝트라는 이름으로 코드를 많이 방치했었는데, 리팩토링 과정에서 점점 깔끔해지는 코드를 보고 ‘이런 게 리팩토링이구나!’라는 생각이 많이 들었답니다.
그럼, 앞으로도 더 발전할 나모 Android 팀의 코드와 리팩토링 도전기를 응원해 주세요😁
감사합니다.
