2주차 멘토링 회의록

2주차 멘토링

week2 멘토링 일지

→ 사전에 질문을 작성할 예정입니다.

✔️ 아젠다 및 질문

멘토링 아젠다와 멘토에게 하고 싶은 질문을 사전에 준비합니다.

• 공통
  • 안드로이드와 서버의 데이터 문제 → 각자의 의견 작성
    • 세찬
      • 로컬의 데이터가 메인이라고 생각했고, 일정을 우선 로컬에서 생성하고 추후 데이터를 업로드 하는 방식을 생각
      • 하지만 A 데이터가 서버에 올라가도 그 데이터를 다시 받아왔을때 로컬의 데이터와 정합성이 일치하는지를 주장할 수 없기 때문에, 로컬에서 id를 붙여서 올려야한다.
      • 그럼 서버 데이터에 붙는 pk 값과 로컬의 id로 이중화 되기때문에 이 부분을 어떻게 처리해아할지 좋은 수가 떠오르지 않습니다.
    • 다정 : 🐰
    • 찬민 :
      • 서버DB를 메인으로 해서 로컬DB에 저장하는 방식을 유지해야한다
      • 네트워크가 없는 상황에서 일정 추가, 변경, 삭제는 어떻게 갱신 할 것인가?
        • 구간 단위로 서버에서 일정을 받아오는데 서버의 DB상황을 몰라서 처리가 어려울 것 같음
        • 네트워크 연결이 없을 경우 일정 추가를 막는다 → 캘린더 기본적인 기능을 제공하기 어렵지 않나?
        • 서버에서 받아온 데이터를 로컬DB에 저장할 경우 동기화의 문제? → 호출되지 않은 일정은 로컬DB에 저장되지 않아서 네트워크가 없는 상황에서 일정이 제대로 보이지 않음 → 감수하고 넘어가야하는 부분?
    • 근범
      • 온라인 상황 → 서버에서 데이터를 받아서 로컬에 저장을 하여 동기화 + 요청할 때도 서버에 먼저 넣고 다시 서버에 일정을 요청해서 로컬에 저장하는 방식
      • 네트워크가 없을 때도 달력에서 사용자의 요청에 반응을 해야할 것 같음… 어떻게 해야할까… 앱 단에서 인터넷 연결을 해야한다고 알려주도록 하면 동기화에 문제가 없을 것 같다…
        • 하지만 진짜 오프라인으로 하고 싶은 사람을 지원하려면 로컬에서 생성, 삭제에 대한 테이블을 따로 관리하여 그곳에 저장하고 나중에 인터넷이 연결되면 서버에 다시 요청을 보내는 방식이 맞지 않을까….
    • 해림 :
      • 온라인 → 서버에서 데이터를 받아 로컬 데이터 업데이트
      • 오프라인 → 수정된 데이터를 위한 db 하나 더 만들어서 저장, 온라인이 되면 모두 업데이트..
        • 생각해본바 데이터 삭제 때문에 난이도가 높아지는 거 같은데.. db에 삭제됐음을 확인할만한 플래그를 추가해서 주기적으로 한번에 실제 데이터를 삭제하는 방식은 어떨까..? 이 경우 수정, 삭제, 삽임 모두 한번에 고려할 수 있을 것 같은데…
• BE
  • 1:n ↔ 1:n 인 너무 많은 데이터를 관리하는 방법
  • 인프라 문제
    • Docker의 사용성에 관한 문제
    • 비용 절감
      • micro(DB) ↔ VPC
    • 네트워크 구성문제
      • VPC를 꼭 구성해야할까?
• And
  • 안드로이드에서 키 관리 고민…

✔️ 멘토링 내용

멘토링 시간에 나눈 이야기를 기록해보세요.

