2022. 11. 04 : Architecture Kick - off

 

 

Architecture (11/4 가즈윌)

 

 

View controller 

View 라는 스레드가 한없이 돈다

OS에서는 Process안에 수많은 thread가 돈다

 

아키텍쳐란?

하나의 view만 본다면 여러 컴포넌트의 모임이지만,

동적인 (런타임) 측면에서는 Process, App 하나를 의미

메모리에서 죽지 않는 영역

 

동적이고 정적인 측면을 다 보아야 한다.

MVC: Logical architecture

 

Runtime architecture

Process, Thread 

실제로 런타임에서 바라보는 구조 (OS가 인식하는 구조)

두 개의 앱이 데이터를 공유해야 한다면?

프로세스: 데이터를 정의하지 않는다.

그럼? 세션 메세지 통신 등등의 방법이 있다.

 

Conceptual architecture 

쓰임새에 맞게 붙인 이름들

어쩌구 뷰 컨트롤러 (Signin VC)

쓰임새들의 모임 (컨셉)

 

Physical architecture

이게 분리되게 되면, 다른 OS

서버에 있는 구조 (네트워크 케이블)

아이폰에 있는 구조 (LTE 무선)

 

MVC, MVVM 등만 아키텍처에 해당되는 것이 아니다.

런타임 아키텍쳐가 프로그래밍할 때 많은 고민을 하게 한다.

두더지 게임 스레드 예시 (한 쓰레드에 다 두면 컨플릭, 정지 문제)

-> 멀티 스레드 (스레드 분리를 한다.)

늘 이런 방식을 고민하면서 프로그래밍 해야한다.

우리의 솔루션을 분리하여, 적합한 아키텍쳐를 찾아가면 된다.

 

예시: 애플 뮤직

view로 보는건 하나의 프로세스에 해당함

뷰를 볼 필요가 없다면 백그라운드로 돌린다. 

Background process가 돈다

 

Thread와 Process의 차이

메모리 데이터 공유

 

백그라운드 스레드로 일을 야금야금 데이터를 불러오면 좋겠다. 

-> 백그라운드 프로세스를 만들면 좋겠다.

 

뷰를 보고 있으면서, 소량의 데이터를 받아오고 싶다면?

-> 백그라운드 스레드로 받아올 수 있다. (다 프로세스여야 하는 건 아니다)

 

이런걸 고민하면서 프로그램을 짜야한다. 

이상한 버그, 눈에 보이지 않는 버그를 예방할 수 있다.

그러한 컨셉을 이야기해보자 (어떤 아키텍쳐가 좋다를 논하는게 아니라)

 

QA (Quality Assurance)

주니어 개발자에서 더 좋은 개발자로 나아가려면? 

초급 개발자 학생들은 QA 관련 job을 많이 갖게 된다.

고급지고, 좋은 코드를 많이 보게 되면 배울 수 있다.

 

회사들은 logical architecture가 이미 fix 된 경우도 많다. 

당근마켓은 예를 들어 RX Swift, 알라모파이를 기반으로 사용

(특정 프레임워크, 라이브러리에 의존적인 경우도 있다.)

 

정확하게 잘 동작하는가?

많은 테스트 케이스를 작성하고, 텍스트 하는 업무

: 코딩이 정확하게, 모든 edge case에서 동작하는가? 

: Verification 업무

+ 디자인 대로 개발이 잘 되었는가? (Validation 업무)

 

의도한 디자인 대로 안되는 경우가 있고,

클라이언트가 원하는 대로 서버 API가 작성이 안 된 경우도 있다. 

항상 happy 시나리오만 있어서는 안된다. (유저들은 엉뚱한 행동을 하게 된다.)

 

우리의 솔루션에서, 해당 아키텍쳐가 최선의 방법인지

QA 리스트를 통해 알아볼 수 있다.

우리가 스레드를 나누어야겠다. 

프로세스를 분리해야겠다

 

해당 챕터의 목적: 이러한 논의를 해보고 싶었다.

아키텍쳐란 각각의 컴포넌트가 그 자체로 설명 가능하지만, 

함께 했을 때 상호 간의 동작을 설명하는 것이 아키텍쳐이다.

아키텍처: 토목에서 활용하는 말

(빌당 자체로, 또 다리도 모두 그 자체로 의미가 있다.

그런데, 빌딩 사이를 이어주는 다리는 아키텍쳐를 의미한다.)

 

 

3-5년 개발하다보면

스레드 or 프로세스에 감이 잡히는 것

Physical condition 생각 안하고 프로그램 짜면 어떡해?

네트워크가 자원 먹고, 배터리 메모리 덜 쓰게 해야한다.

 

허준이 교수님 유튜브 꼭 보자 인사이트가 있다.

 

모두 OS 에서 나뉘어진 것

OOP -> 디자인 패턴 23개

 

쓰임새는 달라

그치만 같은 패턴의 문제를 풀고 있다

Ex) 값이 변했을 때 빨리 읽어오고 싶다

-> 그 값을 지켜보고 있다가 알려줘

Observable 등등

 

네트워크라는 건 끊어질 수 있다는 걸 고려해야 함

sync라고 우리가 생각하지만, 비동기 처리를 해두고,

sync처럼 보이게 하는 경우가 iOS에서는 많이 보인다.

비동기를 동기처럼 보이도록 처리하는 경우가 많다.

 

Sequence Diagram

Object - Thread 간의 데이터 전달 구조

그냥 칠판에 그린다

협업을 하려면 -> 손으로 그리는게 제일 빠르지 않을까?

모든 API가 비슷한 Flow를 가지고 있는 느낌 -> 설계를 하고 개발

 

UML : 바닥부터 다 만들 때 (큰 조직에서 유의미한 것)

iOS의 lifecycle (제약 조건이 있다)

우리의 앱 개발: 참조하는 라이브러리 등 밑바닥이 많은 것

우리는 작고, agile하고 기민한 조직 (하지만 기록은 남게)

 

10명 이상 들어가면 의사소통 비용이 크다

공통의 정형화된 언어를 만들자 -> UML

 

정답을 찾는 것이 아니라

함께 생각해보는 Chapter

 

코드 리뷰: QA 점검 리스트 중 하나

서로의 패턴이 팀의 패턴이 되어가는 좋은 프로세스

 

우리는 왜 Clean Architecture를 추구해야 하는가?

남세동 대표: 코드를 작성하다보니 클린 아키텍쳐가 되더라

문제들은 비슷비슷하니까, 자꾸 다듬다보면 비슷해진다.

문제는 하늘에서 뚝 떨어진 게 없다. 다들 유사한 문제

(특별히 특별하고 좋은 문제는 없다)