발표 주제

협업 관련

아쉬운점

• 전체적으로 서로 눈치를 보고 예의를 차리려고 과도하게 폐를 안 끼치려고 했다.
• 프-백 간 커뮤니케이션에서 눈치를 좀 많이 본게 아닌가…
• 만약에 둘다 경험이 좋았다면, 그러니까 지금 6주 전으로 돌아간다면 했을 것들
  • 2조의 콜센터가 상당히 매력적이었음
  • 명세를 조금 더 구체적으로 다듬었으면 어떘을까
• 각 분야간에서 느낀점
  • 서버
    • 어렵고 부담되는 기술들을 혹은 재밌을 것 같은 주제들을 독점한 것 같음
  • 클라이언트
    • 협업에는 딱히 아쉬운점이 없다
• 후반부에 이슈 + 프로젝트가 무력화됨
  • 근데 이게 스프린트 단위에서 잘 관리하기가 빡세긴함…

잘된점

• 깃헙 잘 함
  • PR도 좋았고, PR올리면 댓글 리뷰도 좋았고
• 매일 아침 현재상태 공유가 좋았음
  • 다들 적극적으로 참여해줘서 동기부여가 되었음
    • 문제를 해결하려는 의지가 느껴졌음
• 디스코드로 옮긴 것
  • pc의 리소스를 잡아먹는 미팅(zoom)과 소통채널(카톡 + 슬랙)의 단일화를 위한 구국의 결단
• 최소 일주일에 한번은 식사를 한 것
  • 매주 부산에서 올라와주신 예찬님께 박수 👏👏👏👏👏👏👏👏
• 역시 일은 만나서! 오프라인에서 같이 작업을 많이 한 것!

기술적 도전

• 테스트 코드를 도입하지 않은 이유

• 리액트를 써보는 것 자체도 도전이었음

• 상태관리 라이브러리를 사용하지 않은 전역 상태 관리

• 익스텐션

• 커스텀 드롭다운

• 라우터와 react query 이 두개를 조금 더 잘 쓸 수 있었을 텐데…. 라는 생각

  • 근데 동시에 우리 서비스에 굳이 필요없어서 니즈를 못느낀 것이라고도 생각이 든다.
  • react-query의 도입

• 라우터와 suspense를 잘 못쓴것

• 세션을 이용한 이유

  • Nest 에서 지원이 안 좋은 세션을 굳이 이용한 이유
  • FE에서 어떻게 구현했는지
  • 장점과 부작용

BE

• 백준 문제 전체 크롤링 + 디비 반영
  • solved.ac api 이용
    • https://solved.ac/api/v3/search/problem?query=+&page=${page}
• 채점 서버 없이 어떻게 백준 문제가 맞았는지 아닌지를 판단하나요?
  • 문제점: 백준에서는 사용자가 제출 버튼을 누를 경우 발생하는 POST 요청에서 백준 아이디와 문제 번호만을 추출할 수 있습니다.
    • 사용자가 여러번 제출 할 경우, 제출 번호를 특정할 수 없습니다.
  • 해결책: 백준은 특정 사용자가 특정 문제 번호에 대해 제출한 모든 제출 목록을 살펴볼 수 있는 페이지를 제공합니다.
    • 해당 페이지를 0.5초 간격으로 크롤링하면서, 가장 최상단 제출에 대해 맞/틀을 판단합니다.
• 리트룸즈와의 차이점: 문제 쿼리 검색을 더 용이하게
  • 아쉽게도 리트룸즈에서는 문제를 랜덤으로만 출제할 수 있습니다.
  • 개선 사항: 백준룸즈에서는 직접 문제를 출제할 수 있습니다. 이때, 디비에 들어가 있는 백준 문제들를 검색해, 이름과 문제 번호에 대해 자동완성을 제공합니다.