내 맘대로 용어사전 🥸

분야를 막론하고 모든 용어를 습득한 순서대로 적습니다. 내 맘대로. 🙄

SRP

single-responsibility-principle: 하나의 클래스는 프로그램의 하나의 기능에 대한 책임만을 가지게 하는 설계 원칙

Cocoa MVC

Model-View-Controller

애플 UIKit의 MVC 패턴. View, Controller가 결합도가 너무 높음. Massive View Controllers 문제가 생김. 왜? Controller 역할이 너무 많음. 뷰마다 controller 하나씩 필요함

MVP

Model-View-Presenter

Cocoa MVC의 View와 View Contorller가 너무 붙어있으니 Presenter라는 View와 연관이 1도 없는 중간자를 만들어서 진짜 MVC를 구현

MVVM

Model-View-ViewModel

ViewModel이 Presenter처럼 Model을 소유하고 업데이트 하는 것은 변함이 없으나 View와 Data Binding이 이루어져 있다. 여기서 RxSwift, RxCocoa 등장! Binding 제공해줌. SwiftUI에서는 외부 라이브러리 없이 Binding 사용 가능

VIPER

View-Interactor-Presenter-Entity-Router

View: UIView, UIViewController
Interactor: 비즈니스 로직 중 데이터, 네트워킹과 같은 로직을 담당.
Presenter: 비즈니스 로직 중 UI관련 로직 담당
Entity: 데이타 객체 그 자체
Router: view navigation 로직 담당

RIBs

Router-Interactor-Builder-Component-Presenter-View (이 왜 s??? RIB가 중요하기 때문)

비즈니스 로직 중심의 앱 흐름을 만들기 위해 Router를 View 로직 중심이 아닌 비즈니스 로직 중심으로 설계한 것이 VIPER와의 차이점.

View, Presenter는 view Logic 을 담당하고 Optional 하다. 핵심은 RIB! (Router-Interactor-Builder)

Interactor: 비즈니스 로직 담당. Rx 구독, state변경, 데이터 저장 위치 선택, 다른 RIBs 가 하위에 붙을 지 결정 등의 일을 함. 모든 작업은 스스로의 lifecycle 내에 끝나야 함.
Router: Interactor의 output을 보고 하위 RIB들을 붙이고 떼는 작업으로 변환해줌. Interactor 사이의 추상화된 레이어. RIB간의 결합도 낮춰줌. Interactor 내의 반복되는 routing logic을 Router에 빼기 때문에 Interactor는 더욱 비즈니스 로직에만 집중 가능
Builder: RIB을 구성하는 모든 class 들을 인스턴스화 하고 하위 RIB들의 Builder들도 인스턴스화 함. Builder만이 DI system에 대해서 알고 담당해야함.
Presenter: stateless한 class. 비즈니스 Model을 View Model로 바꿔주고 그 반대로도 바꿔줌. View Model 변환을 쉽게 만들어주는 역할 딱 그정도만 담당해야함. 이 변환이 너무 명확하면 불필요. 이 때 변환하는 역할은 View 혹은 Interactor가 담당
View: UI 만들고 업데이트. 최대한 멍청하게 유지
Component: RIB의 의존성 관리를 위해 사용. 외부 의존성에 대한 접근 제공. 보통 부모 RIB의 Component는 자식 RIB의 Builder에 주입됨.

+ State Management

앱 state는 RIB tree에 붙어있는 RIBs로 관리. 각 RIB은 자신의 바로 한단계 하위 state 변경만 결정할 수 있음.

그렇다면 RIB의 변경과 관련이 없는 state들은? ex) 유저 프로파일 세팅 변경

답 ) immutable models stream에 저장함. 예를들어 유저 이름은 LoggedIn RIB 내의 ProfileDataStream에 저장될 수 있음

Fault, Error, Failure

Fault:
Error:
Failure:

RIPR

Fault & Failure Model로 Failure가 관찰되기 위해 필요한 4가지 조건인 Reachability-Infection-Propagation-Reveal을 일컫는다.

Reachability: fault가 있는 지점에 도달 가능해야함
Infection: program의 state가 올바르지 않아야함
Propagation: -
Reveal: -

Black-box testing

전체 시스템의 내용을 모르고, 시스템의 요구사항만 아는 상태에서 시스템 스펙을 기반으로 테스트 하는 것.

White-box testing

프로그램 구조를 보고 테스트케이스를 생성

@inlinable

Swift 컴파일러가 외부 모듈의 경우에도 최적화를 할 수 있도록 붙이는 키워드. 외부 모듈의 함수에 @inlinable 키워드가 있었다면 스위프트 컴파일러가 최적화 가능. 외부 모듈에 한줄짜리 함수가 자주 호출되는데 그 오버헤드를 줄이고 싶다면? @inlinable을 써보자

weak, unowned

class 끼리 강한 순환참조를 유지하는 것을 막기위해 사용. weak는 옵셔널, unowned는 값이 있다고 가정

mutating func reserveCapacity(_ minimumCapacity: Int)

Swift Array Instance Method. 배열에 들어갈 원소의 갯수가 이미 정해진 경우 여러번 메모리 할당을 하는 것을 막기 위해 처음부터 capacity를 줄 수 있음. O(n)의 시간복잡도를 가지기 때문에 원소가 없을 때 하는게 유리.

Xcode Server

Apple에서 지원하는 CI툴. Xcode에 통합되어 있기 때문에 Certificate, ProvisioningProfile 관리 쉬움. 자체적으로 Code Coverage 기능이 있음. 파일 단위 커버리지를 보여주어서 유닛 테스트 추가시 편함.

환경변수, REST API, 빌드 없이 분산 테스팅, 트리거 등 다양한 기능 제공.

단점:

Pull Request시 테스팅 하려면 Github webhook등으로 추가 설정해줘야함
오로지 MacOS만 지원
팀의 규모가 크다면 추가적으로 네트워크 세팅을 해 줘야함

Fastlane

CI 툴. 테스트 부터 배포까지 자동화 가능. xcodebuild 명령어들을 추상화해서 사용하기 쉽게 만든 서비스.

Info.plist

Information Property List File. XML 문법으로 작성된 앱의 정보를 담고있는 파일. key, value를 가지는 Dictionary형태로 구성되어 있음

CFBundleURLTypes: 앱에서 지원하는 URL scheme(http, ftp, …)의 목록의 키 값. 이름은 URL types이고 타입은 Array<Dictionary>