• 동기화 이슈
  • 동기화가 정말 중요하다면 시간을 많이 들여서 동기화에 집중
  • 다른 기능이 더 중요하다면 동기화 부분은 적당히 타협하고 다른 부분에 더 집중필요
    • 기능 구현을 놓치지 않는 게 좋을 듯..
  • 일단 온라인만 가능하도록 해놓고 오프라인은 나중에 시간남으면 추가로 구현
  • 구글 캘린더 쓰는게 어떨까
  • edit distance 알고리즘을 써보면 좋을 듯
  • caldav 프로토콜을 찾아보면 좋을 듯
  • git이 동기화하는 방식을 벤치마킹해보면 좋을 듯..
• id 생성
  • 서비스 바운더리를 계산해보는 게 좋을듯
  • id 생성 → 충돌확률을 한번 계산해보는 게 좋을 듯
  • snowflake 의 유일아이디 생성 라이브러리(?)를 사용해보는 것도 좋을듯
    • 아직은 여기까진 생각할 필요 없을 것 같다(규모가 더 커지면 고려해보기)
• 실제 서비스에서 로컬과 서버 갱신 구간 설정 어떻게 하는 지??
  • 해시값을 비교해서 마지막 갱신 위치를 찾아 하나씩 로컬에 적용,,?
  • 실시간성 vs 모든 데이터
    • 실시간성이 더 중요할 듯..! 한달치만 동기화 하는 건 부적절
    • 가져오는 데이터가 적어서 크게 무리 없을 것 같다..
• MySQL의 격리 수준에 대해서도 알아보면 좋다.
  • MySQL은 기본적으로 repeatable read 격리 수준을 사용해서 그대로 쓸지, 다른 형태로 사용할지
  • MVC (Multi-Version Concurrency)

안드로이드

• 키값 관리
  • 개인 개발 환경에선 local property에 저장하는 것 좋다
  • ci 에 시크릿 키 추가할 수 있음
    • 한번 넣으면 빼낼 수 없음 (키를 다시 볼 수 없다..)
• 리소스가 png일 때
  • png가 해상도 별로 주어진다.
  • xxxhdpi에 넣어 놓으면 낮은 해상도에서는 자동으로 해상도가 조정되어 들어간다.
• 한화면에서 분업하는 것
  • 현업에선 화면단위로 나눈다..
    • 화면 단위가 아니더라도 타인의 코드를 기다리는 경우 많음
    • 어느 정도 코드에 대한 협의 진행 후 → 인터페이스와 같은 더미를 만들고 구현 완료 후 대체하는 방식!!
  • 화면 내에서 분배 - 효율적이진 못하지만 다양한 경험 가능..
• gson vs moshi
  • 비슷해보인다면 익숙한거 써라!
  • 새로운 기술은 사이드 프로젝트로 해보면서 좋다면 도입해보자!!
  • 팀 내에서 나눠서 쓰기도 함
• pr을 날리는 기준,,이슈 단위에 따라 pr 크기가 달라짐
  • feature 단위..
  • pr 쪼개기를 해보자
    • 커밋 단위로 쪼개는 것을 추천
• 코드수 볼 수 있는 것 - 안스 git으로 보자

백엔드

• 1: n
  • n+1 문제 검색
  • ORM 을 어떤걸 사용하느냐에 따라서 달라지기도 한다. → 해결하는 방법이 다르다..! 위의 문제와 연관지어 탐색해야할듯..
• fk 키를 넣는게 좋지만,,, 정 안되면 해제를 하고 가자…
  • 정안되면 넣어라..

✔️ 체크리스트

이번 주 멘토링에서 이야기 나누면 좋을 주제입니다. 우리 팀의 상황은 어떤가요? 멘토님과 이야기 나눈 후 셀프 체크하고, 그 이유를 작성해보세요. 추가하고 싶은 항목이 있다면 직접 추가해도 좋습니다.

• 기술적 도전 과제를 중심으로 기획서와 백로그 및 feature list 등이 완비되었다.
• 기술 스택의 선정 이유 혹은 구현 방식에 대해 나만의 근거를 가지고 설명할 수 있다.
• 이번주 스프린트 계획을 세웠고, 목표한 만큼 구현하고 있다.
• 다른 팀원의 과제가 무엇이고 왜 그 일을 하고 있는지 설명할 수 있다.