Mentoring

2020-11-18

📣 사전 공지

핵심 기능 위주로 Feature 설계

• 회원가입 / 로그인 (드라이버, 사용자 각각)
• 사용자 액션 Flow 정의
• 드라이버 액션 Flow 정의

간단한 자기소개 준비

🔖 제출 내용

• 기능 명세서
• 와이어프레임
• 백로그

💡 멘토링 내용

❓ UI를 얼마나 (구체적으로, 어느 시점에?, 시간을 얼마나 쏟아야 할 지) 잡고가야 할까요?

• UI라이브러리를 적극 활용
• 기능 위주로 구현하도록
• CSS작업은 최소화

❓ 지금 우리가 선택사항으로 해놓은 것들 중 필수로 돌릴만한 것이 있나요? 선택사항/필수구현사항 분배가 적절한가요?

• 자동완성 기능은 선택으로 하는게 좋겠다.
• 좀 더 빼도 된다.
• 결제 기능을 구현하지 않고 결제가 되었다고 가정해도 좋다.
• 드라이버 - 유저 간 실시간 통신이 핵심!
• 기술 스택에서 힌트를 얻도록 하자

❓ 구글 네비게이션은 한국에서 지원이 안되는 것 같아요.

• 안되는건 하지말자,
• 경로표시도 안해도 좋다.

❓ 업무분장의 방향을 어떻게 잡으면 좋을까요?

• 풀스택이 이 과정의 목표이다 : 프론트/백엔드 나누지 말자
• 기능/피쳐별로 분장하는 것이 좋다.
  • 조장님이 교통정리 잘 해서 분장해주시길

❓ 몽고DB 사용시 제약사항, 주의할 점이 있을까요?

• node에 붙이기엔 mysql보다 편하다.
• 딱히 유의할 점, 제약사항은 없다.
• nosql 개념을 반영해서 스키마 없이?
• 익숙하지 않다면, 저장소의 개념으로 사용하라. 넣고 꺼내는 개념

❗️ 질문 외 멘토링 내용

• 기능 피쳐 개발이 먼저!!
• 논의사항이 아닌것들은 바로 빼자
• 한사람이 논외 사항으로 시간을 과하게 쓴다면 나머지 세명이 확실하게 말해주는 것도 좋다.

---

2020-11-25

📣 사전 공지

🔖 제출 내용

• 상세 이슈
• 기술스택

💡 멘토링 내용

❗️ 질문 외 멘토링

로드맵

• A팀의 경우 날짜별, 이슈별, 팀원별로 어떤 일을 하고 있는지 엑셀로 정리
• 좀 더 구체적으로 달력 형식으로(?) 수정해야 할 듯 합니다

기술스택

• 큰 이슈는 없음
• 지도 개발 실시간 통신시 드라이버/유저의 GPS 이동 테스트 방법 팁
• 구글 크롬에서 테스트 할 수 있다.
• 개발자 도구 -> More tools - Sensors - Location에서 GPS 위치를 바꿀 수 있다.
• 구글 맵이 한국 지도 영역 내에서는 경로, 남은시간이 안되니 외국 위치에서 테스트 하시길

모든 스펙은 graphQL로 작업

• 꼭 필요하면 restAPI 사용하는데, 시간이 걸리니 웬만하면 통일해서 사용하자.
• 퍼블릭/프라이빗 쿼리 구분 할 때(로그인 전/후 노출 되는 부분 나눌 때)는 어떻게 하느냐?
• Directive 문법 활용!
  • https://www.apollographql.com/docs/apollo-server/schema/directives/
• (예시) @isAuthenticated : 인증한 사람만 보여야 하는 페이지는 디렉티브 문법을 사용하면 된다.
• (예시) @isAuthenticatedDirected 페이지를 만들어서 사용하면 된다.

❓ 질문

오퍼레이션 네임으로 로그인 유저 구분을 했는데, (아폴로 서버 환경의 context 안에서 ) 디렉티브가 가지는 장점이 따로 있을까요?

