서론
네이버 부스트캠프 웹・모바일 8기 멤버십의 1주 차가 끝났습니다.
챌린지보다는 스케줄이 여유로워서 꽤나 괜찮은 일주일이었습니다.
이번 주는 1주차여서 그런지 아직까지는 크게 힘들지는 않았습니다. 하지만 앞으로도 이렇게 여유롭게 진행될지는 모르겠습니다.
더 어려운 과제가 주어지고 더 바쁜 스케줄이 기다리고 있을지도 모르니, 더욱 노력해서 잘 따라가야겠습니다.
네이버 부스트캠프 웹・모바일 8기 멤버십 회고부터는 기술적 고민을 함께 적으려고 합니다.
예를 들어, 확장성의 고민, 타입 고민처럼 Swift, UIKit, 설계 등의 고민일 거 같네요.
챌린지 때는 단순한 일기였다면 멤버십부터는 개발자로서의 성장을 위해 회고하려고 합니다.
다만 문단을 명확히 구분하진 않을 거예요. 일상적인 회고도 성장에 도움이 되니까요 ㅎㅎ
Git 연습
멤버십에서 Git은 매우 중요합니다.
과제 코드를 깃허브에서 관리하고 PR도 날리고 팀 프로젝트에서 협업도 하기 때문입니다.
그래서 1주차에 깃 연습을 병행했어요.
어려웠던 건 PR을 날리고 머지를 기다리는 동안 제 작업을 진행하는 거였습니다.
머지가 되면 그걸 다시 fetch 하고 작업을 합치는 과정이 많이 복잡하더라고요..
또 일부러 간단한 충돌도 일으키면서 해결해 봤는데 이 과정에서 플젝도 날려봤네요 ㅎㅎ;;
결구 짧은 시간동안 익숙해지진 못했습니다.
그래도 멤버십 기간은 기니까 다양한 시도를 해보면서 깃이랑 친해져야겠다고 생각했습니다.
코드 리뷰 선순환
멤버십에서는 3주차부터 현업 개발자의 코드 리뷰가 진행됩니다.
그래서 1, 2주차에 코드 리뷰 없이 지나가는 게 아깝더라고요.
문득 캠퍼들끼리 서로 코드 리뷰를 해주면 어떨까?라는 생각이 들었고,
수동적으로 누가 해주길 바라는 것보다 나부터 하자! 해서 친한 분들 위주로 코드 리뷰를 했습니다.
그리고 슬랙에 살포시 "캠퍼들끼리도 코드 리뷰를 할 수 있지 않을까요?"라는 메시지를 보냈습니다 ㅎㅎ..
너무 감사하게도 메시지를 보신 몇몇 캠퍼분들이 코드 리뷰에 동참해 주셨습니다.
자기 과제하기도 힘들고 벅차고 귀찮을 텐데 함께 해주셔서 너무 감사했습니다.
먼저 코드리뷰를 시작한 게 선순환이 되어서 뿌듯하기도 하고 멤버십을 함께하는 캠퍼분들이 너무 든든했네요.
멤버십 하길 잘했다고 생각한 순간이었고,
현업자 리뷰가 시작되더라도 쭉 이어지는 문화가 되었으면 좋겠습니다.
iOS 스터디 시작
iOS 스터디도 시작했습니다.
과제를 분석하고 몇 가지 주제를 정해서 학습한 뒤 공유하는 방식인데요.
겉핥기 학습이 아니라 딥다이브하는 습관을 들이는 게 목표입니다.
다음 주 월요일에 본격적으로 시작하는데 너무 기대되네요.
그리고 스터디원분들 대부분이 극효율주의 STJ더라고요..?
STJ 모임은 놀라울 정도의 효율이 나온다는 걸 느꼈습니다 ㅋㅋ
스토리보드 사용
그룹 활동에서 흥미로운 스토리보드 사용법을 들었습니다.
스토리보드에는 컴포넌트만 넣고 코드로 레이아웃을 잡는 건데요.
만약 적용한다면 아래 내용이 기대되었습니다.
- 컴포넌트 생성 코드가 줄어듦
- 생성과 레이아웃 관심사를 따로 관리함
- 어떤 컴포넌트가 있는지 시각적으로 볼 수 있음
근데 직접 사용을 해보니 흠....이었습니다.
- 컴포넌트가 생길 때마다 스토리보드를 편집해야 한다는 점
- 오토레이아웃에 필요한 translatesAutoresizingMaskIntoConstraints 설정 코드가 필요하다는 점
위 두 개가 불편한 내용이었고,
스토리보드의 단점과 코드 UI의 단점이 함께 느껴지는 경험이었습니다.
하지만 긍정적인 부분도 있었어요.
큰 틀만 스토리보드에 넣어서 변경이 안 되도록 하고,
뷰를 커스텀해서 translatesAutoresizingMaskIntoConstraints 등을 자동 설정하면 편의성이 크게 개선되겠다고 생각했습니다.
처음 기대했던 효과와 결과가 좀 다르지만 새로운 방식을 배웠다는 것 자체가 좋은 학습이었네요.
프로토콜과 제네릭
추상화에 대한 고민도 많았습니다.
구조체 + 프로토콜이 습관화가 되어서 객체지향적인 부분을 고려하지 못한 게 아닌가 생각을 해봤습니다.
생각해 보면 프로토콜도 단점이 존재합니다.
프로토콜 메서드는 동적 디스패치로 동작하고, 프로토콜에 선언한 변수는 private으로 사용하지 못합니다.
하지만 구조체로 다형성을 구현할 수 있다는 장점 때문에 필수적인 요소죠.
그렇지만 다형성을 구현하는 또 다른 방법이 있습니다.
바로 제네릭입니다.
만약 타입마다 알고리즘이 동일하다면 제네릭을 이용한 추상화가 더 적절할 수 있습니다.
예를 들어, Stack을 구현한다고 해봅시다.
Stack은 타입마다 pop, push 알고리즘이 동일하기 때문에 제네릭이 적절합니다.
protocol StackProtocol {
associatedType T
var items: [T] { get set }
func pop() -> T?
func push(item: T)
}위 프로토콜에서 items는 외부에서 접근 가능할 것이고, pop, push는 동적 디스패치로 동작할 것입니다.
반대로 제네릭을 사용한다면 items 배열은 private으로 설정할 수 있고, pop과 push는 정적 디스패치로 동작합니다.
디스패치 동작은 크게 와닿지 않을 수 있지만, 접근제어자 설정은 치명적입니다.
스택의 items에 직접 접근하면 스택의 본질을 흐릴 수 있기 때문입니다.
이렇게 같은 추상화, 다형성이라도 여러 방면으로 고민해야 한다는 것을 배웠습니다.
다음 주부터는 OOP, POP 사이에서 적절한 선택을 할 수 있도록 많은 고민을 해야곘습니다.
끝나지 않는 Jeongfisher 버그
마지막으로 Jeongfisher 내용을 얘기해 보겠습니다.
이번 과제에서 Jeongfisher를 사용해 봤습니다.
이미지 캐싱이 필수는 아니었는데 억지로 써봤어요 ㅋㅋ
근데 이 짧은 순간에 버그를 또 발견했지 뭐예요..?
심지어 두 개나..? ㅎㅎㅎㅎ
첫 번째 버그는 placeholder 대기 시간이 설정되지 않는 거였는데요.
Task 안에서 Timer를 fire를 시킨 게 원인이었습니다.
이건 DispatchWorkerItem을 사용해서 해결했습니다.
두 번째 버그는 상당히 골치 아프고 해결법도 잘 모르겠습니다.
CollectionView에서 같은 URL을 여러 셀에서 다운로드하는 상황입니다.
cell의 didEndDisplaying이 호출되면 다운로드를 cancel 합니다.
download -> cancel -> download -> cancel이 반복되면서 이미지 다운로드가 안 되는 겁니다..!
- CollectionView가 아니거나
- cancel을 시키지 않거나
- 다른 이미지 URL이라면
문제가 전혀 없는데 위 시나리오에서 버그가 발생합니다.
어떡하면 좋을까요? ㅋㅋ
킹피셔의 로직을 그대로 옮기는 게 좋을까요?
하지만 이미 너무너무 달라서 그게 가능할지도 모르겠습니다.
참 씁쓸한 마무리네요 ㅎㅎ;; 차근차근 시간을 들여서 고민하고 고쳐봐야겠습니다.
미무리
이번 회고도 얼렁뚱땅 마무리가 되었네요.
다음 주는 1주 차보다 훨씬 바쁠 것으로 예상됩니다.
스터디도 하고, 과제 명세도 공개되고, 개선도 해야 해서요.
1주 차보다는 더 깊고 넓은 고민을 해서 성장해 보겠습니다.
감사합니다.