공통 질문

• [ ] 협업을 어떻게 했냐
  • 우선 notion, postman, slack, miro, 구글 스프레드시트 를 적극적으로 활용했다.
  • Conflict 를 방지하기 위해 커밋 컨밴션, git flow 전략, eslint, prettier 로 코딩 컨밴션 등 저희만의 개발 문화를 정했습니다.
  • 함께 성장할 수 있는 분위기를 위해 PR 에 대해서 1명 이상의 리뷰를 필수로 진행하여 서로의 코드를 보완했다.
    • 함께 성장할 수 있는 분위기가 뭐냐???
      • 놓친 코드 스타일
      • 생각없이 사용한 any type
      • 생각하지 못했던 로직 (Ex, promise all 등)
  • 추가로 백과 프론트간 버그 리포트 부분은 git issue 를 활용했다
• [ ] 역할분담은 어떻게 했냐
  • 프론트 2명 백 2명으로 나누었습니다.
    • 백로그를 통해서 기능을 나누고 분담했습니다.
• [ ] 왜 프론트랑 백이랑 나눠서 진행했냐
  • 서로 프로젝트 진행에 대해서 경험해보고 싶은 분야가 명확하여 나눠서 진행했다.
  • 하지만 스크럼을 통해 백, 프론트의 진행상황 브리핑과 기술공유를 진행하며 완전히 분리된 협업을 진행하지 않았다.
• [ ] 기술스택은 왜 그걸 선택했냐
  • 기술 스택을 사용한 사람이 대답하면 될 듯
  • 선정이유
• [ ] SNS 서비스와 차별점이 뭔가요
  • 개발자들이 이용하는 Github, 백준, 블로그 등의 서비스를 연동하여 제공하는 기능이 있다.
  • 대시보드 페이지를 통해 자신의 간이 포트폴리오를 만들어 나의 활동 내역을 모아서 볼 수 있다.
• [ ] 협업하면서 발생했던 커뮤니케이션 트러블이 있었나? 있었다면 어떻게 해결했나?
  • 서로 다른 의견을 주장할시 각자의 의견을 이유와 함께 설득하려 노력했다. 그리고 듣는 사람들은 설득 당하려는 자세로 임했습니다.
  • 그래서 설득 당함과 설득함의 가능성이 둘 다 열려있는 상태로 임하면 커뮤니케이션 트러블을 예방과 동시에 더 나은 결과가 도출될 수 밖에 있었다.
• [ ] 개발 도중 문제점 발생한거 없냐? 있었다면 어떻게 해결했냐?
  • 자동 배포가 실패했음 self hosted, next build
  • 미흡한 설계, 컨벤션 등 자잘한 문제등은 팀원과 미팅을 통해 지속적으로 보완했습니다.

프론트 질문

• [ ] 정말로 pre render 바른가? 데이터 페칭하는 횟수는 같은데 어떤 부분에서 사용자가 더 빨리 컨텐트를 볼 수 있나?

  • 클라이언트애서 데이터를 페칭해서 리렌더 해주는 것과 서버사이드에서 pre-render 해서 응답해주는 것 중 어떤 방식이 유저입장에서 더 빨리 컨텐츠를 볼 수 있을지 고민을 해봤는데영?? 전자의 경우에는 응답받은 html과 script를 연결하는 하이드레이팅 작업을 완료한 뒤 데이터를 페칭하고 그것을 적용해주기 위해 리렌더링을 해야하지만, 후자는 프리렌더 과정에서 컨텐츠가 포함된 html을 만들어서 주기 때문에 사용자는 응답받은 동시에 컨텐츠를 볼 수 있고 전자보다 상대적으로 더 빠르게 첫 컨텐츠를 볼 수 있었습니다.

• [ ] 스크롤 복원 시 스크롤 위치에 대한 정보를 세션 스토리지에 저장한 이유

  • session storage는 tab과 window 단위 별로 저장되고 local storage의 경우 domain 단위로 저장되기 때문에, local storage에 저장될 경우 혼선될 가능성이 있으므로 session storage에 저장하였습니다.

• [ ] ~를 사용한 이유

  • 기술 스택 선정 이유로 커버 가능

• [ ] 무한 스크롤은 어떤 방식으로 구현 하셨시유?

  • 데이터가 더 필요하다고 판단했던 방식은 intersection observer api를 커스텀훅스로 래핑해서 사용했구영! 그리고 데이터를 불러오는 api는 url query에 next cursor라는 파라미터를 둬서 다음에 받아야하는 데이터의 인덱스를 명시했음!!!!

• [ ] 이미지 업로드의 경우 어떤 방식으로 진행하였나??

  • naver ncloud의 object storage를 사용하였습니다. aws 라이브러리를 사용해서 client에서 바로 업로드를 진행 했고, 사진 url을 DB에 저장하는 식으로 했음

• [ ] 상태 관리는 어떤 식으로 진행?!

  • 접속한 유저 정보, 대시보드 기본 정보와 같은 전역 상태의 경우 recoil을 통해 관리하였다.
  • 포스트 작성, 타임라인 데이터의 상태를 관리 하였습니다.

• [ ] Profiler 에서 어떤 거를 사용했나

  • 현재 업데이트에 해당하는 Profiler와 자손 컴포넌트들을 렌더하는데 걸린 시간인 actualDuration 을 사용

• [ ] 검색은 왜 쓰로틀링을 안쓰고 디바운스를 사용했나?

  • 검색 자동완성에서 쓰로틀링을 사용하는 것이 유저 경험에 더 도움이 된다는 것을 알고 처음에는 쓰로틀링으로 피쳐를 잡았는데요?
  • 외부 API를 사용하지 않고 정확한 쓰로틀링을 구현하는 것이 생각보다 복잡하고 요구사항이 많더라구요
  • 그래서 외부 API를 사용하는 것 보다는 직접 구현하는 것이 더 학습에 도움이 되겠다고 판단해서 디바운스를 커스텀 훅으로 만들어 사용했습니다.

• [ ] react virtualized 깃허브에서 원리를 가볍게 읽어서 정확하게 알지는 못하지만 우선 목록 가상화를 통해 리스트 데이터를 따로 들고있고 실제 데이터와 shallow Compare를 통해 필요없는 render를 뺀다고 하더라구요 그리고 이 shallow compare 는 react-addons-shallow-compare 모듈을 통해서 지원하구요 이런 키워드를 좀 더 깊게 학습한다면 충분히 자체개발 가능할것이라 예상합니다.

백엔드 질문