221118_스크럼

스크럼

오후 스크럼

• 병학

  • MVVM-C 각 클래스 별 역할 지정하기

    • Coordinator?
    • M / V / VM / C
    • 11.20 오후

  • 다음주 스프린트 지정하기

  • MyProfileViewController의 coordinator 변수 주입을 못했다

  • 문서화

• 동은

  • 회고록 작성 목록을 통일하면 좋을 것 같다.
    • 좋았거나 개선된 점
    • 아쉬웠거나 문제였던 점
    • 개선할 점
  • 스크럼 작성 목록도 마찬가지
    • 오전스크럼
      • TODO
      • 논의할 내용
    • 코어타임 논의 사항
    • 오후 스크럼
      • 공유할 내용
      • 논의할 내용

• 준영

  • MyProfile Coordinator가 TabBarCoordinator에 통합했는데, 마이프로필에서 앱 설정, 프로필 설정으로 넘어가지 않는 문제 파악

• 문제-상황-&-Discussion

주차 회고

좋았던 점

• UI를 빨리 구현해서 데모영상을 보여주기 편했다
• 깃헙 컨플릭트가 크게 나지 않은 점
• 코디네이터나 mvvm 등에 잘 이해하지 않고 이야기를 해보니, 이에 대한 이해가 부족한 것을 깨닫고, 프로젝트와 공부를 위해 확실한 공부가 필요한 것을 배운 것 같습니다. 태스크는 잘 분리가 되었던 것 같습니다.
• 스프린트에서 기획했던 대로 작업 대부분을 해결할 수 있어서 뿌듯했습니다.
• 코드리뷰가 활발하게 되서 서로 발전할 수 있었던 것 같다.

아쉬웠던 점

• 토론한 내용 양에 비해 문서화된 결과가 적었던 점이 아쉬웠고, 문서화에 더 신경쓰기로 했다.
• 미리 UseCase나 Entity 설계가 명확하게 되지 않아 아쉬운 것 같았음. 멘토님도 비지니스 로직에 좀 더 신경쓰는 편이 좋다고 하셔서 다음 주에는 비지니스 로직을 들어 갈 것 예상
• MVVM-C에 대한 이해가 팀 전제적으로 필요했다. → 일요일 오후 8시~10시 개념 정리 하는 시간을 갖기로 했다.
• 비지니스 로직을 배재하고 코드를 작성한것이 아쉽다.
• 시작하면서 Clean Architecture를 공부하고 시작했지만, 여전히 개념 이해가 잘 되어있지 않은 것 같다.
• 문서화하는 습관이 아직 길러지지 않은 것 같다.

멘토링

질문

• cocoapods-binary-cache → 이것 때문에 1.5일 날렸습니다

  • 파이어베이스을 prebuild 할 때 에러가 나서 캐시를 사용할 수가 없었습니다.
  • 말고 다른 방법이 있을까요?
    • cartage

• private let VS private lazy var

  • 타이밍
  • 병학- lazy var는 self를 쓰지 않으면 효과가 크지 않다고 생각함
  • 참고자료
    • https://seungchan.tistory.com/entry/Swift-SnapKit에서-lazy-var-와-let
    • https://sunggweon.dev/TIL/swift/lazy_var.html
    • https://baked-corn.tistory.com/45
  • 메모리를 아낄 수 있지만, thread-safe 하지 않음
    • 하지만 큰 의미가 없다.

• 멘토님은 개발 과정에서 생기는 이슈를 문서화할 때 어떤 방식으로 하시나요?

  • 규모가 작으면 PR에 남김
    • commit에 리뷰가 가능하도록 내용 남기기
    • Review note
  • 규모가 크면
    • tech spec
    • TDR
    • 1 pager

• View에 나타나야할 label, textfiled들이 많지만 재사용할 부분이 없다면 따로 view를 만들어서 VC에 추가하는 방법이 별로인지 궁금합니다.

• Clean 아키텍처에서, UseCase 리턴 값으로 Observable 같은 RxSwift 프레임워크에 해당하는 타입을 반환하는 케이스를 만든 경우를 많이 보았는데, UseCase와 Entity가 외부 프레임워크에 의존받지 않아야 한다고 생각합니다. (테스트와 여러 플랫폼에서 쉽게 탑재하기 위한 목적이 있다고 생각합니다)

  • UseCase가 외부 프레임워크(RxSwift)에 의존하고 있어도 되는가?
    • utility function이라 생각하고 사용할 수 있지만, combine pulisher나 async-await을 사용할 수 있음. 비동기 처리는 도메인과는 무관하여 넣을 수 있음.

• FirestoreService

  • 파이어 스토어는 파이어 스토어만 바라 볼 수 있도록 firestoreservice 메서드 작성
  • repository의 datasource를 갈아끼울 수 있게 하기 편하게 할려면 어떻게 하면 좋을까?
  • SRP를 위반하는 객체다.

• Single은 의미가 없다

  • Single
  • Completable이 나을 수 있다

• 레이어 별 정의에 대한 이해 필요

• observable은 스트림이라 한번만 써도 되는 경우는 trait 사용 권장. single (verifyuser는 한번만 사용 하므로completable 활용 가능)

• 도메인과 비지니스를 먼저 하고 ui를 나중에 함. 나중에 ui를 바 수 있는데, 디자인 사용성 점검인나 벡엔드 구현이 느리면, 뷰컨이나 깡통을 만들기도 함. 요새는 피그마로 바로 넣어볼수 있어, ui를 나중에하고 도메인을 먼저 다 만들고, repository에 json 반환시킬 수 있음.

• 슬라이더나 피커 결정은 개발자가 하나 디자이너가 하나 (ios는 컴포넌트가 회사에 이미 있어 디자이너가 자체적으로 하는데, 작은 회사는 컴포넌트가 없어 엔지니어도 의견 냄)

• usecase는 도메인 영역 (안드로이드 문서가 비슷한게 많으니 그것 참조 권장) 도메인은 비지니스 로직의 캡슐화 (재사용: verb + what/명사, 하나의 역할, 화면에 종속적이면 안됨). 재사용이 안되는 것은 안 만들어도 됨. 화면에 의존적이지 않게 쪼개서

• 테이블뷰보다는 컬렉션 뷰를 많이 사용 (compositional layer가 잘 만들어져서 테이블뷰를 그걸로 할 수 있음)

• 컬렉션뷰 가로를 고정하는게 어렵고, 그렇게 되면 높이 계산이 어려움. 가로가 결정되면 높이를 자동으로 계산하자고 나온게 테이블 뷰.