6월 12일 온라인 백엔드 회의

[JAWSP]

회의

event-emitter

• 클라의 소켓id를 키값으로 하고 유저 시퀀스를 벨류로 잡는데

• 정보를 업데이트 함과 동시에 status값도 캐시에 저장한다고 함

  →status는 온라인/오프라인/게임중인 상태(테이블)에 대한것

• 근데 저장하는 경우에 겹치는 부분이 많아서 한꺼번에 하면 어떨까란 의견이 있음

채팅/게임 소켓 명세

현재 desc(소켓 이벤트 요약), at(생기는 시점), to(보내는 타겟)으로 명세를 해놓음
근데 문맥상 at이 아니라 when이 더 맞는듯

인터페이스가 문디?

• 자바스크립트는 왠만하면 다 객체인데

• 그러한 객체에 대하여 타입을 지어주는 역할??

• 핵심은 프로젝트 외부에서 사용하는 코드의 계약을 정의하는 것

  →서버에서 서버밖으로 전해주는건데 그것에 대하여 좋은게 인터페이스가 나을듯함

• 타입과 인터페이스사이에 차이

• 그러고 보니 구조체랑 많이 비슷하네

팔로우/팔로이 관련

• 만약에 서로 친구관계인 AB가 있으면 서로 팔로우를 해야겠지

• 둘 중 하나만 있게 된다면 어찌 해야 하는가

• 만약에 팔로워가 친구추가로 하고 팔로이가 친구요청으로 생각을 한다면

• 친구찾기를 할떄 팔로우/팔로이를 두번 찾아야한다

• 따라서 친구관계에 대한 새로운 칼럼이 필요하지 않느냐란 의견이 있었음

• 그리고 마스터코드를아래와 같이 수정

인자를 객체로 넣는 이유

• 객체로 넣으면 수정하는 부분이 줄어든다
• 아니게 되면 받는쪽 주는쪽 둘다 수정하는데
• 객체로 넣으면 받는쪽만 수정하면 된다

테스트 관련

• 컨트롤러에 대한 e2e랑 서비스에 대한 유닛(단위) 테스트가 있는데
• 둘 중 하날 하자면 e2e가 더 실용적이니 쟤만 남기면 되지 않을까 싶음
• 그리고 구연할껄 구현한 다음에 리펙토링할때 테스트를 만들면 되지 않을까싶음

테스트 작성(e2e)

given-when-then패턴을 쓰게 된다고 한다

TDD를 할때 일반적으로 요 패턴을 많이 쓰게 된다고 한다

• given이 주어진 정보 when이 주어진 엑션 then이 주어진 결과라고 한다

• 그리고 이렇게 하니 된다(어차피 함수 출력값으로 생각하면 당연하게 느껴진다고 한다)

• 테스트 방법은

• jest의 expect메소드로 어떤 값을 가져야 하는지에 대한걸 정할 수 있는데

  • 참이여야 하는것
  • 거짓이어야 하는 것
  • 값이 정확히 일치하게 되는것
  • toBoInstanceOf 잘못된 정보를 집어넣을때 에러 exception이 잘 나오는지 아닌지
  • 심지어 그 exception이 특정한 에러를 잘 내는지
  • 심지어 테스트를 할떄 몇번째 줄에 들어갔는지까지 다나옴..

  →if문으로 들어갔는지 안들어갔는지도 찾음

  →저것때문에 if가 들어갔는지 안들어갔는지도 안보여서 최대한 자제하고

  →해당되는 클래스랑 해당되지 않는 클래스로 나눠서 하는 경우도 있다고 하다

e2e 테스트

• 슈퍼테스트란걸 쓴다고 한다
• 제스트랑 얼추 비스므리하다고 함

• request, .get에서 테스트를 해주고 그걸 err, res로 받아서
• 아래에서 어떤 결과가 나왔는지 보는거
  • res가 200인지
  • 바디가 Array인지
  • 해당 객체의 결과가 예상된결과인지 아닌지 결정

프론트로 쳐들어가자

• 이유: 회원가입에 대하여…

• 회원가입절차에 대한건 42auth때문에 인증을 안해도 되는듯

• 2차인증은 유저가 로긴할때 바로 인증페이지로 가고 2차인증을 했는지 안했는지

• 첫 로그인에 대하여

  →디폴트값으로 처리하고 로그인하면 바로 넘어가고

  →그리고 만약에 2차인증에 대하여 껏다켰다하고 디폴트는 끄고

  →그리고 로그인은 42auth로 들어가서 로그인 되면 바로 회원가입되는거고

• 그럼 회원가입이란 개념이 없어질듯함

• 로그아웃 있음 없을 것 같지만 있음

현재 상황에 관하여

• 이대로 가기엔 너무 루즈한 느낌이 들어서 한번 합숙으로 크런치에 돌입하자는 의견이 나옴
• 근데 그렇게 하기에는 빠지는 사람이 너무 많음(절반이 빠짐)
• 그렇다고 매일마다 오프라인으로 만나기에는 힘든 인원들이 생김
• 결국 온라인으로 빡시게 하는걸로 일단 결정
  ->일단 안해보고는 모르는 것이니까
• 그리해서 어쩌다트센팀을 벤치마킹해서 디스코드를 리뉴얼을 했음
  • 과제와 관련이 없는 부분은 지우고

- 위와 같이 필요한 부분을 중요도에 따라서 채널을 나눔
- 자신이 과제중일때 i’m working에 상시 있음
- 만약에 뭔가 필요하면 태그 걸어서 불러주고 전체/프론트/백 회의에서 진행하기

• 멘토링 의견도 있었으나, 멘토분들이 온라인상으로 작업하는데에 익숙하는가 익숙하지 않느냐란 의견이 갈렸음

  →그래서 멘토링 하자는 결론은 몰?루