[07] 1주차 기술멘토링 피드백 정리

1. 사전 준비

① 노션 : https://www.notion.so/1-882180dd274943b683676575e8aae4dd

1조 기술멘토링 사전노트

 

② 준비한 질문 

• GameSet에서 발언권이 바뀔 때 마다 DB에 접근을 해야될 것 같은데 속도나 효율성 때문에 Redis를 사용하고자 하는데 방향성이 맞을까요?
• 한 방에 정답이 최대 4개인데 키워드 리스트를 Json화 시켜서 문자열로 DB에 저장을 했는데 이거를 다시 검증하려고 하면 배열화 시켜야하는 번거로움이 있는데, 조금 더 효율적인 방법이 있을까요?
• queryDSL 예시를 찾아보던 중에 여러 queryDSL문 생성 후에 마지막에 flush / clear 로 DB에 저장하는 사례가 많았는데, 이 방법이 DB 접근을 최소화하기 위한게 맞을까요?
• 실무에서 flush / clear를 사용할 일이 별로 없다는데 잘 이해가 안됩니다….ㅠㅠ (데이터를 DB로 보내는 다른 방법: 트랜잭션 commit() / JPQL로 만들어진 Query 실행)
• Redis가 메모리 파편화 때문에 생각보다 많은 메모리를 차지하는데, Redis 메모리를 효율적으로 사용하는 방법이 있을까요?
• WebRTC를 시그널링 서버를 구축하는 방향으로 구현은 성공했는데 최대 4명의 유저간 통신이 이루어지는 저희 서비스에서도 SFU 서버 통신을 고려해야 할까요?

 

2. 피드백 정리

① SA대시보드 피드백

 

② 1주차 피드백 (1월 7일 토요일)

1) 깃허브 

• 코딩컨벤션 : 에어비엔비 참고 (스탠다드 처럼 쓰임 )  https://github.com/airbnb/javascript
• 깃플로우 전략 : 순서가 중요( 하위 브랜치에서 상위 브랜치로 가야함 ) + Master branch 에는 배포된 코드만 있어야 한다
  • Hot fix branch - 실제로 현업에서 발생하는 경우는 많지 않음
  • 브랜치는 Commit 단위로 나누기 ( 커밋 로그를 나눠서 )

2) 기술스택

• AWS - 기술스택이 아니고 인프라로 빼야함 
• OpenVidu - 이것도 기술 스택 아님 

3) ERD

• 현재 ERD - ERD라고 보기 어려움 ( 몇대 몇으로 맵핑되는지 보여야함 +  PK/FK 가 보여야함)
• 개선할 부분
  • GameRoom - Member 사이에 관계를 맺어주기
  • GameRoomMember 도메인을 GameRoomAttendee로 변경
    • Id(pk), RoomId(fk), MemberId(fk) 요소가 만들어진 테이블 만들어주기
    • relation table 역할 : 진짜 필요한 데이터만 갖고 있어야 한다.
    • PK : Id, FK : RoomId, MemberId, nickname
  • 게임룸이랑 멤버요소는 지워줘도 괜찮음
  • 게임룸 안에 chatroom 을 뺴도 괜찮을 듯 (존재 이유가 명확해야 하는데 불명확 하기 때문 )
  • GameRoom <- GameRoomMember -> Member
  • 게임룸이 게임룸 멤버 정보를 들고있으면 안된다 ! 

 

4) 질문에 대한 답변 

 

1. Openvidu와 같은 미디어 서버를 사용해야 할까요?

• 사용자가 많아지면 SFU를 사용하는게 맞지만 4명~8명처럼 소수라면 P2P 시그널링 서버를 쓰는게 좋다 : 성능적으로 좋다
• 실시간성이 중요한건지 서버의 부하를 줄이는건지 선택하는게 중요
• 완벽한 이상적인 해결책은 없다 ! 따라서 서비스에 따라 기술스택을 선택하면 된다 

2. Redis가 메모리 파편화 때문에 생각보다 많은 메모리를 차지하는데, Redis 메모리를 효율적으로 사용하는 방법이 있을까요?

• Redis는 현업에서 아주 많이 사용하는 메모리 DB, 메모리 파편화라는 것을 신경쓸 필요가 없을 정도로 잘 구성이 되어있음
• 메모리 파편화 해결 : 효율적인 자료구조로 사용 - 리스트나 맵보다 스트링으로 저장한다던지 하는 방법 

3. 한 방에 정답이 최대 4개인데 키워드 리스트를 Json화 시켜서 문자열로 DB에 저장을 했는데 이거를 다시 검증하려고 하면 배열화 시켜야하는 번거로움이 있는데, 조금 더 효율적인 방법이 있을까요?

• 효율성을 생각하면 콜룬을 추가해주는게 맞지만 사실 추후 확장성을 고려했을때는 Json 형식이 맞다! 

4. 실무에서 flush / clear를 사용할 일이 별로 없다는데 사용한 예제를 봤다. 이유가 뭘까요?

• flush / clear 명시적으로 사용할 수 있지만 거의 코드로 사용하지 않음
• 암시적으로 자동으로 반영이 되기 때문에 굳이 써줄 필요가 없다. 
• hibernate 에 auto commit 기능이 있기 때문에 알아서 처리가 된다. 

5) 그 외 조언

• 자료 찾을때 블로그보는게 좋지는 않음 - 최대한 공식 문서 / 영어로 찾아보기
• 잘짠 코드/ 좋은 코드 : 일관성 있는 코드,  간결함 = 여러명이 찐 코드여도 한사람이 짠 코드처럼 보이는 코드 
• 프론트엔드 : 리덕스를 사용하기보다 리액트에서 최대한 관리하는게 좋다. 리덕스 사용을 최소화하기 - stateful (x) stateless (o)

 

③ 과제

• 깃 , 깃허브랑, 깃플로우의 차이점
• 스프링과 스프링부트의 차이점 ?
• trunk based development ( TBD 새로 주신 키워드 - 학습해보기 )

---

한시간 반동안 열심히 피드백을 주신 김선우 개발자님 감사합니다 : )

덕분에 많이 궁금증이 해소되고 배울 수 있었어요. 받은 피드백 잘 기억해서 개선하는 개발자가 되겠습니다.