[team-01][쑤, Isaac] ViewModel 구조화, 첫 번째 화면 구성

[okstring]

스텝별 작업 목록

• Alamofire 사용해서 네트워킹 및 JSON Decoding
• CollectionView를 활용해 메인 화면 구성
  • 구성을 잡고 가기 위해 먼저 First section만 구성
• CocoaPod을 사용해 의존성 도구 활용
  • Toaster, Alamofire
• Combine을 활용해 ViewModel - CollectionView 간 binding
• Caching 을 사용해 FileManager를 사용해서 캐싱 처리 예정

학습 키워드

• Alamafire
• Toaster
• Combine
• FileManager
• Cache
• CollectionView

고민과 해결(질문거리)

• 저희는 이번 미션을 진행하면서 가장 염두해두고 있는 부분은 View의 구현도 중요하지만 ViewModel, Clean Architecture의 구조를 제대로 알고 싶어 중간 PR을 일찍 보내드리게 됐습니다. 특히나 ViewModel, Binding 부분의 미숙함, UseCase와 ViewModel의 제대로 된 역할을 아직까지 명확하게 알고 있지 않아서 이런 부분도 의심을 해가며 코드를 작성하게 됐습니다. 아직 구조만 짰을 뿐 볼륨이 커지지 않은 상태라 각각의 계층에서 제대로 된 역할을 가질 수 없는 것 같기도 하지만 데이터의 흐름에 대해서도 고민을 했었고 전반적인 흐름에대해 조언을 요청드립니다 :)
• 요구사항에서는 셀을 표기할 때 이미 다운로드된 이미지가 있으면 표시하고, 새로운 파일이 다운로드 완료되면 해당 이미지를 테이블뷰 셀에 뒤늦게(lazy) 표시한다. 라고 명시가 되어있는데 lazy하게 표시하기 위해서 이미지를 lazy하게 불러오는 것이 저희가 작성한 흐름과 비교해서 맞는지도 의구심이 들고 있습니다.
• Error처리를 Network 단에서부터 ViewModel까지 계속해서 가지고 오고 있습니다. 보통의 에러처리와 비교해서 이렇게 긴 흐름을 가지는 Error도 맞는지 궁금했고 Error 처리를 하게되면 저희가 작성한 것 처럼 ErrorHandler를 통해서 화면에 일단 표시해두고 있는데 이런 흐름도 맞는지 궁금합니다.

부연 설명

• MVVM, Clean Architecture 패턴에 대해 참고한 자료

[okstring]

Image를 받아오는 흐름이 브랜치를 합치는 과정에서 유실된 것 같아 코드 추가 후 푸시드립니다 😅

[GangWoon]

저희는 이번 미션을 진행하면서 가장 염두해두고 있는 부분은 View의 구현도 중요하지만 ViewModel, Clean Architecture의 구조를 제대로 알고 싶어 중간 PR을 일찍 보내드리게 됐습니다. 특히나 ViewModel, Binding 부분의 미숙함, UseCase와 ViewModel의 제대로 된 역할을 아직까지 명확하게 알고 있지 않아서 이런 부분도 의심을 해가며 코드를 작성하게 됐습니다. 아직 구조만 짰을 뿐 볼륨이 커지지 않은 상태라 각각의 계층에서 제대로 된 역할을 가질 수 없는 것 같기도 하지만 데이터의 흐름에 대해서도 고민을 했었고 전반적인 흐름에대해 조언을 요청드립니다 :)

아래 그림을 보면서 공유해주신 링크를 다시 한번 읽어보셨으면 좋겠어요. 추후에 자세한 내용은 대화를 통해서 가이드 드리겠습니다.

요구사항에서는 셀을 표기할 때 이미 다운로드된 이미지가 있으면 표시하고, 새로운 파일이 다운로드 완료되면 해당 이미지를 테이블뷰 셀에 뒤늦게(lazy) 표시한다. 라고 명시가 되어있는데 lazy하게 표시하기 위해서 이미지를 lazy하게 불러오는 것이 저희가 작성한 흐름과 비교해서 맞는지도 의구심이 들고 있습니다.

