Week4 ‐ 멘토링

공통 질문

• 현재 서버에서는 노드의 정보를 id, 자식 정도만 가지고 있고, 실제 위치는 클라이언트쪽에서 텍스트 크기를 재서 노드의 크기를 측정한뒤 → 정렬을 통해 위치를 결정하고 있습니다. 그런데 노드 이동 기능이 생기면서 노드가 이동중인 모습도 다른 클라이언트와 실시간으로 보여주고 싶은데, 그럼 정렬을 서버에서 해야할까요?
  • 코루틴
    • default dispatcher→ 정렬
    • ui dispatcher → 그리기 (최적화)

AOS

• 콜백 패턴이 사용하기에 간편해서 저희 프로젝트에서 많이 사용하고 있습니다. 현업에서도 콜백패턴을 많이 사용하는지 궁금합니다. 또는 웬만하면 코루틴/RxJava 같은 비동기 처리를 이용하시는지 궁금합니다.
  • 그리고 콜백 패턴을 구현할 때 lamda 식으로도 구현할 수 있고, interface로도 구현할 수 있는데 이 두가지 방법 중 선택할 때 어떤 기준을 가지고 선택해야할까요?
• 테스트코드보단 실제 동작 구현을 집중해서 개발하고 있습니다. 테스트코드의 중요성은 알고있는데 현업에서는 어떤 테스트 코드를 작성하는지 궁금합니다.
  • 질문이 너무 모호한거 같아서 죄송합니다 ㅠㅠ
  • 그리고 codelab에 보면 테스트 함수의 네이밍이 operationAdd_otherTime_equal 이런식으로 테스트대상_action_기대결과 형식으로 작성되어있어서 따라했는데, 이러면 ktlint에서 함수이름이 snake case라서 걸리게 되더라고요. 현업에서는 테스트 코드에 대해서는 따로 함수이름 규칙을 설정해두도록 하고 사용하시나요?
• 저번에 sealed class에서 copy를 직접 구현해야할 지 질문 드렸었는데요! 보내 주신 코드 느낌대로 해보니까 약간 디자인 패턴의 생성 패턴 중에 Builder 패턴처럼 사용하게 되는 것 같아요! 의도하신 바가 맞는지 궁금합니다!

BE

• 지금 nest-JS/cache-server 안에 있는 코드가 cache-server를 만든 코드인데, 캐싱 기능과 DB에 전송될 데이터들을 모아서 전송하기 위한 기능이 같이 존재하고 있습니다. 각 기능을 하기 위한 api 들을 모두 설정해 놓은 상태입니다. 저희 서버 구성이 VPC 환경에서 서브넷을 public 과 private를 나눈 상태에서, 데이터 관련한 것은 private에 넣어야 할 것 같다고 생각이 들어서, cache-server를 private에 넣고, BE와 통신하는 식으로 구성하려고 하는데, 저번주에 말씀하신 네트워크 비용을 생각하여 cache-server를 따로 두지 않고, BE 코드에 합치는게 맞을지 고민입니다.
• MySQL과 MongoDB를 사용해서 데이터를 저장하려고 하고 있습니다. MySQL은 prisma로 진행했고, MongoDB에서 prisma를 사용해보려고 했는데, prisma는 트랜잭션 기반이라서 NoSQL과는 맞지 않는다는 생각이 들어서 Mongoose로 진행하려고 합니다. MongoDB에서도 Replica Set를 설정해서 prisma를 돌아가게 할 수 있는데 Mongoose를 사용하는 게 맞을지 아니면 MongoDB를 사용하는 것도 prisma를 적용하는 게 맞을지 고민입니다!
  • prisma를 계속 사용할 경우: MongoDB에서 replica set을 설정해야 한다.
  • Mongoose를 계속 사용할 경우: 데이터 베이스 사용에 추상화가 필요할 것 같다.
• 마지막 과정에서 주요 유즈 케이스에서 문제가 없는 게 중요함!

멘토링 내용

