팀 01 프론트엔드 중간 피드백

1️⃣ 면담 일지

면담 일시

참여 명단

• Paeng / 팽건우

• Padd / 김정환

• Jay / 박민제

• Kaia / 김가연

• Mckee / 이재웅

면담 내용

인증샷

전체적인 피드백

• 보통은 마감 일주일 전에는 서비스가 완성은 돼있어야 함. 아직 API 서버가 안 떠있는 상황은 조금 일정이 빠듯할 수 있음.

• 멘토님의 경험 상 유저들은 낙관적 업데이트를 별로 선호하지 않고, 특정 요청이 정확히 처리된 후 UI가 변화하는 것을 선호한다.

• 현재 메인 페이지에서 Select Box에 기본 값(전체)이 존재하지 않는 것으로 보임. 이런 경우 새로고침을 해야 해당 필터를 취소할 수 있기 때문에 이 부분은 필요할 것 같다.

Q&A

• Q. 현재 백엔드에서 Refresh Token을 관리하고, 클라이언트에서 만료된 Access Token으로 요청을 보낸 경우, 특정 에러코드와 같이 토큰을 재발급 받은 뒤 다시 해당 요청을 보내도록 되어있는데 이게 올바른 방법인지 궁금합니다! A. 보통은 그런 방식으로 구현하기는 한다. 하지만 요청을 보내는 일이 잦아지면 유저 경험이 낮아지므로 Access Token의 유효기간을 조금 늘리는 방식으로 하면 좋을 것 같다.

• Q. redux 로 유저 객체를 저장하는데 있어서 thunk 를 이용해 비동기 액션으로 저장하는 것과, 비동기 요청이 끝난 후 동기 액션으로 저장하는 것 중 어느것이 적절한 방식인지 궁금합니다! A. 웹앱의 경우 둘 다 큰 차이는 없다. 지금 당장은 구현하기 쉬운 쪽으로 먼저 구현해도 좋을 것 같다.

• Q. Git FLOW 전략을 이용해서 브랜치를 관리하고 있는데, release 브랜치와 main 브랜치의 역할이 겹치는 것 같습니다. 왜 두 브랜치를 분류하는지 궁금합니다. A. main 브랜치에 바로 push해서 배포하는 경우 잘못된 내용이 배포되면 서비스 장애가 생기기 때문에 안전을 위해 두 브랜치(release or staging branch)를 나눈다. 다만 지금처럼 규모가 작거나 실 서비스 이용자가 없는 경우 main을 배포 브랜치로 사용해도 좋다.

• Q. 현재 스토리북에서 데이터 핸들링을 하는 컴포넌트들도 테스트도 하고 있는데, 이게 올바른 방향인지 알고 싶습니다. A. 그건 잘못된 사용법이다. 스토리북에서 데이터를 사용하는 컴포넌트를 테스트 하는것은 스토리북을 너무 남용하는 방식이다.