일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- combine
- XCTest
- ChatGPT
- 함수형 코딩
- Apple Developer Academy @ POSTECH
- 함수형 프로그래밍
- unittest
- Swift
- MVVM
- flutter
- 하드디스크 삭제 원리
- xcode
- 액션과 계산 데이터
- 쏙쏙 들어오는 함수형 코딩
- github
- IOS
- CI
- LGTM
- print 단점
- swift github action
- Swift thread
- SwiftUI VStack
- auto_assign
- os_log
- swift CI 적용
- SwiftUI
- 오픈소스
- firestore
- Firebase
- 2기화이팅
- Today
- Total
개발공방
[애니또] MVVM을 선택한 이유 - 리팩토링 (2) 본문
애니또 팀에서 아키텍쳐 패턴을 고민하던중 MVVM을 선택하게 되었다. 어떤 이유로 선택하게 되었는지 알아보겠다.
애니또 iOS 팀에서 MVVM을 선택한 이유
1. 테스트 가능성
우리의 목표는 테스트 가능한 코드였다. MVC에서는 테스트가 물론 가능할지 몰라도, 번거롭다. 왜냐하면 UIViewController에서 테스트가 필요한 함수들이 UI 코드와 엮여있기 때문이다. 테스트를 하기위해 UI관련 코드까지 작성해야하는 문제가 발생한다. 이런 문제들을 MVVM으로 해결할 수 있다. 비즈니스 로직들을 ViewModel이 소유하고 ViewModel은 View에 관해 일절 모른다. 그러기에 테스트 가능한 코드를 만들기 유리하다.
사실 1번의 이유만으로 충분하다.
2. 기능을 추가하기 힘든 기존의 아키텍처 패턴
MVC 패턴은 비교적 작은 프로젝트에서 아주 유용한 패턴이다. 그래서 개발 속도면에서도 가장 속도가 빠른 패턴중 하나이다. 하지만 우리의 프로젝트는 꽤나 방대해졌고, MVC와는 빠이빠이 할 때가 되었다고 생각했다.
현재의 우리의 패턴에는 서로 엮여있는 것들이 꽤 많다. 그래서 사이드 이펙트가 자주 발생한다. 역할이 너무 방대해져서 독립적으로 분리하기가 어렵다. 각자의 역할이 명확한 아키텍처가 필요했다.
3. Clean Architecture + MVVM
클린아키텍처의 장점은 많다. 의존성이 확실하고, 각각을 테스트하기에 너무나도 용이하다. 하지만, 첫 아키텍처 패턴부터 클린 아키텍처로 가는것은 무리가 있다고 생각한다. 우선 MVVM으로 만들고 추후에 각각의 역할을 명확히 분리할 때 클린 아키텍처를 추가할 계획이다. 왜냐하면 MVVM도 처음이고, Reactive Programing도 처음이기 때문이다. 이를 공부하며 MVVM을 적용할 것이기 때문에 클린 아키텍처를 바로 도입하기엔 무리라고 생각했다.
팀이 성장하기 위해선 새로운 도전이 필요하다. 클린 아키텍처는 우리 팀에게 새로운 도전이 될 것이다.
MVVM 하면 항상 따라오는게 있다. 바로 Reactive Programing이다.
말 그대로 반응형 프로그래밍이다. 어떤 ViewModel의 값이 바뀌면 관찰하고 있던 View의 UI가 변경되도록 반응하는 프로그래밍 방식이다.
이에 가장 많이 쓰이는 RxSwfit가 있다. 그리고 iOS 13이후로 나온 Combine이 있다.
다른 써드파티도 존재하지만, RxSwift가 압도적으로 많이 사용되고 있고 그만큼 잘 만든 써드파티라 후보에 올리게 되었고, Combine은 퍼스트 파티여서 후보에 올리게 되었다.
RxSwift vs Combine
팀 내에서 각각을 놓고 서로의 의견과 어떤걸 채택하고 싶은지 얘기를 나눴고, 결론적으로 Combine을 선택하게 되었다. 이유는 Combine은 First-party이고, RxSwift는 Third-party라 괜히 빌드시간을 더 잡아먹을 수 있다는 문제였다. 테스트 코드를 짜기 위해서 RxTest를 다시 import해야하고… 여러모로 Combine을 사용하지 않을 이유가 없었다.
현재 애니또 팀에선 MVC에서 View를 분리했는데, 이제 ViewModel을 추가해서 작업할 예정이다.
기존에 사용했던 delegate pattern또한 같이 가져감으로써 View도 UIView로 만들어 UIViewController에서 분리하고, ViewModel로 비즈니스 로직을 처리할 예정이다.
'Swift > UIKit' 카테고리의 다른 글
[애니또] MVVM + Combine Input & Output 구조 - 리팩토링 (4) (0) | 2023.07.14 |
---|---|
[애니또] MVVM + Combine - 리팩토링 (3) (2) | 2023.06.15 |
[애니또] ViewController와 View의 분리 - 리팩토링 (1) (0) | 2023.04.19 |
Swift UIBezierPath 크리스마스 트리 (4) | 2022.12.25 |
Swift DispatchQueue 기본 원리 (8) | 2022.07.14 |