221115_스크럼_회의록

오후 스크럼

진행상황

• 준영: 온보딩 ViewModel, Usecase제작 및 테스트. UseCase를 넣어보는 게 더 좋음
  • 피드백
    • 구조체 대신 클래스로 (의존성 주입은 메모리 참조로 연결하는데 클래스가 적합)
    • 애플 로그인 버튼 (safelayout bottom에 붙이기)
    • 코디네이터에서 메소드를 이용해서 php피커를 프레젠트하기
    • DIContainer에 테스트 관련한 UseCase, Repository 등을 만들어내는 메서드 추가
  • Todo
    • DIContainer와 Coordinator 만들 계획
• 영욱: 채팅 목록 화면 Repository, UseCase 작업 중.
  • Todo
    • 클린 아키텍쳐 구조와 rxswift ,mvvm 내용을 이해하면서 진행 할 계획
• 창묵: 클러스팅 기능 구현 - 마커: Annotation 2+ 1 제작 (오픈, dm, 클러스터링)
• 동은: 채팅방 생성 화면 PR.
  • 피드백
    • 채팅방 화면 생성 버튼은 맨 밑(safelayout)에 붙이는게 나음
    • 채팅방 생성화면 슬라이더) 현재 설정한 거리와 최대/최소거리 글자 구분되게 처리 (폰트, 글자색)
    • 한 화면에서 Corneradius는 전부 통일하는게 보기 좋음
  • Todo:
    • 뷰모델 구현
• 병학: Firebase 추상화 중
  • Todo:
    • 로그인 관련 기능 내일 중으로 완료 예정
    • RxSwift 세미나

회의 안건 결과

클래스 내 변수를 접근할 때 self를 쓸지 말지 통일이 필요

클로저에 순환 참조 방지 위해 어차피 self 써야하므로 쓰는 것이 나아 전부 self 사용 결정

모든 변수에 타입 명시

SwiftUI 프리뷰 포함하여 프로젝트 컴파일 속도 빨라짐 (타입 추론이 들어가면 느려짐) → 모든 변수에 타입 명시 결정

final 키워드

많은 리뷰어님들의 코드 리뷰에도 많았던 사항이고, 상속 불필요한 클래스 앞에 final 키워드 붙여 런타임 성능 향상 (Static Dispatch)

Coordinator 프로토콜을 Single, Multiple Child Coordinator로 분리

Coordinator 프로토콜 계산 프로퍼티 중 var childCoordinators: [Coordinator] 프로퍼티가 있음. Child가 여러개 필요한 경우 (모달 쓰는 한 화면에서 2개의 VC가 필요함) 실제로 프로젝트 해보면, 하나만 필요한 Coordinator(채팅방 리스트에서 채팅방 들어갈 때 VC는 1개만 필요)도 많아 Child Coordiantor가 하나만 필요한 것과 여러개 필요한 Coordinator를 각각 Single, Multiple Coordinator로 분리 제안 (by: 병학)

어차피 Child Coordiantor가 하나만 필요하면, 그냥 배열에 하나만 넣으면 되고, 그러면 Protocol을 하나로 통합해서 사용 가능. 배열 쓰는 이유는 어떤 VC가 추가로 필요할 지 모르기 때문에, 확장성을 포기하면서 까지 굳이 프로토콜을 나눌 필요는 없음 (by 창묵)

→ 프로토콜을 분리하지 말고 기존 그대로 유지 결정

PHPickerViewController vs UIImagePickerViewController

PHPickerViewController에는 이미지 crop하는 기능이 없고, UIImagePickerViewController에는 있음.

PHPickerViewController에 직접 이미지를 Crop하는 UI를 만드는 것을 제안 (by 병학)

→ MVP 까지 시간이 없으니, 차후에 선택으로 구현할 계획으로 두고 UIImagePickerController로 만들것을 결정

이미지 선택 기능

동은 & 준영은 현재 프로필 이미지 선택하는 기능이 필요한데, 코드 중복 방지를 위해 동은님이 먼저 만들어서 서로 같이 공유하기로 계획했지만, MVP 까지 기다리기가 시간이 부족함. → 각자 알아서 구현하는 것으로 결정

---

오전 스크럼

어제 오후 스크럼 이후 추가한 항목

• 준영: 어제 마이 페이지 화면 작업 후, pr 전송
• 영욱: 친구 목록 작업만
• 동은: 프로필 상세화면, 채팅 생성 화면 대략적으로 마무리. Layout 문제가 있어서 pr을 못 함
• 창묵: cherry-pick을 이용한 브랜치 관리 (브랜치에서 원하는 커밋만 복사해와 새 브랜치에 집어 넣음 - 마치 케이크에서 체리만 골라 오기 처럼)
• 병학: 런치 스크린 MVVM-C 코드 추가 작성

코드 리뷰

• 다음날에는 전날과 겹치지 않게 리뷰어 2명을 본인이 랜덤으로 골라서 골라서 리뷰 요청. 12시 이전까지. 13 시 이후에 알아서 하기. 다음 주에 멤버는 리셋: 이번주만 이렇게 해보고, 문제가 있으면 다음주 월요일 회의때 다시 의논하기로.
• 씬 단위로 구현 작업이 끝날 때, feature → develop에 merge
• 자기 브랜치 대신, develop에 머지 (리뷰가 끝나면) (안그러면 close 이슈번호 실행 안됨)
• PR 마일스톤 설정하기

Todo

• 준영: (온보딩, 마이프로필, 프로필 수정, 앱설정)뷰모델, 코디네이터 (알람, 로그인은 내일로 연기)
• 영욱: (채팅방 목록) MVVM 모델로 코드 나누기, 코디네이터 생성
• 동은: 프로필 사진, 채팅방 사진 선택을 위한 PHPickerVC, 추후 업데이트
• 창묵: ChatRoom 더미데이터 작성, Clustering Annotation 기능 구현
• 병학: Firebase 내일 마무리 예정, RxSwift 자료 작성

이슈 생성

코디네이터,mvvm, dicontainer 등에 대한 작업은, 본인이 알아서 이슈 추가해서 작업하는 것으로

기타

영욱님 2시까지 병원에 계셔서 연락 불가능.

PR Close

resolved #이슈번호 명시.