-
Notifications
You must be signed in to change notification settings - Fork 1
11월 4일 회의록
Jiyong Jung edited this page Nov 4, 2024
·
2 revisions
- 프로젝트 초반에 적용 or 기존 것을 tuist로 적용하는 방법이 있다.
- 기술적인 근거가 충분한가? 단순히 학습의 목적으로 사용하는 것은 부적합하다고 생각.
- 기술적인 근거는 충분히 만들 수 있다.
- But, 6주간의 시간 동안 학습의 분량이 상당하다고 생각함.
- 6주의 시간동안 모듈화를 먼저 경험하고 이후에 tuist로 적용해보는 것이 좋겠다.
- 모듈화 / 프로젝트 세팅을 최대한 학습을 하고, 해당 내용을 바탕으로 Tuist로 migration하는 과정이 훨씬 도움될 거라고 판단하였다.
- 버전에 따라서 사용할 수 있는 기술이 많이 달라질 수 있다.
- 일반적으로 배포는 3단계 전으로 한다.
- 우선은 15.0으로한다.
- 더 높일 필요도 낮출 필요도 없기 때문에, 추가 기능 요구사항이 들어갈때 변경하도록 한다.
- cocoapods → pod파일 생성, 협업시 조금 불편하다고 생각!
- 이미 사용해봐서 이번에 spm사용해보면 장단점 확실히 알수 있을 것
- 간단한 것은 SwiftUI로 그리기
- 기술적 이유
- 우리만의 아키텍처로 만들 것인가? or 클린아키텍처로 할 것인가?
- 클린아키텍처로 하면 좋은 점
- 모듈화
- 확실하게 공부하고 넘어갈 수 있는 기회
- 다른 디자인 패턴을 사용하기 위해서는 현재의 디자인패턴에 대한 불편한 점을 느껴봐야함. 그러기엔 기본적인 것에 대한 것이 부족
- MVVM 기초부터 하자.
- Combine을 먼저 학습하고 이후 Rx 적용하는것이 좋다고 생각함
- “애플”이 기본 제공하는 퍼스트-파티 프레임워크를 사용해보고 싶었습니다.
- Rx(외부의존)와 Combine(애플의 기술력)
- 코드 짜기가 어려우면 Combine으로 짜기
- 기술적으로 학습하기
- 왜 썼냐?! : combine으로 부족한 부분을 Concurrency가 채워주기 때문
- ios에서 크게 중요하지 않은 것 같다. 추후 DI 공부할때 해보자..
- Coordinator
- 객체지향의 관점에서 화면전환이라는 책임을 따로 분리해주는 것이 좋을 것이라는 판단.
- 분리를 제대로 해주지 않으면 ViewController가 복잡해지면서 무엇을 하는지 알 수 없다고 생각. (코드 간결)
- 학습 목적 + 앱의 확장성 고려를 생각하면 Coordinator가 좋다고 생각.
- 화면전환이 의도대는 되로 test가 가능하다.
- 우선은 써보고 단점을 찾아보자.
- 객체지향의 관점에서 화면전환이라는 책임을 따로 분리해주는 것이 좋을 것이라는 판단.
- 가능하다면 기능을 짜고 테스트 코드를 작성해보자, 결국에는 우리가 사용하는 아키텍처!
- 시간이 부족하다면 마지막주차에 해도 됨