19.03. let us: Go! Spring

동료를 통해 알게된 후로 용케 빠짐없이 참석하고 있습니다. 등록하는 곳에서 반팔티를 나눠주고 있었는데 사이즈를 묻기에 잠시 멍해졌습니다. '사이즈를 현장에서 묻다니 재고 관리는 어떻게 하는거지?' 중간중간에 들은 설명으로는 스폰서가 있었던 모양입니다. 

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

 

스토리보드 없이 UI 만들기

인터페이스 빌더의 단점으로 (1)머지 컨플릭트를 해소하기가 어렵고 (2)재활용성이 나쁜 점 (3) 변경된 프로퍼티를 알아채기 힘든 점을 들고 있습니다. 코드로 작성한다면 인터페이스 빌더의 단점들이 클리어되고 성능 관점에서도 개선이 된다고 합니다. 개인적으로는 인터페이스 빌더를 헤비하게 사용하는 편인데, 이러니저러니 해도 파일을 열자마자 '아 이렇게 생긴 뷰구나'라는 직관적인 정보는 포기하기 쉽지 않은 것 같습니다. 언급된 인터페이스 빌더의 단점 세 가지 중 앞의 두 가지는 어떻게든 보완이 가능한데, 세번째 문제는 사실 정말 심각한 단점이라는데에 동의합니다.

 

TRY! SWIFT TOKYO 2019

미리 좀 체크하고 있었더라면 참가를 고려했을 텐데 너무 아쉽네요. 언제 또 일본에서 할지 아무도 알 수 없는데... 여튼 소개해주신 일부 내용들만 봐도 너무나 흥미로웠습니다. 메모리릭 체크 테스트는 꼭 체크해야할 것 같습니다.

- https://www.tryswift.co/

- DISCOVER MEMORY LEAK WITH TESTCASE https://github.com/tarunon
- SWIFT TYPE METADATA https://www.untitledkingdom.com/
- ASSEMBLY, YOU CAN DO IT!
- INTRODUCING SOURCEKIT-LSP (Language Support Protocol)
- SHARPING SOUND IN SWIFT
- KEYPATH http://www.appventure.me/

 

TEXTURE

지난번인가 지지난번 세미나 때 빙글의 개발자가 엄청 호객을 했던 Texture입니다. 그때도 아 흥미롭네 한번 봐야지 해놓고 그냥 묵혀버렸는데, 한번 더 접하게 되었습니다. 그때는 깊이 생각 못했는데 최근에 Flutter를 경험하고 이날 또 Texture를 보니 CSS Flexbox 기반의 UI 구현이 대세인가 싶기도 합니다. Android도 ReactNative도 Flutter도 이 지점에서 유사한 부분이 많아 같이 공부할 때 쉽게 따라잡을 수 있는데 iOS는 혼자 개성이 지나치다는 생각입니다. 또 하나 매력적인 부분은 UI를 다 코드로 그리면 인터페이스 빌더를 사용할 필요가 없어지고 그럼 이제 AppCode를 사용할 수 있다는 부분입니다. 이젠 AndroidStudio보다 Xcode가 훨씬 익숙해졌지만 역시 IDE는 JetBrains!!! 또한 빙글의 개발자 블로그를 살펴보면 Node에 Test를 붙이는 내용도 소개되어 있습니다. 얼마나 빨리 학습해서 프로젝트에 넣느냐가 문제지 마음은 이미 결심.

 

RxFlow 시작하기

RxFlow를 통해 Coordinator 패턴을 구현하는 방법을 소개하고 있습니다. Flow, Step, Stepper, Presentable, Flowable, Coordinator 순서로 으쌰으쌰하는데, Coordinator 패턴에 왜 Rx가 필요한지는 사실 이해를 못했습니다. Rx에 좀 더 익숙해지면 뭔가 깨달음이 있겠지요.

 

iOS 환경에 SOLID 적용하기

결합도는 낮게 응집도는 높게. 언제 들어도 좋은 이야기입니다.

- SRP. Single Responsibility Principle.

- OCP. Open-Closed Principle. 확장에는 열려있으나 변경에는 닫혀 있어야 합니다. 

- LSP. Liskov Substitution Principle. 서브클래스는 자신의 슈퍼클래스를 대체할 수 있어야 합니다.

- DIP. Dependency Inversion Principle. 추상화된 것은 구체적인 것에 의존하면 안되고, 구체적인 것은 추상화된 것에 의존적이어야 합니다.

- ISP. Interface Segregation Principle. 클래스 내에 사용하지 않는 인터페이스는 구현하지 말아야 한다.

 

상속에서 프로토콜로

상속보다는 프로토콜로 구현하는 게 재사용성 측면에서도 훨씬 낫습니다. typealias를 UIViewController & DismissableUsable 이렇게 정의할 수 있는 줄 몰랐네요. 이어서 extension에 stored property를 추가하는 방법인 Associated Objects를 소개했습니다. 상속을 완전히 대체하려면 이런 특별한 수가 필요해집니다. 개인적으로는 약간 크래키하게 느껴져서 선뜻 사용하지 않는 방식이긴 합니다.

 

A Framework Driven Development

Framework로 레이어를 나눠서 개발하겠다는 아이디어입니다. 이렇게 되면 access modifier도 더 명확하게 사용할 수 있게 됩니다. 또한 Framework마다 테스트도 따로 붙이게 되어 있어서 무척 매력적인 방법이라고 생각됩니다. 집에 와서 개인 프로젝트로 이런 저런 시험을 좀 해봤는데, 아직 제 입맛에 딱 맞는 유즈케이스는 완성하지 못했습니다. 다짜고짜 Framework를 나누면 되는 것이 아니라 미리 코드를 분리해야한다고 분명히 설명했었는데, 까맣게 잊고는 Framework 부터 나누다가 삽질만 한참하고 처음으로 돌아와 코드 정리부터 다시 해보았습니다. New Project를 같은 레벨에 추가하는 방식을 소개했는데, 아무래도 New Target이 낫지 않은가 싶기도 하네요. Podfile에 의존성을 명시하니 framework search path 지정을 생략할 수 있었습니다. Model, View, ViewModel Framework을 구상했는데 View Framework에 포함된 xib 파일들이 로드가 안되어서 조금 전에 나가 떨어진 상태입니다. 방법을 찾던가 Texture 도입을 서두르는 것이 좋을 것 같습니다.

 

Immutable Data

Immutable Data만 사용해서 mutable 기능을 구현하는 방법을 소개했습니다. struct를 거의 사용하지 않다보니 이런 방식에 대해 깊이 생각할 일이 없었는데, 조금 어려웠습니다. Lens, Lensable을 사용해 Data 내부에서 mutable을 구현하는 방법과 Functor, Monad를 사용해 Data 외부에서 mutable을 구현하는 방법을 배웠습니다.