Let’s Swift in 판교 1회

안녕하세요😃 어제 Let’s Swift in 판교에 다녀왔어요!! 너무 재미있고 유익했는데 못 오신 분들을 위해 후기를 적어봤어요. 마지막에 다음 모임 발표자 지원 많이 해달라구 하시더라구요. 저도 발표하고 싶은데 아직 많이 모자라서 좀 부끄러워 지원을 못하고 있어요ㅠㅠㅠㅠ 그래도 3,4회 때는 발표할 수 있지 않을까요,,,, 발표자분들처럼 꼭 멋진 사람이 되어야겠다는 다짐을 하고 왔네요. 제 지식이 아직 짧고, 잘못들은게 있을 수 있으니 혹시 잘못된 내용이 있거나 더 좋은 내용이 있다면 댓글로 알려주시면 감사하겠습니다🤗

느낌적인 느낌을 찾아서 - 네이버웹툰 장수한

if문과 guard문의 차이점을 설명해주셨어요. 웬만하면 if문을 쓰라고 하셨는데 저도 공감했어요. 처음에 UIView의 isHidden 프로퍼티를 예로들어 시작하셨는데 UIView.isHidden은 데이터관점에서 만든 것이라고 하셨어요. 저도 가끔 isHidden 프로퍼티를 사용할때 헷갈릴 때가 있었는데 다른 개발자분들도 가끔 헷갈려하시는구나 하고 신기했어요. 그리고 !연산자가 안좋은이유, 피해야할 이유를 설명해주셨어요. !연산자의 핵심은 반전인데 이걸 사용하게 되면 가독성이 안좋아지게 된다고 하셨어요. 예를들어 설명해주셨는데 예시는 다음과 같아요.

if !title.isEmpty { }

만약에 아니면 문자열 타이틀이 빈 상태 = 가독성 안좋아

if titld.isEmpty == false { }

만약에 문자열 타이틀이 빈 상태가 아니라면 = 가독성 좋아

다음은 guard문은 이중반전(?)이라는 이야기를 하시면서 guard문보다 if title.isEmpty = false { return } 이렇게 if문을 사용하는 것이 가독성에 좋다고 하더라구요. 저도 요새 가독성이 좋은 코드를 작성하려고 노력중인데 이 발표를 통해 많은 것을 얻었어요. 스위프트가 런타임이 아닌 빌드타임에 에러를 잡을 수 있게 도와주는 대표적인 문법에는 guard문, optional이 있어요. 그래서 자신의 코드에 자신감이 있으면 guard를 쓸 이유는 굳이 없다구 하셨어요. 그래도 guard를 사용해 옵셔널을 언래핑할때는 쓴다고 하시더라구요. 확실한 guard문과 if문의 차이 때문이죠. if문은 if문 내부에서만 언래핑한 상수를 사용할 수 있으니까요. 코드를 읽는 순서, 해석, 그리고 가독성이 가장 중요하다고 하셨어요. 저도 이에대해 깊은 공감을 합니다. 알면서도 실천하기 어려운 것들이죠ㅠㅠ

그리고 모든 기본 문법엔 이유가 있다고 하시면서 추가적으로 하나의 예시를 들어주셨어요. 연산프로퍼티와 메소드였는데요. 별도의 파라미터가 필요하지 않고, 이미 저장된 다른 변수를 참조하여, 연산하되 그 결과를 저장할 필요가 없고, 그 결과를 바로 반환하면 될때 연산 프로퍼티를 써야한다고 하셨어요. 하지만 이렇다하더라도 그 기능이 동사면 함수, 명사면 연산프로퍼티로 만드는게 맞다고 하네요!! 결론은 문법의 특성과 목적을 생각하며 코드를 생산해야한다! 였습니당 정말 좋은 발표였어요. 기본적이고 누구나 해봤을법한 고민을 깔끔하게 해결(?)까지는 아니더라도 반성하게 되고 더 생각하게 되는 발표였어요😆

지저분한 언래핑 코드를 깔끔하게 정리해보자! - 네이버웹툰 김형규

Objective-C에서 Swift로 언어를 바꾸면서 optional이 생겨 안정성과 귀찮음이 동시에 올라갔다고 하셨어요!! 이런 언래핑의 헬게이트를 탈출하기 위한 다양한 방법들을 알려주셨는데요. 결론은 다음과 같습니다.

• Non-optional/optional 데이터 분리

• Guard / if / coalescing unwrapping의 사용을 구분하자
  • 빠른종료
  • 분기가 필요한 경우
  • default value
• Collection 내의 언래핑 코드를 줄여보자
  • compactMap/map 활용
• 단일 옵셔널 - map/flatmap

코드를 역할에 맞게 함수로 더 쪼개고 그에 맞춰 언래핑 코드를 분산하면 근본적인 해결책은 아니지만 가독성을 높여줄 수 있다고 해요. 여러개의 옵셔널이 input이 되는 경우도 flatmap안의 flatmap 안의 flatmap,,,이런식으로 해결할 수 있다고 합니다!! 형규님이 flatmap안의 flatmap,,,, 방법을 구체화해서 스위프트 포럼에 올리셨는데 다음 코드와 같은 방법을 얻으셨다고 하네요.

func abab(a: A?, b: B?) -> (A,B)? {
	return (a, b) as? (A, B)
}

