진행 사항 공유

• 공부방 목록 페이지
  • → 인풋 변경에 따라 실시간 검색이 되도록 하는것은 어떨지?
    • 서버 최적화도 고민해보기
  • → form validating
    • 언제 validate할건지?
    • input이 invalid일 경우 어떻게 보여줄 것인지?
• WebRTC
  • mesh방식 1:1, 1:N 화상공유 테스트 성공
• 스프린트 계획보다 일정이 밀렸습니다

조언

• 처음 도전하는 기술 (ex. WebRTC) → 프로젝트 초기 단계에서 리서치 많이 하기
  • 얼만큼의 리소스를 투자해야 하는가도 미지수
  • 처음 산출한 일정이 밀리는 것은 어쩔 수 없다.

질문

서버가 여러개로 나뉘어있는데, (FE, BE, DB, S3 등) 다 같이 잘 관리할 방법이 있을까요?

• 프론트엔드 → CDN 많이 씀
• 네이버 웹툰 : 인프라 부서 있음 (포토/오디오 인프라 등)
  • S3를 쓰기보다는 보통 인프라 서버의 API 사용
• 도커 구축

WebRTC 테스트 브랜치가 아닌 별도 테스트 레포를 파는게 좋았을까요?

• 프로젝트의 단계에 따라 다르다 : 개발, 운영
• 브랜치 컨벤션을 지키는 것의 중요성은 프로젝트 목적에 따라 다르다.

분업하는데 코드 리뷰를 안하고 있습니다. 코드리뷰를 루틴화하는 것은 어떨까요?

• 코드 리뷰 : 문제해결 방법을 리뷰하는 것 → 문제가 뭐였는가에 대한 이해가 필요하다.
  • 하지만 보통 PR에 “어떤 기능을 추가했다”를 기록하지, “어떤 문제를 해결했다”를 기록하지는 않음
  • 여력이 없으면 본질적인 부분은 리뷰해주지 못함
    • 컨벤션, 변수명 같은 사소한 부분만 리뷰하게됨 → 취향의 영역
  • 본질적인 문제를 공유하자! → 페어 프로그래밍 도입
• 리뷰를 요청한다면 구조적 틀(설계)에 대해 요청해보는 것이 좋을 것 같다.

비동기 데이터 fetching을 어떻게 처리할지 함께 결정했습니다. 현업에서도 이렇게 비동기 데이터 fetching 컨벤션(?)을 초기에 결정하나요?

• 보통 네트워크, fetching과 관련된 하나의 객체에 역할과 책임을 위임하는 방식을 사용한다.
• 결정 사항 : 비동기 데이터 처리에 custom hook을 사용하고 로딩 컴포넌트를 재사용하기로 했다.
  • 컨벤션이 아닌 설계라고 할 수 있다.
    • 설계 : 요구사항이 변경될때 유연하게 대처하기 위한 전략
    • 컨벤션 : 코딩스타일, 취향, 목적의 차이 (로직과 관련 없음)