멘토님의 질문
1.
프로젝트를 진행하는 목적은 어떤 것인가요? 제품생산이 목적인지, 공부가 목적인지
a.
둘다 목표를 하고 있다.
2.
ios 경험이 있나요?
a.
처음입니다!
3.
개발 시작한 기간
a.
한달 반
4.
하기전 다른 프로젝트는?
a.
팀원마다 조금 다르다
b.
c언어 , 자바, 등 각자 스택이 조금씩 다르다.
•
짚고 넘어가고 싶은것
◦
개념/용어 혼동하지말것 UiKit → SwiftUI (프레임워크)
•
매운맛
◦
중간중간 질문/의견 가능
1. SwiftUI로 리팩토링한 이유?
•
SwiftUI 로 옮긴 이유가 있나요
◦
웹 개발에 익숙해져 있다보니까, SwiftUI 가 좀더 익숙했다
◦
기존에 StoryBoard 에서 merge 할때 conflict 해결이 편했다
◦
code base 로 진행할수있어서 좋았다
•
UIKit 으로 돌아갈수있다면 돌아갈래?
◦
아니요
◦
다들 아니라고 생각
•
의사결정에서는 근거의 타당성이 있어야한다.
◦
넷 모두 동의를 했는지
◦
결정의 이유는 무엇이었는지
•
현업에서는 이런결정을할때 장점보다는 최악의 단점을 먼저 본다.
•
실제 새로운 기술을 도입을 할때
◦
해 본 사람이 많이 없으니까 제대로된 자료를 찾기 어렵고 문제 해결을 도와줄 사람이 많지 않다.
◦
이러한 리스크들을 충분히 고민을 해야 한다.
◦
철저한 사전 점검이 이뤄졌어야했는데, 지금은 좀 아쉬운듯?
•
멘토님이 SwiftUI 선호하지 않는 이유
◦
CoreData 연결하는게 좀 현타왔을것이다
•
DDIP에서 가장 핵심이 되는 상황이 Map인데,
◦
SwiftUI 에서 Map 이 제대로 제공 되지 않는데,
◦
이걸 진행하는게 의미가 있나?
•
다시 Swift UIKit으로 돌아가는 것도 생각해볼 것
◦
필요하다고 생각하면 용감하게 돌리기
•
앞으로(1~2년 안에) iOS 쪽으로 취업하려고 한다면, UIKit 을 써라
•
최신 기술이 나오고 2년뒤에 부터 인기를 얻기 시작한다
•
작년까지만해도 SwiftUI = 못쓰는거 였음
•
UIKit 처럼 코드를 구성한게 많이 보인다.
2. MVVM 구현
•
MVVM 구현이 전혀 안됐다.
◦
Binding, Observing, 데이터 흐름에 대한 이해가 없이 코드를 짠 것 같다.
◦
View-View Model관계
▪
Binding, Observing 하기 때문에 컨트롤러의 문제점(??맞나)을 피할 수 있다.
◦
View가 Model의 상태를 감지하지 못하는 것 같다.
◦
뷰 자체가 상태를 가지고 있는걸 지양하고 있다.
•
뷰를 출력하는 방식에서의 차이뿐만 아니라 아예 생각을 좀 다르게...
◦
UiKit 는 능동적인 느낌
▪
컨트롤러가 사이에서 중재함. model 을 보고 View 를 수정
◦
SwiftUI
▪
MVVM 은 서로 Binding 되어있기 때문에, 그런 문제를 완전히 피해할 수 있다.
▪
모델의 변화를 뷰모델이 자동감지하고, 뷰모델의 변화를 뷰를 자동감지한다
▪
애플이 좋은척은 다 했지만, 구라였다
•
제대로 된 튜토리얼이나 검증이 되어있는지 잘 모를때는, wwdc 읽어보자
3. SwiftUI 공부
•
기초부터 탄탄히
◦
Apple Developer Tutorials
◦
WWDC swiftui
•
SwiftUI 공부는 WWDC부터 시작!
•
코드를 먼저할게 아니라, 이런 학습이 먼저 선행 되어야한다.
◦
핵심 기능 부분만, 따로 프로젝트를 만들어서 진행하면서 조금씩 점진하는게 나을뻔 했다
•
SwiftUI는 Combine때문에 학습량이 많다.
◦
초보가 하기에는 ㄹㅇ 쉽지 않다
•
어느 포인트를 잡았어야 했나?
◦
튜토리얼을 안보고 그대로 만들 수 있는 수준이 되어야, 실제 제품에 적용이 가능한수준이다.
•
욕심을 내려놓고,
◦
기능 하나만 딱 만들기만하는게 좋다....
4. UIKit으로 돌아가면 xml diff 어떻게 처리? 아니면 코드베이스?
•
방법1. 현업에서는 주로 StoryBoard 를 나눈다
◦
담당자를 배분한다
•
방법2. 아니면 코드로만 Layout 으로 하는곳도 많다 (차선책)
5. 네이밍 & 코딩 컨벤션
•
협업하는 사람들끼리 맞추기
•
사용하는 언어에 따라 맞추기
•
swift Lint 로 맞추는거 할줄 알아야한다
•
5년뒤에 봐도 이해할 정도로 ️네이밍️이 중요하다
️네이밍️이 중요하다•
한글에서 맞춤법 맞추는거랑 똑같은 느낌이다.
•
SwiftApi가이드 가 있다.
◦
도구
6. Swift 문법
•
if/else & switch 질문 → 클로져문법 살펴보기
•
UIKit 사용할 때보다 SwiftUI 사용할 때 난이도가 더 높다.
•
클로져를 바로 쓸지, 아니면 함수로 빼서 쓸지
◦
정답은 없다. 상황에 맞게 판단해서 사용하기.
◦
가독성을 해치는 상황이면 함수로 빼면 되지만,
◦
한줄로 편하게 끝낼수있다면 그냥 바로 넣어도 된다.
7. 나머지 질문(Navigation View 등)
•
UI Component에 대해 이해가 부족해서 생기는 질문같다.
•
질문 자체가 애매하다.
•
Navigation Link vs. Button
◦
Human Interface Guide 참고하기
◦
아이폰 사용자 라면 당연한데(사실 익숙한 사용자가 아니라면 당연하지 않음), 이걸 그대로 코드로 구현해야되나? 그런듯 ㅇㅇ...
▪
예시: 취소 버튼은 항상 왼쪽
▪
언제 화면을 왼쪽에서 오른쪽으로 쓸어넘기는지(Navigation), 아래에서 위로 쓸어넘겨야하는지(Modality) 등 모든 상황에 대해 정리가 되어있음
•
이건 정보의 흐름에 따라 다르다.
◦
아이폰은 정답을 미리 다 제시해둔다.
▪
하라는대로 따라만 하면 됨.
8. 코어 데이터를 왜 썼나요?
•
서비스가 iOS 만 할거는 아니니까,
•
이런 기능 자체는 백엔드에서 진행하는게 맞다
•
애초에 iOS에서만 존재하는 기능이기때문에 확장성을 고려할 때, 별로다
•
localStorage 에 저장하는 기능은 차후에 빼도 되니까 지금은 안해도 된다.
•
핸드폰에 존재하는 달력 기능을 바로 써버리는게 맞는가 아니면 로컬에 저장하고 있는게 맞는가
◦
애초에 iOS 캘린더에 접근이 안된다.
◦
우리가 보내는 요청은 되는데, 캘린더로부터 받아올수는 없다.
•
저장해야하는 데이터의 종류에 따라서 로컬에 어떻게 저장해야할지는 다르다
•
유저 정보는 그냥 키체인에 저장하면 된다.
◦
대신에 유료(애플 개발자 계정)....
◦
유저 디폴트?
9. 서버 URL을 어떻게 숨기나요?
•
보통
◦
프로젝트의 번들 파일에 URL을 저장해놓고,
◦
파일로 부터 가져오게 한다.
◦
깃에서 이 파일은 가져오지 않도록 빼놓는다.
•
유저들도 번들을 열어볼수있는 경우는 어떻게 하냐
◦
이거는 백엔드단에서 처리를 해야한다.
◦
극단적으로는 파일 자체를 암호화해서 쓰기도 한다.
10. VC 데이터 통신
•
delegate 는 이벤트 전달 성향이 크다.
◦
데이터 전달 보다는 이벤트 위임 느낌
◦
두 타입 사이에 결합도 높아짐
•
combine 생기면서 해결책들이 생김
◦
binding, 등등 옵져버 패턴
◦
지금 공부할만하다
◦
UiKit 이랑도 많이 쓰이나요?
▪
Combine 사용해서 MVVM 디자인 패턴으로 구현할수있다
◦
UiKit 에 MVVM 적용하는걸 보기는 어렵다
•
DDD 이거 쓸만함?
◦
실무에서 잘 쓰여요? → 이거는 의미가 없음
◦
팀장 마음에 따라서 다름;;;
◦
그리고 지금 실질적으로 쓰기에는 에바인듯
◦
근데 이거 쓴다고 하는 사람 들어본적 없음
•
결합도를 낮춰야하는데, delegate, closure 는 너무 어렵다
•
notification center 는 연결성이 안보여서 어려움
11. 그래서 머 해야될까요...
일단 UIKit은 어느쪽을 선택하든 기초 다져두기
1.
제품 내놓는다면?
•
빠르게 해야되는 상황으라면,
•
지금 갈아엎고 UIKit 으로 최대한 빠르게 할 것
•
SwitfUI로 하면 더뎌질 수 있어서!
2.
공부가 목표라면?
•
Swift UI 도 공부해보고,
•
MVVM 도 공부해보고
•
기본적으로 공부할것이 뭔지 알아보고 튜토리얼 그대로 해볼수있을 정도로 할수있을정도로 숙달 되면
•
기본 단위부터 조금씩 만들어보는게 나을거같다
12. 목표는 어떻게 되나요?
•
기간을 좀더 늘려놓고 하는게 좋을거같아요
•
현업자도 최소 기능 만드는데 최소 한달반은 진짜 걸림
13. 초보와 현업의 핀트 차이
•
기획자를 뽑는게 아니라, 개발자를 뽑는것이기 때문에,
•
개발자가 되려고 한다면, 기능 중심보다는,
•
구현하기 위해서 쓴 기술이 뭔지
•
왜 그 기술을 사용했고, 그래서 대체제는 무엇인지 이런걸 생각해보기
•
현업자의 얘기를 들어보자
◦
어물쩡 선배들 얘기를 듣고 혹하지 말것...
◦
다른 iOS 멘토님들 의견을 먼저 들어보자
◦
곰튀김(송치원 멘토님)
◦
미정 멘토님?
14. 앞으로....
•
인사 담당자가 개발자 데리고 오는게 덤덤 불가능해서
•
developer relation 이런 직군들 생기고 있다.
•
개발자랑 기획 사이에 그런 직군들도 충분히 있다.
•
코딩배워서 개발자만 되는건 아니니까 ,,,
