공통

로컬에서 안드가 서버 띄우면 더 빠르지 않나? 배포하는데 시간이 걸린다. 코드리뷰, merge되는데까지 시간이 걸리기때문에 api ↔ 화면 관통하는 사람이 소통하면서 서버 직접 띄워도 될 거 같다.

AN-BE 페어로 작업 할 때, AN 로컬에 띄워주자.

<aside> 💡 지난 스프린트와 동일하게 API 별로 AN-BE 페어를 지정하고, QA를 머지 여부와 상관없이 구현이 되면 로컬에서 진행했다.

평균적으로 수~목요일에 QA를 시작했는데, 이번 스프린트는 월~화요일에 QA를 시작할 수 있었다.

그러나, 아래와 같은 문제점도 존재해 개선이 필요하다.

</aside>

안드의 “서버 안돼요~” 에 백이 “너네 잘못임” 한 적 있나? 이제 안드가 로그 알아서 보게 할 수 있겠네요~ 안드에게 대시보드 공유하기

파트별로 서로에게 로깅 대시보드 공유 완!

모바일은 예외 케이스 + 사용자 시나리오를 로깅하고, 서버는 예외 케이스만 로깅한다. 서버는 사용자 행동 분석에 대한 로그가 없을까요?

로깅 전략 백이랑 안드 같이 세워야 하지 않나?

<aside> 💡 AN, BE이 함께 로깅 전략 회의를 진행했다.

<로그 수집으로 알고 싶은 것>

  1. 지각자를 줄이는 것
  2. 기다리는 사람의 기분/행복
  3. 유저가 사용했을 때 불편함을 느끼는 페이지 및 기능
  4. 유저가 사용했을 때 매력을 느끼는 페이지 및 기능
  5. 주기적으로 동일한 약속이 생성되는 니즈가 얼마나 될까?
  6. 몇시에 가장 많이 약속을 잡는지(트래픽 관리, 마케팅 전략), 약속 형태가 어떤지
  7. 약속 생성을 약속 전 언제 하는지? (30분 전?)
  8. 지각 변화 추이 확인

<유저 데이터 수집 관련 로깅 전략>

기술공유, 오디톡 2가지 병행하는 것 괜찮은지?

둘 다 유지하자! 목적이 다름

오디톡은 기술을 빠르게 공유하는 목적, 기술 공유는 계속 확인할 수 있는 주제에 대해 정리하고 공유하는 목적

AN

하루 이상 API 문서를 기다려야 해서 개발에 지연이 발생하지 않았는가? 현재는 서버가 터지면 앱도 터지는데, 이를 어떻게 개선할 것인가?

스크린샷 2024-08-20 오전 2.47.21.png

FakeRepository를 만들어서 해결한다.

현재는 서버가 아직 개발되지 않은 상황인 경우, FakeRepository에 임의의 데이터를 넣어서 안드로이드 코드가 잘 작동하는지 확인하고 있다.