• 공통 질문
  • Q1
    • 1프레임 단위 같이 짧게 하기보다는 적절한 지점을 찾아서 서버에 전달해주면서 하면 될 거 같다. 1초 정도로 해도 충분할 거 같다.
      • 최적화는 그 이후의 도전이 될 것이다.
    • 보통 게임에서 많이 나오는 경우가 많다.
    • MMORPG 같은 경우는 핸드폰 최소 사양이 좋다.
    • node.js는 실시간에서 한계가 명확하다. MMORPG 같이 하려면 보통은 C++ 혹은 C에서 패킷을 건드려야 할 정도이다. 요즘은 Rust도 올라오고 있지만 Rust도 좀 부족함.
    • 나중에 최적화 할 때 코루틴을 사용
      • default dispatcher→ 정렬
      • ui dispatcher → 그리기 (최적화)
  • 리뷰하면서 정답이 없는 것들이 많다고 느끼는데 어떤 점을 중점으로 하고 받으면 좋을까요?
    • 앱을 여러가지 테스트 해보고 코드를 보는 편.
    • 지적을 하는 것보다는 이렇게 하는 방법도 있다고 알려주는 편이다.
    • 빠진 테스트 케이스 등이 보이면 그런 테스트 케이스를 알려주는 편이다.
    • 자신의 주관을 가지고 코드를 작성했다면 반드시 수정할 필요는 없다.
• AOS
  • Q1
    • 어떤 것이 더 좋다고 할 수는 없다. 각자 취향에 맞는 걸 사용하는 게 맞다. 콜백 패턴을 사용할 때 더 좋은 가독성이 나온다면 콜백 패턴을 사용하는 것도 좋을 거 같다.
    • 비동기적인 처리가 필요하지 않다면 코루틴/RxJava를 꼭 사용할 필요는 없을 거 같다.
  • Q1 - 1
    • 람다식으로 구현했을 때 장점도 있지만, 가독성이 떨어질 수도 있다.
    • 매개변수가 많아질 때 많이 복잡해지기도 한다.
    • 간단한 수식은 람다식이 좋긴 하다.
    • inline 함수에 대해서 공부해보는 것도 좋다. 람다식을 무방비로 사용하는 것을 방지하기 위해서 inline 함수 등이 나왔다.
  • Q2
    • ui 테스트, 유닛 테스트, view model 테스트
      • ui test → https://developer.android.com/training/testing/espresso?hl=ko
    • 현재 회사 기준으로는 하나의 기능을 구현할 때 view model 테스트 → ui 테스트 순으로 구현하고 있다.
    • Junit, MockK kotest, mockito
    • 테스트 도구를 어떤 것을 사용하는 것이 중요하기 보다는 중요한 기능에 대해서 테스트를 하는 점이 더 중요하다.
    • api를 호출한 다음 예상한 결과가 나왔는지 안 나왔는지를 테스트 하는 편이다.
    • view model에는 api 뿐 아니라 다른 코드들도 있는데 각각에 대해 성공과 실패를 테스트한다.
    • 현업에서도 테스트 코드를 작성하지 않은 사람도 많다. 다른 더 중요한 것들에 집중하지 않고 테스트 코드에 집착하는 것은 좋지 않다.
  • Q2 - 1
    • snake case로도 가독성이 좋아서 많이 사용하고, 요즘에는 영어보다 한글로 작성하는 분들도 많다.
  • Q3
    • companion object의 장점을 이용했다고 생각한다.
    • 나중에 코틀린에서 최상위 함수랑 companion object함수, 컨스터블 함수을 한 파일에 선언해보고 자바 코드로 변환해봐서 알아보는 것도 좋을 거 같다.
    • 코틀린에서는 자바에서와 다르게 builder패턴이 필요 없다는 것도 알아두시면 좋을 것 같다.
      • 생성자 하나라도 매개변수마다 값을 줄 수 있다.
      • 프로퍼티에는 get, set기능이 포함되어 있다.
• BE
  • Q1
    • DB서버 자체가 캐싱을 하는 기능이 어느정도 있다. 한 번 가져온 데이터들을 어느 정도 캐싱하고 있다.
    • 운영체제 쪽을 공부했다면 메모리가 디스크 읽는 속도보다 빠르다. redis는 휘발성이 높다.
    • mysql 캐시 쪽을 공부해보면 어느 정도 자료가 있다.
    • 스타트업 쪽으로 가는 게 아니면 인프라는 보통 인프라 팀이 하기 때문에 이것 때문에 프로젝트 계획이 어그러지는 것은 좋지 않을 거 같다.
  • Q2
    • 둘 중에 어느 걸 해도 괜찮을 것 같다. mongodb에 replica set을 했다는 것을 듣지 못했긴 했다.
    • 추천하자면 mongoose를 사용해서 둘 다 한 번씩 사용해보고 추상화 해보는 것을 추천한다.
• 생각해볼 기능
  • 다른 사람들이 사용하고 있는 노드라는 표시하기
  • 템플릿 기능
  • 마인드맵을 공유하는 기능