GiftHub : `23. 6. 17. 10:00 이태우 멘토님 정기 멘토링

Created by 정인희, last modified on 6월 19, 2023

말할 거 정리

  1. 멘토링 방식 의논

    1. 오프라인/온라인

    2. 빈도 수

      1. 스프린트 1주 vs 2주

  2. 거래 방식 확정한 거 말씀드리기

    1. 에스크로 기반의 결제방식을 제공한다.

    2. 기프티콘을 구매하자마자 기프티콘이 보이게 하지 않는다.

      1. 참고자료 - 버거킹

직원확인==구매확정 버튼을 눌러야 판매자에게 대금이 송금이 되도록 한다.

c. 사용하기 직전에 쿠폰이 보이게 하고, 쿠폰이 유효하지 않을 시에 거래를 파기한다.

d. 악의적인 구매자가 쿠폰을 정상 사용하고도, 구매확정을 하지 않거나, 판매자를 대상으로 신고를 할 경우, 쿠폰 받기 버튼을 통한 바코드 조회 기록과, 기프티콘 사용 기록(사용처에서 확인할 수 있음) 으로 악의적 구매자 증거 확보가 가능하다 생각

3. 한 주 동안 한 거 보고

a. 정보 구조도 → mvp 기준을 어디까지 설정했는지 보고

b. ERD - 피드백

c. API 명세서 - 피드백

d. OCR 기술 검증

https://jinu0137.github.io/development/2023-06-16-React_Native-Google_ML_Kit_Text_Recognition_v2_API/

4. 다음 주 스프린트 계획

멘토링

스프린트 회고 방식

  • 회고를 같이 해도 되고, 회고 한 것을 같이 봐도 됨(방식을 정하기)

  • 정보구조도

    • 양방향은 봤을 때 헷갈리므로, 수정하면 좋을 것

    • 핀번호가 뭐에 쓰이는지 설명 넣을 것

      • 이것보다 간결한 경우로 id가 전화번호가 되도록 할 수도 있음

      • 사업자등록 때문에 본인인증을 바로 넣을 수 없을 수 있음

    • 기프티콘 검색은 지금 당장 안 넣어도 됨

    • 그쪽 산업에 대한 이해가 필요

      • 매입을 할지 등에 대한 이야기도 필요

    • 위치 정보 저장-> 지금은 빼도 괜찮을 것 같다

      • 시럽 어플이 잘 되고 있는지 자료조사 필요

      • 개인 사업자 필요할 수도

      • 위치 기반을 상점을 어떻게 할 건 지가 설명이 안되어 있음

      • 와이어 프레임을 그려보다 보면 확실해 질 것

      • 위치기반 뷰를 어떻게 보여줄 건지도 생각해야함

      • DB를 어떤 걸 선택할 지가 고민이 될 수도

        • PostgreSQL vs MongoDB

        • DB 선택에 대한 이유를 문서로 남기는 것 중요

    • 버전 정보

      • 오픈소스 라이센스 작성

      • 도메인 구입

      • 구글 계정 만들 수 있음(재료비로 처리 가능한지 알아보기)

    • 알림

      • 알림 내역에서 나눌 필요는 없음

      • type별로 필터를 할 수도 있음 (MVP에서는 고려X)

    • 금액/잔액 확인

      • 지금은 안해도 될 것

    • 관리자 기반의 정보구조도 필요(일단 사용자 기반 먼저하고 생각)

      • 유저 별 보유하고 있는 기프티콘 목록

      • 기프티콘을 사용처에 대한 위치기반 정보

  • MLKit - RN vs Kotlin

    • react-native-ml-kit

      • 오픈 소스를 가져와서 fork떠서 우리가 만들기

      • 기존 레포가 이상함

  • ERD

    • user

      • 전화번호

        • PASS 인증 붙이며 나오는 값으로 전화번호를 저장하게 되면 실명인증의 dependency가 붙긴 함

      • 문자 인증 방식 → 판단 필요

        • PASS vs firebase

      • user가 조금 빈약

    • notification_type

      • 국제화를 고려했을 때 현재처럼 하면 좋음

      • 하지만 상황에서는 enum으로 들어가도 될 것

        • enum을 사용하지 말아야 할 이유에 대한 의견

          • 옛날 자료, 테이블을 따로 빼는 것은 별로

        • enum set

          • array 타입을 지원을 함

        • 테이블 따로 빼지말고 enum으로 수정하기

        • notification 이랑 notificaton_type이랑 합쳐도 될 것

      • notified_at을 created_at이라고 하고 checked_at을 만들고 checked_at이 null 인경우를 false를 리턴하게 해 virtual variable 을 만들 도 있다는 것 참고

    • messeage VARCHAR로 하면 안됨 → TINYTEXT or TEXT

    • usage(General 한 이름임) → voucher_usage_history

      • _history(컨벤션): 암묵적으로 insert만 한다는 표식

    • expired_at

      • 바우처.expires_at

      • 시점까지 고려하면 좋음

    • brand(이름 조금 애매)

      • image->image_url

      • 특정 카테고리를 다루지 않는 brand가 있거나 한 brand가 여러 카테고리를 다룰 경우엔 어떻게 할 것인가?

        • 바우처랑 Product 관계를 잘 고려해 보기

        • brand 카테고리, product 카테고리 따로따로 가져가도 됨

      • 큰 단위 명사_작은 단위 명사 라고 많이 표현

    • Relation 을 어떻게 잡았는지에 대한 기준이 잘 있어야 함

      • ManytoMany 관계가 들어갈 것만 잘 생각하면 좋다.

    • n+1 문제

      • voucher 사용 여부: Status Code없이 history 테이블을 다 가져와야 하는 상황

      • 정규화를 빡세게 하면 퍼포먼스가 저하됨 → 반정규화 고려

      • history를 다 가져와야 함

      • 반정규화

        • ManytoMany 관계가 아닌데 조인을 두 번해야 하는 경우 고려해 볼 수 있음

스프린트

  • 보통은 2주이긴함

  • 현재는 서로의 일정 산정이 모호해서 1주가 좋음

  • 기능이 얼마나 걸릴 까에 대한 고민에 따라 스프린트 주기가 정해짐

  • 이번 주 까지는 끝낸다는 범위가 있어야 함

  • Time 이 어느정도 걸릴건지가 이야기가 되어야 함

  • 하루를 8시간으로 잡고 할 일을 쪼개도 됨

  • 공부할 것도 스터디도 Task로 넣어도 됨

멘토링

  • 팔로업만 될 수준

  • 회고에서 lessen-learn 이 없다면 회고를 없애도 됨

  • 일을 위한 일을 하지말자

  • 회의실 예약 부분

    • 미리 잡아놓아도 됨

  • 정기적으로 하는게 좋긴함

    • 할 말이 없을 경우엔 2주에 한번

  • 자기 공부할 시간이 필요함

  • 토요일 오전 10시를 매주로 할지 격주로 할지 다 정하고, 오프라인 온라인도 월 초에 다 정하면 좋다.

다음 주 Todo

  • 한번에 Navaigation 되는 설명하는 페이지가 필요함(깃 레포 추가하면 좋다.)

  • 스토리 보드

  • 도메인 구입

  • 상표권(로고디자인이 나오면, 셀프로 해도 괜찮)-> 센터 지원 되는지 확인 해보기

  • 회고하고 나서 공유만 하기(이해안되는거 개념같은거 이야기 해도 됨)

Attachments:

image-20230614-133651.png (image/png)
image-20230614-133716.png (image/png)
image-20230614-133651.png (image/png)
image-20230614-133716.png (image/png)