"해당 이미지를 테이블뷰 셀에 뒤늦게(lazy) 표시한다. "
저화질 사진 보여주고 그 다음에 고화질 사진으로 갈아친다고 생각하시면 이해에 도움이 될까요?
이미지는 다른 리소스에 비해 사이즈가 크기 때문에 이미지를 전부 다운 받고 리스트를 갱신하기엔 제한적인 UX입니다.

Error처리를 Network 단에서부터 ViewModel까지 계속해서 가지고 오고 있습니다. 보통의 에러처리와 비교해서 이렇게 긴 흐름을 가지는 Error도 맞는지 궁금했고 Error 처리를 하게되면 저희가 작성한 것 처럼 ErrorHandler를 통해서 화면에 일단 표시해두고 있는데 이런 흐름도 맞는지 궁금합니다.

에러를 사용자에게 표시할 수 있는 순간에 보여주는게 가장 좋습니다. 그 흐름이 길이는 중요하지 않습니다.
에러라는 단어를 생각해보시면 프로그래머가 원치 않는 순간이란걸 확인하실 수 있습니다.
ErrorHandler를 사용해서 화면에 표시해서 사용자에게 보여주는건 좋은 흐름 같습니다.

---

구조에 대한 피드백은 토요일에 이어서 드리도록 하겠습니다.

[GangWoon]

statusCode를 사용하시지 않는데 프로퍼티로 작성하신 이유가 있을까요?

[lenaios]

statusCode를 내부 로직에서 사용하고 있지는 않으나, 위와 마찬가지로 API 응답 형태에 따라 decoding 하기 위해 작성했던 값입니다!

[GangWoon]

statusCode를 저장하지 않고도 가능한 작업이지 않나요?

[GangWoon]

사용하지 않는 값은 _으로 주석 처리해주시면 다른 사람이 코드를 읽는데 많은 도움이 됩니다.

[okstring]

추가로 궁금한 부분은 제외하고 말씀주신 피드백 반영해서 push 완료했습니다!
감사합니다 :)

[okstring]

오전에 피드백 주신 내용 수정 완료했습니다!
지금은 여러 고민해봤지만 reload하는 시점이 해결되지가 않았고(main쓰레드에서 load시 런타임 에러) 또 세션을 추가하게되면 구조가 달라질 것 같아 너무 지연이 될 것 같은 판단이 들었습니다.
일단 머지를 받고 다음 PR때 reload부분 보완하려 계획중에 있습니다
감사합니다 :)

[GangWoon]

@okstring @lenaios
피알을 수정하기 앞써 이번에 작성한 코맨트는 무시하시고 프로젝트를 진행하셔도 좋습니다.
더 이상 고칠게 없다고 판단하시면 스쿼시 머지로 부탁드리겠습니다.

코드를 보개되면 특정 부분에선 다음 줄을 공백으로 두고 넘어가거나 어떤 부분은 띄웠고 어떤 부분은 붙이는 식으로 코드가 작성되어있습니다.
현업에서 모든 코드가 하나의 컨밴션을 준수하는 건 아니지만 개인적으로 협업에 있어서 중요한 부분이라고 생각합니다. 앞으로 코드를 작성할 때 두분이서 의논하셔서 코드 컨밴션을 맞춰주셨으면 좋겠습니다.

클린 아키텍처를 반영하는게 많이 어려우셨을 텐데 다들 고생하셨습니다 :)

[GangWoon]

rawValue를 사용하시는 것보다
description 내부에서 switch문으로 분류하는 게 더 안전해보입니다.

[GangWoon]

image 타입이 string인데 뜻하는게 url에 더 가깝지 않을까요?

[GangWoon]

주석은 정말 필요로할 때 보통 사용합니다.
ex) iOS 14.0 부턴 api가 변경됨으로, 최소 버전이 14.0일 때 개선해주세요.
메소드 네이밍이 정말 어려운 문제지만 해당 메소드가 무슨일을 하는지 표현하는 방법도 연습하셨으면 좋겠습니다.

[GangWoon]

코드를 변경한 지금 TapToastGestureRecognize가 필요한가요?

[GangWoon]

data + "원" 이런 형태의 모든 부분에 뷰에서 작업하는 것보다 viewModel에서 만들어주고 뷰에선 할당만 하는 형식이 어떤가요? 라고 말씀드렸던 겁니다.