Week01‐멘토링 일지

✔️ 결론 및 To Do

• 멀티 모듈 사용하기
• MVVM 사용하기
• 기획을 좀 더 상세히
• 테스트 중요한 것만

✔️ 멘토링 아젠다

• 프로젝트 소개

  1. 프로젝트 주제

     • 사용자가 꿈을 기록하고 해석하며 꿈에 관한 이야기를 다른 사람들과 공유할 수 있는 서비스

  2. 우리 서비스의 기능

     1. 로그인
        • Firebase Authentication
     2. 꿈 기록 및 분류
        • ROOM
        • Firebase
     3. 꿈 해석 도움
     4. 공유하기
        • Retrofit
     5. 알림 기능
        • Local Notification
        • FCM

  3. 개발 일정

     

• 프로젝트의 매력?

  1. 기능적으로
     1. 오프라인 상태에서 일기를 쓸 수 있다.
     2. 동기화 기능이 있다.
     3. 작성한 일기를 간편하게 공유할 수 있다.
  2. 기술적으로
     1. 동기화(오프라인에서 온라인으로 바뀌었을 때라던가)
     2. 꿈 일기의 내용에 글과 이미지를 함께 저장할 수 있다.
  3. 경험적으로
     1. 모바일 접근성
     2. 다양한 기기 대응

• 프로젝트 관리는 어떻게 하나요? 선택한 이유는 무엇인가요?

  • And01-DreamDiary Project
  • github의 project 기능을 사용하였습니다.
  • issue를 label을 이용해 , Epic / Story로 구분하였습니다.
    • Epic: 큰 단위의 기능( 로그인 / 일기 )
    • story: 특정한 가치를 제공하는 작업의 단위 ( 로그인 화면 구현 / 로그인 api 연결 )
  • milestone을 이용하여 epic과 story의 연관관계를 설정 해주었습니다.

• 협업은 어떻게 하나요?

  • zep을 이용해서 재택 근무를 합니다. (멘토님도 심심하시면 놀러오세요/ 다른사람은 오면 내쫓습니다)
  • slack workspace를 따로 파서 github에 PR이 올라올 시 알림이 오도록 했습니다.
  • 2명 이상이 코드 리뷰 진행 시 dev branch로 merge가 되도록 했습니다.
  • 현재는 각자 공부할 주제를 정해서 발표하는 식으로 진행하고 있습니다. → 이 부분은 모르는 분야가 나올 때마다 앞으로 계속 진행할 것 같습니다.

