반갑다 멤버십
드디어 멤버십이 시작되었다. 멤버십은 챌린지와는 다르게 진행이 되는데 하나의 미션을 2주동안 구현하는 것이다.
1주차에 미션이 주어지고 2주차에 구현했던 것을 개선하는 것이다.
평소에 개발을 하고난 뒤에 개선해야지 하고 생각만하고 실천하지 못한 나에게 아주 적합한 일정이였다.
HIG 경험하기
Apple의 HIG를 알고는 있었지만 HIG에 대해 잘 이해는 하지 못하고 있었다.
막상 HIG를 다시 읽어보니 생각보다 더 많은 정보들을 담고 있었고 애플이란 회사가
사용자에 대해 얼마나 생각하고 데이터를 바탕으로 만들었는지를 느낄 수 있었다.
화면전환이나 사소한 애니메이션들에도 사용자가 어떻게하면 집중할 수 있게 하는지 고민하고 만든흔적들을
볼 수 있었고 앞으로 더욱 HIG를 자주 보아야겠다고 생각하게되었다.
추상화는 어디까지
챌린지에서 내 최대고민은 추상화였다. 챌린지에 입과하기 전에는 추상화에 대해서 깊게 생각해본적이 없었는데
추상화에 대해 고민할 수 밖에 없는 미션들이 주어지기도 했고 다른 캠퍼들이 추상화를 해놓은것을 보면서 많은 생각을 하게 되었다.
추상화를 직접 한번 해보니 추상화의 장점을 깨닫게 되었고 그러다보니 정말 작은 단위까지 전부 추상화를 하려고 했다.
그러다보니 추상화가 필요가 없는데도 추상화를 하고 모든것을 추상화 하려고 했었다.
이렇다보니 어디까지 추상화를 해야하나 하는 고민을 자연스레 하게되었다.
추상화를 할 경우는 다음 두 가지 조건을 만족했을 때 하기로 결정했다.
- 최소 2개 이상의 서로 다른 객체에서 같은 기능을 구현했을 때
- 언제든 다른 객체로 대체가 가능할 때
Generic과 Protocol
protocol을 통해 추상화를 하다보니 generic을 사용하는 경우가 종종 있었다.
protocol 내에서 generic을 사용할 때는 associatedtype을 사용하는데 associatedtype이 있는 protocol을 타입으로 받을 때 문제가 발생했다.
protocol을 채택한 객체들의 associatedtype이 다를 수 있기 때문에 같은 타입으로 처리하려고 하면
some이나 any protocl을 통해 해결해야 했다.
protocol SomeProtocol {
associatedtype SomeType
var someProperty: SomeType { get }
func doingSomething() -> SomeType
}
class ClassA: SomeProtocol {
typealias SomeType = Int
var someProperty: SomeType = 0
func doingSomething() -> SomeType {
someProperty
}
}
class ClassB: SomeProtocol {
typealias SomeType = String
var someProperty: SomeType = "0"
func doingSomething() -> SomeType {
someProperty
}
}
// 에러발생 !
// SomeProtocol의 SomeType의 타입이 다를 수 있기 때문
var array: [SomeProtocol] = [ClassA(), ClassB()]
// any 키워드로 해결 가능하다
var array: [any SomeProtocol] = [ClassA(), ClassB()]
WWDC와 그 영상을 잘 정리한 블로그 글
Embrace Swift generics - WWDC22 - Videos - Apple Developer
[Swift] some, any 키워드
Any와 any protocol은 다르다
하지만 any 키워드를 사용한다는 점에서 나는 이 방법이 잘못되었다고 생각했다.
Any키워드는 어떤것 이든 올 수 있고 타입캐스팅을 해줘야한다는 점에서 최대한 사용을 하지 않으려고 했다.
추상화에 대한 고민사항에 대해 다른 캠퍼들의 의견을 물어봤다.
다른캠퍼들의 생각을 듣고나니 Generic과 protocol을 사용한 추상화에 대한 개념을 정리할 수 있었다.
여기에 iOS마스터인 JK님께서 any와 any SomeProtocol에 관한 조언도 해주셨다.
내 생각했던 오류는 any와 any SomeProtocol을 동일하다고 생각해서 발생했던 오류였던것을 깨닫게 되었다.
Git과 친해지기
챌린지에서는 Gist를 사용하여서 Git을 제대로 활용할 일이 없었는데 멤버십에서는 Github을 통해 미션들을 제출하게 된다.
프로젝트를 fork하고 push pull을 하는 방법들을 사용해보면서 Git과 Github에 더욱 친숙해져야할 것 같다.
6주간의 그룹 프로젝트에선 Github을 무조건적으로 사용할 수 밖에 없기 때문에 앞으로 8주간 미션을 진행하다보면 익숙해질거라 생각한다.
기대하던 멤버십이 시작되었다. 마스터분들이나 운영진분들의 말씀대로 챌린지만큼 힘들지는 않지만 오히려 생각할 것들이 많아졌다.
챌린지에서도 상세한 가이드라인은 없고 전체적인 큰틀과 약간의 요구사항만 주어졌었는데
멤버십은 앱에 대한 최소한의 요구사항만 주어지고 각자만의 방식으로 미션을 해결하는 식이였다.
챌린지는 “집을 지어라. 벽돌을 사용하고 방은 3개가 필요하다” 와 같았다면
멤버십은 “집을 지어라.” 이렇게가 끝이였다.
마침 앱의 전체적인 설계를 해보고 싶었는데 좋은 경험이 될 것 같다.