• operationName으로 처리할 수 있으면 조건문이 계속 추가됨
• 지금이야 로그인 상태만 확인하면 되니까 간단하지만 다른 유저 타입이 늘어나면 분기가 무수히 늘어남
• 지금 잘 돌아간다면 궂이 시간들일 필요는 없지만 최적의 방법은 directive일 것

리덕스 디스패치 type을 어디까지 잡아줘야 할까요?

현재 타입스크립트 리덕스 사용하다가 타입정의 시 any 타입으로 지정한 상태입니다.

• redux hooks 사용 사용하면 깔끔하게 끝난다.
• 지금은 기존 전통적인 레거시 스타일이라 타입 지정이 애매...
• functional 리덕스 훅을 사용는것이 권장. 그러면 dispatch 타입을 지정 할 필요가 없다.
• 당장은 any로 해도 상관없지만 공식 도큐먼트는 훅스를 추천 할 것이다. 참고!
• 아니면 @types 중 해당 라이브러리 추가

antd-mobile에 보니 form이 따로 없어서, formik라이브러리를 사용했는데, antd-mobile 사용하면서 form 관리를 form 어떻게 관리하시나요?

useref 방식을 사용하자니 상태관리가 힘들어서...

• antd는 더 많은 요소 제공하니까 거기서 보시오
• 굳이 모바일을 강조한 게 아니고, 그저 UI를 신경쓰지 말란 의미였다.
• 앤트 디자인으로 해도 반응형 대응이 되어 있으니 갈아타도 좋다.

타입스크립트 타입 설정

• 외부 라이브러리 타입 설정시 확인 가능 @types/library
• 하나라도 any를 쓰지 않겠다! 라고 집착하지 않아도 좋다.
  • 충분히 고민했다면 몇개 남겨두어도 좋다.

2020-12-02

📣 사전 공지

A,B,C팀 통합으로 회의 진행
각 팀에서 궁금한 내용 준비
12/02(수) 17:00~18:30

💡 멘토링 내용

❓ 한 페이지에서 사용하는 useEffect가 많은데, 이렇게 작성해도 괜찮은지

• useEffect 갯수 세 개는 지금도 많지 않다. 괜찮다. 이대로 진행하세요

❓ 동시 수락해서 중복요청이 넘어가는 경우는 어떻게 커버해야하나요?

• 싱글스레드인 Redis 를 쓴다면 동시 수락이 아예 어렵다.
• MongoDB는 싱글스레드가 아니기 때문에 발생 가능한 이슈이긴 하다.
• 하지만 대용량 트래픽이 아닌 이상은 그럴 일이 드물다.
• Redis 도입도 현재 프로젝트에서는 오버스펙.
• 그렇다면, 바로 업데이트가 아니라 한번 확인하는 전처리를 진행하면 되겠다.
• MongoDB 에도 트랜젝션이 도입되고 있는 추세이나, 이것은 확인해봐야 해

❓ 큐에서 요청을 뺐는데, 매칭이 된 요청인지 확인하려면 ?

• "이미 배차된 요청입니다" 실제 카카오택시 서비스에서도 이런식으로 처리하고 있다.
• 큐 안에서 배차 상태를 구독하고, 관리 할 필요 없다. 복잡해지고, 오버스펙이다.

❓ 에러를 따로 빼서 관리해야 할지 고민

• 서버에서 에러가 발생되면, 코드와 에러메세지 컨벤션을 정하고, 클라로 내려주면 toast 메세지를 띄워주는 방식으로 처리하는게 실무 보통.
• 에러 넘버로 중앙 관리하면 좋지만 그것 또한 오버스펙.
• 자율도가 높은 이슈이므로 마지막 주차에 하면 좋은 고민이다.
• 결국 실무에서도 필요한 리팩토링 포인트이긴 하니까, 고민해보면 좋겠다!
• 에러를 관리하고 싶다면, 인터셉트하는 포인트를 잘 잡아서
• 초반(테스트)에는 개발자가 에러메세지를 임의로 정하는것보다, 에러 객체를 날 것으로 날려서 확인하는게 팁이다.