현재 회사에서 제가 적용하는 아키텍쳐는 MVP와 MVVM을 섞어서 쓰고 있습니다. 소위 네이밍을 MVVM+P라고 지었는데요.
그림을 그리면 아래와 같이 되는데요.
이 그림 한장이 사람들에게 직관적으로 다가오는지 확인하기 위해 우선 reddit에 글을 올려본 후 어떤 설명을 추가할 지 알아본 후 세번째 글을 써야할 것 같습니다.
잘안보이시면 클릭 하셔서 확대해 보세요.
| 안드로이드 기능 개발 프로세스 그리고 MVVM #1 (0) | 2016.09.03 |
|---|---|
| 안드로이드 소프트웨어 아키텍쳐 패턴 해부 #1 (0) | 2016.06.22 |
너무 오랜만에 블로그에 글을 쓰는것 같다.
개인적으로도 여러 일이 있었고 회사에서 여러가지 일이 있어서 복잡 다산한 생활을 보냈다. 우선 회사 사정을 말하는 것은 조금 그렇고 여러 사황에 의해 결과적으로 모바일 팀의 팀장이 되어 버렸다. 갑작스럽게 되어서 무얼 어떻게 해야할지 고민과 번민의 시간을 가졌었다.
어차피 기술리딩, 팀 관리, 프로젝트 관리도 해야할 것 같은데, 그에 대한 보상은 있겠지? 하는 생각이 든다. 어차피 나는 개발만 해도 잘 벌어먹고 잘하는 사람이니까. 앱 스프린트가 시작되고 왠만하면 예외적인 상황을 안 만드려고 여러가지 고민을 하다가 다른 팀과 협업이 최대의 변수라 협업할 사항들을 새벽까지 정리하고 테이블을 만들었었다. 프로그램 작성할 때도 예외를 최소화해야하는데 기능 개발에 대해서 고심에 고심을 해보니깐 동일한 것 같다. 다만 어떤 기능을 개발해야 할 때 어느 정도 걸릴것이다란 일정 산정이 나는 쉽게 되지 않았다. 기획서를 보고 무얼할지 정리하고 협업 사항을 추출하는 과정에서 각각의 일이 얼마나 걸릴지 예측을 할 수 있겠으나 그것도 예측일 뿐 최대한 넉넉히 다음에는 잡아야 겠다.
어차피 자체 서비스인지라 일정을 너무 빡세게 산정하면 나뿐만 아니라 다른 팀원들도 개발할 때 실수를 하게 되고 결국엔 앱의 품질에 문제가 생길 수 밖에 없다. 한 라인의 코드를 짜더라도 고민하고 고민하는 문화를 가지는 팀을 만드는게 목표인지라 그래야 팀원들의 실력, 내 실력도 늘고 앱의 품질도 보장되고 확장성, 유연성, 유지보수 용이한 앱을 만든는데 초석이 되는 문화라고 생각한다. 바쁘고 야근하는 문화에서는 절대 좋은 코드를 양산하고 좋은 엔지니어가 될 수 없다고 생각하기 때문에 최대한 이 부분을 어떻게 지키고 만들어 나갈까 고민하고 있다. 그런데 다른 팀의 팀장과 애기해 보니 나와는 다른 생각을 가지고 있다. 하지만 나는 내 생각엔 변함이 없다.
회사 일에 파뭍혀 지내면서도 자기 계발에 손을 놓지 않아 다행이다. 디자인 패턴에 대해 이해도 및 숙련도를 조금 더 높히려 디자인 패턴 및 SOLID 원리에 대해 다시 리뷰하는 시간을 가졌고, MIT 알고리즘 책도 1300페이지에 달하는데 한번 빠르게 정독하였다. 지금은 재미로 JVM8 스펙을 두번째 보고 있는데 머리에 쏙쏙 이해되어서 꿀잼이다. 회사에 RxJava, Retro Lambda, Method reference, Optional, Stream등을 안드로이드 앱 개발할 때 사용할 수 있도록 환경을 만들어 놓고 나 같은 경우 거의 모든 코드를 위에 열거한 기술로 거의 구현하고 있긴 하다. 그런데 JAVADOC 및 블로그를 보면서 이해도를 높이면서 사용하고는 있는데 함수형 언어에 대한 근본적인 통찰력이 부족하다고 느껴져 JVM8 스펙을 다 읽은 후 함수형 언어에 대한 책 두권을 읽을 예정이다. 아마도 JVM8 스펙하고 함수형 언어 책 두권을 읽으면 2016이 다 지나갈것 같다. 그 다음은 다시 MIT 알고리즘 정복이다. 아마도 2017년에 3번 더 반복 읽기가 가능하겠다.
개발을 하면서 여러 글을 읽게 되고 reddit 게시물도 항상 모니터링 하고 있는데 그놈의 코틀린 애기가 자주 나온다. 코틀린에 대해 세미나를 한번 들었다. 자바보다 모던하고 간결한 건 인정한다. 근데 언어란게 그게 전부가 아니다. 언어가 제공하는 인프라와 이미 포진되어 있는 그 언어에 대한 통찰력이 풍부한 전문가 인력 풀, JVM 스펙 조차 JAVA를 기준으로 되어 있다. 왠만한 메이저 회사는 섣불리 주력 언어를 타 언어로 변경할 가능성이 거의 없다고 단언한다. 자바가 바보같이 뒤쳐지지 않은한 메이저 회사들은 자바를 유지할 것이고 자바 개발자를 뽑을 것이다. 코틀린이든 어떤 언어든 메이저가 되면 그 때 생각해 봐도 늦지 않다. 굳이 비대중적인 언어를 선택해서 어떤 이득이 있는가? 그것보다 기본 베이스를 익히는데 훈련하는데 충실해야할 것이다.
주말이 되어 오랜만에 어떤 글을 써볼까 하다가 이제 새로운 회사에 입사한지 한달이 살짝 넘은 터라 안드로이드 기능 개발 프로세스에 대해서 고민하는 시간을 갖도록 하겠습니다. (사실 저는 개발 방법론이나 개발 프로세스 자체는 관심이 없긴 한데, 아키텍쳐와 밀접하게 연관이 되어 있기 때문에 살펴봤네요ㅎㅎ;;;) 티몬에 재직할 때에는 사실 개발 프로세스에 대해서는 제가 신경쓰지 않아도 기획자 및 PM유닛에서 관리하기 때문에 고민할 필요가 없었지만, 지금 재직하는 회사는 벤처 회사이기도 하고 좀 더 기민하게 개발할 필요가 있다는 느낌적인 느낌이 들어 필히 개발 과정 동안 발생할 수 있는 상황에 대해 유연하게 대응할 수 있는 개발 방식에 대한 고민이 필요해 보였습니다.
기획서가 성숙단계에 접어들어 안드로이드 개발팀이 개발을 시작한다고 합시다. 기획서만 있고 디자인, 서버 API가 아직 나오지 않는 상태에서 모바일팀에서는 업무를 어떻게 진행해야 할지가 문제입니다. 디자인 시안이 안나와서 기획서대로 xml를 짜놓은 후 액티비티, 프래그먼트 구현을 했는데, 디자인이 기획서와 상당하게 차이가 나도록 변경되는 경우가 생긴다면 액티비티와 프래그먼트의 UI로직도 변경이 필요합니다. 서버에서 mock-up 데이터를 안내려 주거나 힘든 경우 모바일 클라이언트에서는 mock-up만 오기를 기다려야만 하는가? 이런 문제가 있는데요.
사실 서버에서 데이터를 내려주지 않고 디자인 시안이 나오지 않는 상황에서도 할 수 있는게 있습니다. MVVM 아키텍쳐를 채택해서 ViewModel을 미리 만들어서 기획서에 나온 UI를 가지고 xml을 만들어 바인딩하는 정도의 작업을 할 수 있습니다. ViewModel에 대한 테스트까지 해주면 땡큐죠. View에서 사용할 Presenter도 이 단계에서 정의해 줄 수 있습니다. 만약 디자인 시안이나 최종 디자인이 나왔다면 해당 디자인에 따라 xml을 개발하고 기존 ViewModel과 바인딩만 해주면 되고 서버 API 개발이 어느정도 진행되어 mock-up 데이터를 내려줄 수 있게되었다라고 한다면 json2pojo 서비스를 사용해서 5분만에 POJO클래스를 만들고 POJO를 Adapter 패턴을 사용하여 ViewModel에 사용될 수 있도록 적용해 주기만 하면 됩니다. 그리고 Presenter가 model를 사용하도록 하여 서버 연동을 해주면 작업이 완료가 되겠네요.
좀 더 정리해보면,
1. 기획서를 바탕으로 ViewModel을 만들고, 테스트할 수 있는 기본 UI를 기획서에서 있는대로 최대한 단순한 xml을 구현한다.
2. ViewModel에 대한 테스트를 수행 및 테스트 코드를 작성한다.
3. Activity, Fragment, RecyclerView등의 View는 ViewModel만을 사용하도록 구현 한다. 절대 Model의 data(POJO)와는 디커플링 시킨다.
4. View layer에 대한 테스트 수행 및 테스트 코드를 작성한다.
윗 단계까지 작업하면 디자인, 서버 API의 mock-up이 준비되지 않아도 기획서에서 요구한 요구사항을 만족시키고 실행 가능한 앱이 됩니다.
그럼 만약에,
- 기획서가 변경되었다면 어떻게 해야 할까요?
기획서가 변경되면... 사실 답없네요ㅎㅎㅎ 그냥 기존 코드 베이스를 싹다 수정해야 한다면 수정 해야겠죠. 허탈하게 웃을 뿐입니다.
- 디자인 작업이 완료 되었다면 어떻게 해야할까요?
UI디자인에 맞게 xml을 수정하고 data binding을 활용해서 ViewModel과 연동하면 됩니다. 문제가 있네요. ViewModel의 수정이 필요하게되면 ViewModel에 대한 테스트 코드 또한 수정해야하고...
- 그럼, 서버에서 mock-up 데이터를 내려줄 수 있고 통신 프로토콜 방식에 대한 방식이 확정되었으면 어떻게 해야할까요?
data layer가 부재되어 있다면 data layer를 구현해야 하고 앞서 구현한 Presenter에서 API 요청을 보낼 모델을 사용하도록 합니다. json이 응답으로 오는 경우 json2pojo로 POJO 클래스를 뚝딱 만들면 되겠고, POJO와 ViewModel간 Adapter pattern으로 적용하여 기존 UI 로직 수정이 없도록 하면 개발이 끝나겠습니다.
우선 이러한 방식으로 회사에 적용해 볼까?라는 생각이 듭니다. 아직 제가 검증한 방법은 아니고, 이렇게 하면 어떨까 수준에서 나온 아이디어 입니다. 써보니 순수한 mvvm이 아니군요. 사실 click event 처리를 ViewModel에서해야 하나 Presenter를 만들어서 해야하나 현재 아리까리한 상황입니다. 글 보다는 그림으로 설명하는게 좋을것 같아 다음 글에서는 위에 너무 성의없게 작성한 글을 한번 visualization 하고 코드도 작성해서 설명해야겠습니다.
| 안드로이드 기능 개발 프로세스 그리고 MVVM #2 (0) | 2016.11.11 |
|---|---|
| 안드로이드 소프트웨어 아키텍쳐 패턴 해부 #1 (0) | 2016.06.22 |
 JVM, 성능튜닝, 수학, 안드로이드, OS, 컴퓨터아키텍쳐, 자료구조&알고리즘 에 관한 내용을 다룹니다. by 제이제이랩 |
||
|
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
