[Let's Swift] 렛츠 스위프트 판교 후기

저번에 티켓 예매를 실패한 Let's Swift에서 한번 더 판교에서 열린다고 해서

BTS 콘서트를 예매하는 소녀팬처럼 두근거리는 마음으로 예매를 시도했고, 성공했다.

 

특히 내가 개인적으로 존경하는 개발자분들이 발표를 하셔 더욱더 기대가되었고, 도움도 정말 많이 되었다.

열심히 기록도 하고 경청을해서 들었는데 하루만 지나니 기억이 또 가물가물.. 더 잊기전에 정리를 해본다.

 

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

UIView.isHidden =

뒤에  true? false? 가끔 헷갈릴 때가 있음

isHidden = 숨긴다

우리는 스토리보드 xib 이미 표시 되어 있다고 생각, 인간은 90% 시각에 의존, 부정 보단 긍정 더 선호한다.

그런 느낌으로 보면, isHidden = false 로 생각하고 있는데 정작 숨길땐 true를 사용한다.

 

왜 Swift는 이렇게 생각했을까?

titleLabel.isHidden = title.isEmpty

시각의 기준이 아니라 데이터 관점에서 설계를 한 것임 (인간이 아니라 기계 입장에서)

!  (not)

코드가 많으면 안보임 ㅠㅠ → 헷갈림 근데 이건 사실 부정이 아니라 → 이진수 → 토글 시키는 것임

왜 이것을 피해야 하는지 확장해 보자 - 부정이 아니라 반전시킨다는 생각함

 

!isEmpty  //아니면 빈 상태

isEmpty == false  //빈 상태 아니라면 → 훨씬 더 직관적이고 가독성이 높다고 생각

 

guard

guard title.isEmpty else { return }  //이건 별로 생각하는데 문제가 없는데...?

if 만약에.. → 만약은 문장을 완성시키지 않음

guard 막는다 → 문장을 완성시킴  → 결국엔 이중 부정이 되는 것임

 

if title.isEmpty == false { return }

이게 더 자연스러움 → if를 더 선호하는 편

구지 guard를 강박적으로 안써도 된다고 생각!

 

왜 if가 있는데 guard는 왜 만들었을까? guard의 원칙은?

초기 탈출 → guard 를 쓰면 조기 종료하는 키워드가 필요

 

Swift 옵셔널이 있음

가장 개발자를 위해 생각했다 부분 → Build time에서 잡아낼수 있도록 설계

 

guard를 쓰는 경우 옵셔널 언래핑할때 쓴다.

 

하지만 그외의 경우에는 if를 쓰면 if문 안에서만 쓸 수 있기 때문에..

코드를 읽는 순서, 해석, 그리고 가독성이 훨신 좋다고 생각한다.

모든 기본 문법엔 이유가 있습니다.

 

한가지 더

computed Property VS Method // 뭘로하지?

언제 무엇을 써야 할까?

별도의 파라미터가 필요없고, 이미 저장된 다른변수를 참조하고, 연산과정 결과 저장 필요없고..

그런게 아니라 ^^;

동사 / 명사 -> 좀더 본질적인 것에 맞게 생각을 해야 함

 

 

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

Optional

귀찮음..... 구절구절해짐 어떻게 하면 정리 할 수 있을까?

특히 API 파싱하는데 옵션널 / 넌옵셔널 구분...해서 언래핑은 깔끔하게 할 수 없을까?

 

앞서 발표신분과 달리 저는 조기탈출 할 때는 무조건 guard를 써야한다고 생각함 (사족을 달자면 나도 그렇게 생각하고 있음)

 

언래핑코드를 분산해서 작업하고 map / flatmap이 값이 있을때만 돌아갈수 있다는 것을 이용해서 작성

name.map(makeText)

1. 데이터를 옵셔널 / 넌옵셔널 분리

2. 3가지 언래핑 구분 (기억이 잘 안남.. ?? 이거말고 기억이..)

3. map, copactmap 사용해서 여러면 언래핑하는 작업을 간단하게 만듦

4. map, flatmap

(이후 부분은 나중에 슬라이드를 보고 정리..ㅠㅠ)

 

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

의존성 주입 - 왜 개념만 알고 방법은 알려주지 않을까?

테스트는 어렵다.

왜? 테스트하기 좋게 짜여있지 않기 때문

왜? 커플링이 강하기 때문

 

레거지 프로젝트에서 의존성 주입하기가.. 어떻게해야할지를 모르겠음 ㅠㅠㅠ

 

강한 의존 → 약한 의존으로 만들고, 

Production은 실제 코드로 들어가게하고,

Testing은 Stub 이용해서 테스트

 

return self.networking.get()

UserService(networking: )

UserService(Stub)

 

그래서.. 생성자 주입을 어디서해야 해요?

compodition root //조합의 뿌리? = 의존성 그래프가 만들어지는 곳

 

프로그램의 진입점인 AppDelegate에 Compodition Root를 사용

Compodition Root에서는 테스트환경을 위해 생성자 호출 외 코드는 자제

 

그리고 의존성 그래프를 한번 만들어 봅시다.

 

현재 의존성 그래프에 속하지 않는 경우 

레거시 코드가 너무 오래되서.. → 정적 인터페이스에 의존하고 인스턴스를 직접 생성하기 때문에

 

목표

모든 클래스가 의존성 그래프에 속하게 된다. (Compodition Root)

 

현실의 목표

어제보다 더 나은 코드를 작성한다.

하나씩 하나씩 Compodition Root에 연결

 

해결 방법

Static 인터페이스에서 호출 → 생성자로 전달 받는다

init(userService: UserService)

self.userService.fetchUser()

적어도 외부에서 주입할 수있게 되었다. 필요시 프로토콜을 만들자.

UserService.fetchUser() → 써드파티 라이브러리

생성자로 타입 전달을 생성자로 팩토리 전달 받는다. (이때 Pure같은 좋은 라이브러리가 있다!)

 

프로젝트 구성 이야기 - 카카오뱅크 안정민

(개인적으로 지금까지 갔던 세미나중에 가장 충격적인 섹션이었다..)

 

그동안 렛츠 스위프트, 렛어스고 발표한 내용의 최종판 발표입니다.

 

기존 프로젝트는 중복을 막는 방법이 긴 prefix / 모듈이름을 쓰던가해야 했음

근데 모든 기능이나 화면을 프로젝트(프레임워크)로 묶으면 어떨까?

 

다이나믹 ,스테틱 프레임워크를 적절히 사용해서 프로젝트로 쪼갠 극단적인 방법을 생각 했음

프로젝트 별로 ViewController 등 prefix없이 바로 사용 가능

 

스테틱 프레임워크는 링커를 통해 어플리케이션 파일에 소스가 들어가게됨

스테틱 프레임워크의 경우 코드가 메인으로 들어가기 때문에 메인 번들에 번들 위치를 가질 수 있음

 

반대로 다이나믹에서는 번들들을 가지고 있을 수 있음

 

이러한 특성을 사용해서 모든 기능을 프로젝트로 나눌 예정임

(어.. 근데 너무 극단적인거 아닌가..? 동공지진)

 

카카오뱅크는 실질적으로 프로젝트롤 모두 나눠서 진행할 예정

 

후기

1, 2 섹션은 정말 들으면서 고수들은 어떤 작업을 할때 왜? 라는 질문을 그냥 넘어가지 않고 본질적인 이해를 위해 찾아 보는구나라고 생각했다.

사실 나는 guard를 쓰거나 옵셔널을 unwraping할때, 아무 생각없이 늘 하던 데로 써왔다. 본질적인 이유 없이 남들이 다 그렇게 하니까.

하지만 모든 것에는 이유가 있고, 그 본질적인 부분을 이해해야 응용도 할 수 있다는 것을 다시 한번 깨닫게 되었다.

 

3 섹션은 나에게 많은 동기부여를 갖게 되었다. 사실 의존성 주입 이야기만 많이 들었지 현재 프로젝트에 적용해 해볼 생각은 전혀 없었다.

하지만 정말 친절한 방법으로 하루하루 하나씩 고쳐 나갈 수 있는 좋은 방법을 알려주신것 같다.

더 나아가 테스트 코드도 작성해야하는데 휴우 진짜 갈길이 멀다.

 

4 섹션은 그동안 민소네님 발표를 들으면서 framework에 대해 정말 많이 알 수 있게 되었다. 그동안 cocoa pod만 사용하다가,

실제로 컴파일 되면 Framework 들이 어디로 들어가는지, 스테틱, 다이나믹 Framework 차이가 무엇인지 정말 많은 인사이트를 열어주신것 같다.

이번 발표 처럼 일일히 Framework로 나눌 수는 없겠지만, API부분이나 재사용이 가능한 부분은 Framework로 나눠볼 생각이다.