이 발표도 재미있었어요. 저도 항상 이 지저분한 언래핑 코드들을 어떻게 하지라는 고민을 많이 하거든요. 그래서 더 흥미로웠던 같아요☺️

레거시 프로젝트에서 의존성 주입하기 - 스타일쉐어 전수열

부제: 왜 개념만 알려주고 적용 방법은 아무도 알려주지 않는가

그저 🔆수열님께서 발표해주신 주제는 정말 재미있었어요. 특히 부제가 정말 공감되어서,,,ㅜㅠㅜㅠㅜㅠㅠㅠ 저도 테스트코드의 개념은 알고있었어요. 하지만 적용 방법은 아무도 알려주지 않아서 바보같이 항상 시도조차 못해봤어요. 그래도 이번발표를 듣고 적용 방법도 조금 알았으니 시도해보려구요!

수열님이 말씀하시길,, 테스트는 어렵다 -> 테스트하기 좋게 짜여있지 않다 -> 커플링이 강하다 정말 구구절절 맞는말만 하시는 수열님,, 이런 테스트하기 좋게 짜여있지 않은 코드들은 대부분 강한 의존성을 갖고 있다고 해요. 그래서 이 강한 의존을 약한 의존으로 바꾸는 작업을 해줘야 한다고 합니다! 실제 프로덕트에서 Networking이라는 클래스를 사용해 네트워킹하는 코드를 구현했다면 테스팅을 할때는 NetworkingStub이라는 클래스를 따로 생성해 테스팅해야 한다고 해요.

가장 중요한 중심주제인 Composition root 는 의존성 그래프가 만들어지는 곳이고 프로그램의 진입점, 즉 AppDelegate에서 만들어줘야 한다고 해요. 자세한 내용은 수열님이 만드신 Pure를 보시면 이해가 되실거에요! 저는 지금까지 의존성은 생각하지 않고 앱을 만들어왔는데요. 깊은 반성했습니다,,,, 수열님이 설명해주시는 내용이 너무 재미있어서 앞으로는 의존성관리를 열심히 해보려고 합니다!!

중요한 점은 Composition Root를 테스트 환경에서 실행하면 안됩니다! 그리고 생성자 호출 외의 코드는 자제하는 것이 좋다고 합니다. 이론은 좋지만 현실의 문제는 레거시 코드가 의존성 그래프에 속하지 못한다는 것이겠죠? 그 이유와 해결방법은 다음과 같습니다.

1. 정적 인터페이스에 의존한다 -> 생성자로 전달받는다, 심각하면 생성자에서 타입을 전달받는다
2. 인스턴스를 직접 생성한다 -> 생성자로 팩토리를 전달받는다

궁극의 목표는 모든 클래스가 의존성 그래프에 속하게 된다지만 이는 이루기 매우 어렵기에 현실의 목표 어제보다 더 나은 코드를 작성한다를 매우매우매우 강조하셨어요. 일단 적어도 외부에서 주입할 수 있게하고 필요해질 때 프로토콜을 만들어야 한다고 해요. 그리고 복잡해지면 factory 타입을 정의하라고 하셨습니다! CS공부하라는 말씀을 듣고 반성하고 있어요..

아래와 같은 이슈들이 생겨도

테스트 환경에서 AppDelegate가 실행돼요

DetailViewController에 파라미터를 넘기고 싶어요

팩토리 클로저가 너무 복잡해져요

현실의 목표는 어제보다 더 나은 코드를 작성하는 것이라는 것을 또 강조하셨습니다! 마지막에 비보를 들었는데요. 수열님 발표녹화가 안됐다고,,,하네요ㅠㅠㅠㅠㅠㅠㅠㅠㅠ😂😂😂 다시 보고싶지만 그래도 필기를 해서 다행이라고 생각하고 있어요ㅜㅜ

검증되지 않은 이상적이고 극단적인 iOS 프로젝트 구조 설계 - 카카오뱅크 안정민

마지막 발표는 민소네(안정민)님의 발표였어요. 이 발표는 keynote가 아닌 Xcode를 통해 발표가 진행되었는데요. 정말 극단적인 프로젝트 구조를 보여주셨어요. 초반에 스토리보드를 리소스로 봐야한다는 말씀을 하셨는데, 이걸듣고 저는 지금까지 헛살았구나라는 생각을 했습니다,, 그래도 지금 깨달은 것이 다행이라고 생각하려구요🙃

하나의 애플리케이션을 서브프로젝트로 나누면 가질 수 있는 장점에는 다음과 같은 것들이 있다고 해요.

• 파일명이 동일한 걸 가질 수 있다. 즉, 쓸데없이 긴 prefix를 안붙여도 된다.

• 모듈명을 빌려 클래스에 접근할 수 있다.
  • Ex) Setting.ViewController

• 증분빌드 속도자체가 빨라진다. 이론적으로.

• 프로젝트 기반으로 격리화가 가능하다. 극단적으로.

그리고 나서는 dynamic framework와 static framework와 연관지어서 이야기를 진행해주셨어요.

• dynamic framework - 링킹만 하고 있다. shared의 개념

• static framework - application file에 소스가 들어간다.

서브프로젝트들이 static framework가 되면서 소스가 복사되기 때문에 사실상 모듈은 prefix가 된다고 하셨어요. static framework는 링킹이 된 곳에 또는 메인번들에 포함되게 된다고 해요. dynamic framework와 static framework에 대한 제대로된 개념을 모르던 저에겐 정말 흥미로웠답니다😆