2차 멘토링 11월 2일

☕ 멘토님께 질문할 사항

• issue 제목이나 하위 task 이름이 적절한지

• issue 나누는 단위를 담당자로 나눌지, 기능별로 나눌지

• 로비 페이지 생성 시 서버가 가지고 있는 채널(방) 소켓 정보들을 api를 통해 보내는 게 좋을지, 소켓으로 보내주는게 좋을지

  • 채널이 생성되었을 때 어떻게 처리할 것인가?

• 메모리(전역변수)에 데이터를 저장 vs 레디스 사용

  • 다중 서버 구현 시 메모리 데이터는 공유 불가
  • 데이터 연속성, 안정성 고려 필요

• API 명세 평가

  • SSL : https 프로토콜
  • GET 방식에서 암호화할 수 있는 방식 고려 (url 노출 X)
  • 복호화키(서버), 암호화키(클라이언트)
  • DB pw 암호화

• 브랜치 전략 평가, merge or rebase

• form tag로 응답받는 법 (fetch, XHR 객체를 꼭 사용해야 하는지)

  • form tag에 한계가 있다.

• 로그인 시 id, pw를 post요청으로 body에 넣는게 좋을지

• 도커 사용해보는거 어떻게 생각하시는지

• 먼저 실패한 테스트케이스 작성

  • 망한 커밋 수정 코드 작성
  • 테스트 성공 후 머지 가능하게 만들어보기

🚦 정리

• 새로운 issue 생성하는 것을 꺼리지 말자
  • 💁🏻‍♂️ issue-task 구조에 너무 집착할 필요는 없다. 작업 진행중 언제든 sub-issue/task나 완전히 새로운 issue가 도출되기도 한다.
• 로비 페이지 생성 시 서버가 가지고 있는 채널(방) 소켓 정보들을 api를 통해 보내는 게 좋을지, 소켓으로 보내주는게 좋을지 => 새로운 방이 생기면 어떻게 대응할지를 생각해보자
  • 💁🏻‍♂️ 일반적인 HTTP API는 클라이언트가 요청하면 서버가 응답하는 방식이다. 유저가 접속한 이후 생성되는 방은 유저에게 어떻게 보여줄 수 있을까? 를 고민해보자
• 메모리 vs 레디스 : 서버는 언제든지 터질 수 있다. 다중 서버일 때, 메모리는 공유가 안 되기 때문에 레디스를 사용하면 좋다.
  • 💁🏻‍♂️ 앱서버는 언제든지 터질수 있다. 그때에도 데이터는 보존되어야한다. 앱서버를 다중으로 구성해 두었을때에도 앱서버들은 동일한 데이터를 바라보아야 한다.
  • 💁🏻‍♂️ 이는 앱서버 메모리상에 데이터를 관리하면 안되는 무수한 이유 중 일부분일 뿐이다.
  • 💁🏻‍♂️ 레디스는 많은 솔루션 중 하나일 뿐. 사용목적에 따라 다양한 선택지가 있다.
• CSRF 토큰, SSL, https, 암호화 복호화 과정을 하는게 좋다.
  • 💁🏻‍♂️ 클라이언트/서버 민감데이터를 다루는 방법에 대해 알아보자
• 라우터 순서나 hierarchy를 더 고민해보자
  • 💁🏻‍♂️ 라우트 규칙에 따라 선언순서가 영향을 주기도 한다
• 프론트 테스트를 위해서는 백엔드와 같이 합칠 수 있을 필요성이 있을 수 있다.
  • 💁🏻‍♂️ 하나의 기능을 완성해가는 과정에서 지금의 front/back 브랜치 전략은 한계가 있을 수 있다.
  • 💁🏻‍♂️ 테스트 관련해서는 다음에 별도 주제로.
• form tag는 한계가 있다.
  • 💁🏻‍♂️ <form/>의 한계와 태생을 이해하고 클라이언트 비동기 처리를 위한 방법을 고민하자
• rebase는 커밋 해쉬가 바뀌고 merge는 새로운 커밋이 생기니까 tracking하기가 쉽다.
  • 💁🏻‍♂️ 구성원들이 git에 충분히 익숙하지 않다면 rebase and merge 전략은 위험부담이 있다.
  • 💁🏻‍♂️ 커밋로그가 지저분해 지더라도 머지 커밋을 생성하는 전략을 취하면 PR 이슈가 참조되어 이슈에서 주고받은 리뷰 내용이나 설명 등 작업의 컨텍스트를 이해하는데 도움이 된다