[and01 | 쉽고 재미있는 메타버스 ZEP](https://zep.us/play/EggB55)

논의 사항 및 질문

• 멘토님은 왜 이렇게 멋있으신가요?

• 멀티모듈을 도입하려하는데 도입하면 복잡성이 올라가서 개발의 진전이 오히려 늦춰질 것 같습니다. 멘토님은 멀티모듈의 도입 시점을 언제로 생각하시나요?

  • 빌드로직 + a

• MVI

  • MVI를 사용하면 OCP 원칙에 어긋난다는 생각이 들었습니다. 예를 들어서 Intent에 추가를 하면 viewmodel에 when 조건문이 추가되어야 했습니다.
  • 단방향 강제: 복잡도 감소
  • 단일 상태 관리(UIState): 상태 관리가 명확
  • 테스트 용이: Intent와 Model의 비즈니스 로직이 명확히 분리되어, 단위 테스트와 통합 테스트가 쉽다.
  • 그렇다고 해서 Intent에 로직을 처리한다고 하면 MVI 패턴에 맞지 않다고 생각이 들었습니다.
  • 질문1: 현업에서는 무슨 패턴을 사용하시나요?
  • 질문2: MVI 패턴에 대해서 어떻게 생각하시나요?

• state class

  • exception handling 부분에 대한 방법

  suspend fun <T> safeApiCall(
      apiCall: Response<T>
  ): Result<T> {
    try {
      val result = apiCall()
  
      if (result.isSuccessful) {
          return **Result.success**(result.body())
      }
      return Result.failure(Throwable(result.message()))
    } catch (throwable: Throwable) {
      return Result.failure(throwable)
    }
  }

  • Result 쓰는 것 or 만들어서 쓰는 것
  • runCatching

진행상황 및 참고 자료

피그마

https://embed.figma.com/design/p2ChI1lMCpQfqflBCPCV2K?embed-host=notion&footer=false&theme=system

✔️ 멘토링 내용

• 발표 시작할 때 서론을 먼저 말하기, 우리가 이 주제를 왜 선택했는지 짤 등을 활용
• MVP
  • 상세화면에 대한 기획적 부분 구체적으로 작성
    • 태그
    • 이미지 - 왜 필요한가
  • 꿈 해석 도움
  • 알림 기능
    • 로컬 알림 기능에 어떤 기능이 있을지 상세히
    • 푸시 알림을 누르면 어떻게 해야할 지
• 협업의 방법
  • 하나의 기능을 같이 하면 리뷰하기 좋지만 충돌이 일어날수 있다.
  • 각자의 기능을 하면 리뷰내용이 길어진다.
• 테스트를 시작을 하는 것은 역효과가 날 수 있다.
  • 테스트를 하면 3주뒤엔 주석이 될수 있다...
  • 테스트는 좀더 고민해보고 어떻게 할지...
  • 만약한다면 어떤부분을 테스트할지 구체화하는게 좋다.
• 요즘 시대에 오프라인이 과연 적절할까?
  • → 로그인 없이 익명 상태에 저장
  • 여러 디테일한 처리들이 필요해서 어려울 수도 있다.
  • 로그인 x 사용하는경우 설득이... 된다!
• 공유기능
  • 뭐가 매력적인거임? 당연한 기능 아닌가? → 좀 더 당위성 적기
• 우리 서비스의 핵심적 기능 온라인 vs 오프라인 vs 반반
• 기술을 리스트/표로 나타내서 한 눈에 보여주기
• 경험
  • 만들면서 어떤 경험을 할지
  • 다양한 기기 대응: 태블릿으로 접속하면 ui가 다이나믹하게 바뀌나? 어떻게 생각하나
• 멀티 모듈
  • 모듈화의 개념
  • Gradle Kotlin 컨벤션 플러그인으로 효율적으로 멀티 모듈 관리하기
• MVI
  • 장점
    • 의도를 명확하게 전달하는데 도움이 된다.
  • 단점
    • 작성해야할 코드의 양 증가
  • 사용
    • mvi도 많이 사용
    • mvvm이 제일 많지만
    • mvp쓰는 회사도 있다.
    • 토스의 mvw 뭘써도 상관 없는것
    • 다양하게 쓴다.
    • 대부분은 mvvm
    • 직관적이여서 좋지만 보일러플레이트가 많아서…
    • 개인적으론 잘 쓰지 않는다.
    • 하지만 의도가 명확한다는것에서 쓰는사람이 있다.
• 에러 핸들링
  • 에러 핸들링 다 맞는 방법이다.
  • 편한 방법을 사용해라, 잘못만들지 말고 올바르게 만들어서 사용해라.
• Compose
  • 컴포즈에대한 일정, 트러블슈팅
  • 컴포즈 사용한지 1년반
  • 매력적인 요소를 느끼고 있다. 직접적으로 좋은점을 느껴서 쓰고 있다.
  • 개인적으로는 디자이너의 요구를 구현하는데 있어 컴포즈로 했을때 더 퍼포먼스적으로 좋다.
  • 한다면 그에 대한 히스토리를 잘 남겨달라
• 꿈 일기를 스크럼에 기록해보기 → 이 내용을 데이터베이스에 올리자!!

✔️ 체크리스트

• 프로젝트 기획과 설계의 뼈대가 나왔다.
• 프로덕트 backlog가 제작되었다.
• 서비스 핵심 기능에 대한 완성도의 기준 또는 기술적 목표가 수립되었다.
• 현실성 있는 계획이 수립되었다.