let us: Go! 2019 Spring

안녕하세요 :) Zedd입니다.

다행히 제가 3월 30일에 발행은 해놔서..날짜는 잘 나오게 됐지만 쓰는건 이제야 쓰네요.

일요일에 쓰려고 했는데 다래끼가 너무나도 심하게 나서 도저히 눈을 뜰 수가 없었습니다 3_3...

오늘도 회사에 가려다가...또 모니터 계속 보면 피로가 너무 심할 것 같아서 안갔다는 사실..

약을 엄청나게 먹고있는데 왜 안낫지!?!?!?

암튼..늘 그랬듯이 소소한 후기를 남겨보려고 합니다. 오늘은 특히나 더 소소할 예정. 

let us: Go! 2019 Spring 

---

일정은 이렇고 걍 메모한거 있으면 복붙하고 없으면 사족쓰겠음 메모 급하게 하느라 오타많은데 알아서 보셈

스토리보드 없이 UI만들기

코드 vs Interface builder(이하 IB)

왜 IB를 선택하지말아야하는가? 

- Conflict, 재활용성 최악, 가독성 low -> 발견가능성 떨어짐

왜 코드를 선택해야하는가? 

- 쉽게 해결할 수 있음. 떄로는 IB로 만들수 없는게 있음. 모든설정들을 한눈에 쉽게 파악 가능. 인터페이스를 코드로 짤 수 있으면 내가 어떻게 짜야하는지 정확히 이해하고 있다고 볼 수 있음. 스토리보드와 nib은 로딩이 길다. 

어떤 상황에서 코드를 선택하지 말아야 하는가? 그런상황 거의 없음. 

오토레이아웃팁 / 도구

UIStackView : 편하게 많은 constraint를 줄일 수 있다. 

Uiscrollview + stack view: 굳이 collectioview써야하나? 싶을때 유용

UILayoutGuide: 커스텀 할 수 있음. 코드로만 가능. 

View Debugger, Reveal, Wftautolayout.com

정답은 없음 각 상황에 맞게 효율적인걸 사용하면 된다.

try! Swift 2019후기

최완복님이 try! Swift를 갔다오신 후기라 메ㅐ모할게 없었네요. 발표자료가 올라오면 보면 될 것 같습니다. 

try! Swift..내년엔 꼭 가보고싶네요. 내년엔 WWDC도 시도해볼 예정입니다. 가서 총맞으면 어떡하죠 근데?

Texture 입문기

예전에도 Texture에 대한 세션이 있었는데, 그때 오오..이런게..있었다니 하면서 공부해볼려고 했는데zz결국 못한 기억이...

같이 간 제 동료분께서 플러터랑 UI를 구성하는 방식이 비슷하다고 이번에 적용하면 좋을 것 같다고 그러셨어요.

RxFlow 시작하기

RxFlow: Reactive flow coordinator를 구현해주는 프레임워크

Coordinator Pattern.

Navigation flow, Model mutation

Viewcontroller 및 Viewmodel등 종속성을 인스턴스에 삽입. Model mutation

어떤 화면으로 이동하는 것을 승인해줘@@! 

Viewcontroller를 고립되게 한다. Viewcontroller를 완전히 통제할 수 있음. 

네비게이션은 상대적으로 정적이고, 스토리보드는 거대해서 네비게이션코드는 ViewController를 오염시킨다. 

RxFlow

• ViewController의 재사용성을 키운다.
• DI 를 쉽게 구현.
• 앱을 네비게이션 블록으로 나눌 수 있음. 

Flow / Step / Stepper / Presentable / Flowable / Coordinator 

비밀세션

해보고싶어서 했다! 여기에 엄청 감명을 받았습니다,,,이 글을 보시게 된다면 2탄을 기다리는 사람도 있다는 것을 알아주셍,,

iOS환경에 SOLID적용하기

Why?

모든 아키텍쳐나 디자인패턴의 결국 목표는 결합도는 낮게, 응집도는 높게다.

객체지향 프로그래밍 유지보수 쉽게 읽기쉽고 확장 쉽다 + 설계의 5가지 원칙. + @

SRP: 단일 책임 원칙 

한 클래스(함수)는 하나의 책임만 가져야한다. 

클래스 코드를 수정할 이유는 하나여야한다.

Check point!

클래스 인스턴스 변수가 너무 많다.

속성과 상관없는 ㄴ메소드가 많다. 굳이 여기있어야할 메소드일까?

