---
# System prepended metadata

title: Untitled

---

#### RDBS vs NoSQL
- 일단 간단하게 사용하기엔 NoSQL이 좋겠지만 백엔드를 제대로 설계하려면 (음악 플레이리스트 추가 등) RDB가 필요할 것 같다. 

### 아키텍쳐 선정
- 아키텍쳐: JK-클린아키텍쳐(MVVM)
- 선택 이유
  - 뷰와 뷰모델을 분리하여 여러 명이 협업할 경우에 발생할 수 있는 충돌을 막을 수 있음
  - 뷰모델 하위 모듈에 대한 테스트가 쉬움

## 기술 스택
- RxSwift 선택
  - 네트워크 작업 비동기에 대한 가독성 증가 및 Thread 관리의 이점
  - 뷰모델 바인딩 코드의 복잡성 감소
- Git 관리 : Git Kraken
  - GUI툴이 있으면 협업시 발생할 수 있는 브랜치 충돌관리를 쉽게할 수 있을 것이고 화면공유로 서로 얘기하기 쉽게하려면 통일된 하나의 툴을 이용하는게 좋을 것 같다.
- UI 개발방법 : Code 기반 개발
  - 개발 기간이 오래걸리는 단점이 있지만, 협업시 유리한(동일한UI  동일한 UI 화면에서 동시작업을 진행하기 위해 충돌의 위험이 적은) Code 기반 개발 선택
  - [UIKit또한 SwiftUI의 Preview기능을 이용할 수 있는 방법](https://medium.com/swlh/how-to-use-live-previews-in-uikit-204f028df3a9) 또한 존재하지만 불필요하다고 판단
- AutoLayout: SnapKit
  - 협업을 위해서는 가독성이 중요한 요소임으로 채택
  - [러닝커브가](http://snapkit.io/docs/) 매우 낮아 코드리뷰에서도 용이
- 영구저장소
  - Realm vs CoreData - https://cocoacasts.com/core-data-or-realm
  - 차후 논의
- 패키지매니저? 서드파티라이브러리매니저?
  - SPM은 XCode에서 통합되어있는 기능이고 사용이 간단하며 우리가 사용하는 라이브러리가 SPM에 등록되어있다고 판단
  - 차후 논의
- 네트워크 관련 서드파티: URLSession vs Kingfisher vs Alamofire
  - 네트워크가 보통 컨텐츠 다운로드로직에 많이 사용되고 로그인 관련 로직은 Firebase를 이용하게될 예정이므로 Alamofire는 필요하지않다고 판단함
  - Kingfisher는 이미지 캐싱처리를 기존에 만들어놨던 로직을 재사용할지 좀 더 고려해볼 필요가 있음
  - 기본적으로는 URLSession 활용

![](https://i.imgur.com/jblUtVB.png)


## 다른 팀 염탐 정보
- 더 고민해봐야할 것
  - minimum target 지정
  - 각 기능에 필요한 라이브러리 고민(빼먹은것)
    - 달력


3조 위키 https://github.com/boostcampwm-2021/iOS03-Routinus/wiki
4조 위키 https://github.com/boostcampwm-2021/iOS04-OwnMyWay/wiki
8조 위키 https://github.com/boostcampwm-2021/iOS08-WithBuddy/wiki


