전체 글82 클린 아키텍쳐 TestCode 분리하기 문제 상황프로젝트를 진행하면서 팀원들의 개발 일정 상 앱의 디자인을 어느 정도 진행 된 뒤 API 연결에 들어가게 되었다.그러다 보니 연결이 제대로 되었는지, 데이터는 제대로 받아오는지 확인하기 위해 클린아키텍처 구조 상 DataSource (API 연결부)부터 Repository, UseCase를 지나 Presentation 레이어의 뷰모델, 뷰 까지 모두 연결되어야지만 테스팅이 가능했다.그런데 이 때, 앱의 구현이 진행됨에 따라 프레젠테이션 레이어 연결 시 변경해줘야 하는 부분들이 점차 늘어났고, 테스팅 실패 시 최악의 경우 전체 구조를 변경해야 하는 경우도 있었다.따라서 이 부분에서 불편함을 느껴 단계별로 DataSource 의 API 테스트, Repository의 DTO -> Entity 변환 테.. 2024. 8. 23. [iOS/Clean Architecture + ReactorKit] 클린아키텍쳐 책임 분리 ReactorKit을 사용하여 MVVM 모델로 구현을 하고 있었으며 클린아키텍처 구조로 프로젝트를 구성하고 있었다.프로젝트의 전체적인 구조를 살펴보면 다음과 같다Presentation ㄴ View(ViewController) ㄴ ViewModel(Reactor)Domain ㄴ Model ㄴ Usecase ㄴ Repository (프로토콜)Data ㄴ DTO Model ㄴ RepositoryImpl (구현부) ㄴ Datasource 로그인 로직을 구현하면서 여러 데이터 소스들을 사용하고 합치는 과정들을 거치게 되었고,이때 점점 레이어나 각 구성 요소들의 책임들을 모호하게 코드를 작성하고 있다는 생각이 들어 명확하게 책임 분리를 정리해야겠다고 생각했다.처음에 공부.. 2024. 8. 6. [iOS/ UIKit] Error 핸들링 - 모든 에러를 하나의 형식으로 관리하자 feat.ReactorKit ReactorKit을 사용하면서 state에서 Error를 받고 있었고 여러 UseCase에서 다양한 Error들을 내뱉는데 어떻게 관리를 해야 할까 고민이 있었다.한 개의 에러에 모든 에러를 몰아 넣을 수 없었다. 또한 NSError로 모두 정의하기에는 코드가 너무 지저분해 보였다.각 클래스마다 에러를 지정하고 싶었고, 내가 정의하지 못한 시스템 에러 또한 잡아주기를 원했다.그리고 각 에러마다 StatusCode와 간단한 설명이 있으면 좋겠다고 생각했다.따라서 각 클래스마다 LocalizedError 프로토콜을 준수하는 에러 값들을 만들고 statusCode와 errorDescription을 따로 선언해 주었다.예를 들면 다음과 같다 enum NaverLoginError: LocalizedError {.. 2024. 8. 2. [iOS/Fastlane] Fastlane으로 배포를 해보자 - fastlane 코드 살펴보기 default_platform(:ios)platform :ios do desc "Build and distribute to Firebase App Distribution" # 해당 lane의 설명 lane :distribute do # lane 이름과 시작점 match(type: "adhoc") # match의 Adhoc 프로비저닝 프로파일을 가져옴 clean_build_artifacts # 이전 빌드 아티팩트를 정리 (클린 빌드) # 배포 시 빌드 타임을 기록하기 위함 build_start_time = Time.now # 스타트 시간 기록 UI.message("Build started at #{build_start_time}") # 빌드 시작 메시지 출력 # 생성될.. 2024. 7. 31. 이전 1 2 3 4 ··· 21 다음