OCP : 개발 폐쇄 원칙

확장에는 열려있으나 변경에는 닫혀있어야한다.

Check point!

새로운 기능ㅇ이나 케이스가 추가될때 마다 기존의 코드를 변경해야한다.

자신의 속성보다는 외부의 속성을 의존하고있찌 않은가? (결합도가 높다)

인터페이스보다는 구현한 타입에 의존하고잌ㅆ지는 않은가?

LSP: 리스코프 치환원칙 .

하위타입은 기반타입을 대체할 수 있어야 하낟. 

Check point! 

자식클래스에서 너무 많은 override가 구현되어있다.

수직정 확장과 수평적 확장 중 어느것이 필요한 상황인지 생각해본다.

상속을 사용하면 강한 결합도가 생기기 떄문에 주의 필요

자식이 부모를 대체 할 수 없다.

 DIP: 의존관계 역전원칙.

상위레벨 모듈은 하위레벨 모듈에 의존 x

두 모듈은 추상화된 인터페이스 의존해야한다.

내부적으로 생성하는 하위 모듈이 존재하는가? (주입x)

DIP를 해결하기 위해 DI를 쓰는것이다. 

ISP : 인터페이스 분리 원칙

클래스내에서 사용하지 않는 인터페이스는 구현하지 말아야 한다. 

프로토콜에도 단일 책임의 원칙이 필요한다!!!!

프로토콜을 채택하고 어쩔 수 없이 의미없는 구현을 하고 있진 않은지?

만병통치약은 없다. 

개인적으로 가장 좋았던 세션이에욘

상속에서 프로토콜로

기억에 남은건.. Associated objects < 제가 Associated objects를 몰라서 반만 이해갔습니다..

프레임워크 주도 개발

기존 개발방법과 문제점

- 파일단위로 레이어를 분리

- 소스코드의 집중화

- 의존성 관리도구를 지원하지않는 Xcode. Framework 작성 및 관리의 귀찮음

- 코드 파일 개수가 많아질수록 느려지는 Swift

Framework 주도 개발은  Framework로 레이어를 나누어 개발

import 하지 않는 이상  Framework들끼리 알 수 없음

Framework 주도 개발 장점

- 외부 코드를 노출할지 말지 결정 할 수 있음

- 다른 Framework와  격리화 응집도 증가 결합도 감소

- 각  Framework에서 빠르고 많은 테스트를 수행가능

즉 메인 프로젝트에서는 안정적으로 적용가능라고 빌드 속도가 비교적 빨라짐

Conflict 발생 확률 줄어듬

단점

Framework를 만들어야함

기존 코드의 커플링을 제거하면서 리팩해야함

수많는  Framework 생길 수 있음

프로젝트 재구성

모듈은 라이브러리를 가진 프로젝트 특정 역할을  수행한다. 네트워킹 등 

모듈 패키지 여러모듈을 관리 및 모듈간의 결합으로 기능 확장

도메인 서비스 특정 도메인 역할 담당 

제가 얼마전에 서브모듈 작업했어서 조금 익숙했어요! 

민소네님네는 공통모듈로 사용할게 아니니..Build Configuration을 다 맞춰줬겠죠? 

Immutable Data

Immutable Data가 뭐고 왜씀?

let으로 선언되면 그냥 봐도 데이터 값을 알 수 있다 예상 할 수 있다

Coverage

Race condition

뭔가 변경이 있는 데이터가 필요하면 새로 만들어서 써야함 비효율적인거 아님? ㅇㅇ마즘

예상가능하고 테스트할 수 있고 Thread-safe하다. 즉 유지보수하기좋다.

하지만

친숙하지 않고

메모리 낭비 성능저하가 일어날 수 있다. 

== 한마디로 성능.

하지만 성능 신경 쓰지마셈. 걍 일반적인 프로젝트에서는 이뮤터블 써도 갠찮다~~~성능 걱정하지마라~~

https://www.slideshare.net/ChiwonSong/20190330-immutable-data-138781570

머그컵과 티셔츠도 감사합니다!! 티셔츠가 검정색이라 넘나 좋은것,,

그리고 엑스코드...엑스코드 아이콘을 3D 프린터로 뽑은거..있었는데 그것도 감사합미다 너무 예뻤어요!

눈이 아파서,,글에 오타는 차차 수정할게요

https://iosdevkor.github.io/let_us_go_2019_spring_review/