백로그 구체화, 프로젝트 구조 설계

Jump to bottom

천일영 edited this page Dec 1, 2024 · 1 revision

📝 회의 주제

🌟 주제 1: 스프린트별로 백로그 상세 작성

🌟 주제 2: 프로젝트 셋팅 관련 백로그 추가하기
- 패키지 구조 정하기 및 모듈화 셋팅
- CI 적용 해두기
- 필요한 라이브러리 추가
- // 베이스 컴포넌트 작업
- Pr rule, commit에 이슈 번호
- Pr 템플릿에 issue num
- github.com

💬 주요 논의 내용

1. 주제 1: 스프린트 1주차

같이 할 부분

패키지 구조 / 메인 컨텐츠 파일
- :feature
  - :login✅
    - LoginScreen.kt✅
  - :main✅
    - presentation
      - NotificationScreen.kt✅
      - MainScreen.kt✅
  - :study✅
    - presentation
      - CreateStudyScreen.kt✅
      - StudyDetailScreen.kt✅
  - :category✅
    - presentation
      - CreateCategoryScreen.kt✅
      - CategoryScreen.kt✅
  - :quiz✅
    - quiz
      - presentation
        
        QuizScreen.kt
        
        QuizResultScreen.kt
    - question
      - presentation
        
        CreateQuestionScreen.kt
        
        QuestionScreen.kt
        
        QuestionDetailScreen.kt
- :app✅
- :core
  - data✅
  - domain✅
  - designsystem
    - custom-theme 여기 두면 될까요? 🤔
    (공통적으로 사용되는 UI composable)
    - ui
  - custom-theme 여기 두면 될까요? 🤔
  - navigation (모르겠음) - 논의해보기
- UI
  - 로그인 UI
  - 메인 UI
  - 스터디 생성 화면

해야 할 부분

cloud fireStore db 스키마 확인
- 추가로 firestore 직접 안 해봤으면 간단하게 해봤으면 좋겠습니다. 🙏 (하루를 투자해서 X / 간단하게 / 여유가 없다면 고민이라도) (비동기랑 콜백이 생각보다 어렵습니다. 값을 가져왔지만 UI에는 보여지지 않는…)
  
  → group_id를 비동기로 받아서 그 결과를 다시 비동기로 group정보를 가져오는 것을 어떻게 구현할 것인가? await() 사용?
  
  → 만약에 addSnapshotListener를 데이터 레이어에 달아준다면 생기는 문제는?
  
  → 저희는 뷰모델에서 값을 가져오는 것이 아니라 데이터 레이어에서 가져와야합니다.
  
  → 레퍼지토리는 생명주기가 앱에 따라감. 그리고 싱글톤
https://firebase.google.com/docs/firestore/query-data/queries
프로젝트 셋팅
- 멀티모듈 - 유리님
- compose - navigation : 일영님 or 유리님
- Custom Theme - 유리님
- CI 셋팅 - 훈님, 지훈님
- 필요한 라이브 추가
  - hilt
  - compose-navigation
  - firebase
- closed #(이슈 번호) pr 템플릿에 추가 ✅(영민님)
commit 컨벤션 수정✅ (github wiki 컨벤션 페이지에 넣을 것)
- feat: 로그인 UI 작업 (#123)

주제 2:
- 🔸 논의 사항 1:
- navcontroller 관리를 call back으로 받아 navcontroller가 정의되어 있는 레벨에서 바로 관리하도록 하는 방법 or navcontroller를 내부 컴포넌트는에 위임시켜서 컴포넌트가 직접 핸들링하는 방식중 뭐가 더 효율적인 경우가 있나요?
→ 재사용성 기준으로는 stateful인우 lambda 표현식을 사용하는게 좋다.
- 🔸 논의 사항 2: [세부 내용]
- ✅ 결론: [결정된 사항 또는 추가 논의 필요 여부]
주제 3:

noti가 바뀌면 user를 다 건드리게 된다.

notification에 userid 를 넣는 방향으로 생각해보기

사이에 테이블을 추가하는 방법도 있다.

userid가 아닌 통신용 id 생각하기

멘토님 피드백

Q : user와 group에 따로 빼는 테이블은 group_id,user_id만 갖는 테이블만?

A. yes, 그룹의 확장성을 따져 봤을 때 애매하다는 느낌이 있다. 지금은 굳이? 라는 생각이 듭니다.

확장이 필요한 경우는 그룹과 유저 id만 갖는 테이블을 만들어서 관리하는 것이 좋습니다.

카카오톡 기준으로 minSDK를 조절해보자!

→ android9로 잡으세요~ 너무 옛날 버전으로 잡을 필요는 없다.

위에서 타고 내려가는 방향으로 실행시켜보면서 내려갈 수는 있다.

푸쉬 알림 같은 경우는 후순위로
코드 컨벤션 (ktlint github action적용)
pr 규칙 고민해보기
추천은 xml과 compose를 병행하는 방향을 고민해보기

-> 동시에 사용했다는 흔적을 남기기

퀴즈 다음 페이지에 viewpager 써보는 것도 좋아 보인다.
Material를 커스텀해서 쓸거면 primary, onprimary.. 등을 직접 값을 만들고, 매핑해서 써야 한다.. (한달 봅니다)

🏁 결정 사항

🚩 결정 1: Compose로 쓰기로 결정, 푸쉬 알림 같은 경우는 후순위로