[개별 멘토링] 2024.11.24 이시은

이번주 문제 해결 경험

한국투자증권 웹소켓 끊기는 문제 해결

트러블 슈팅 페이지에 정리되어 있습니다.

마이페이지 내 자산 조회 API

이번 스프린트에서 제가 담당했던 기능은 마이페이지에서 자산을 조회하는 API를 구현하는 부분이었습니다.

처음에 해당 기능에 대해 구상해볼 때에는 가지고있는 종목의 가격이 변화할 때마다 업데이트 해주는 방식으로 구현해야하나 생각했었습니다. 그러나, 그렇게 되면 DB에 접근하는 빈도가 너무 잦아지는 것 같았습니다.

소켓 테스트를 해 본 결과 한 종목 당 주가가 1초에 2번씩은 변화하는 것 같아 보였는데, 사용자가 한명이라고 쳐도 한 사용자가 20개의 종목을 사 두면 자산은 1초에 40번이나 바뀌어야하는 문제가 생겼습니다.

그래서 다음으로는 스케줄러를 통해 1분마다 현재 가격을 조회해 자산 DB를 업데이트하는 방식으로 구현하고, 마이페이지를 조회했을 때는 스케줄러를 통해 마지막으로 업데이트된 자산 결과를 보여주는 것으로 구현했었습니다.

그러나, 이 방식도 문제가 있었습니다. 만약 한 종목을 구매하고 1분이 지나지 않은 상태로 마이페이지에 접근하게 되면 구매가 반영되지 않은 결과가 보이기 때문에 자산을 제대로 확인할 수 없었습니다. 마이페이지에 접근할 때는 그 시점의 자산을 보여주어야 할 것 같았습니다.

그래서, 마이페이지 API를 조회하는 시점에서 DB를 업데이트해주고 업데이트된 결과를 반환하도록 다시 구현을 진행했습니다. 이렇게 구현을 진행하니 1분마다 스케줄러로 DB를 업데이트할 필요도 없을 것 같다는 생각이 들어 업데이트 주기도 10분으로 늘려주었습니다. 스케줄러로 업데이트된 자산 데이터는 추후에 친구 기능 또는 랭킹에서 활용될 예정입니다.

개별 멘토링 기록

멘토에게 전달하고 싶은 이야기를 정리해보세요. 개별 멘토링 24시간 전에 멘토가 미리 내용을 보고 올 수 있도록 공유해야 합니다. 개별 멘토링 이후에는 멘토와 나눈 이야기가 휘발되지 않도록 기록해보세요.

• 단위 테스트에 대한 고민
  • 단위 테스트를 어떻게 해야할지 잘 모르겠습니다… 제가 생각하는 단위 테스트는 작은 단위로 하나의 기능만 테스트하는 것인데, 작은 단위로 테스트한다는게 너무 어렵게 느껴집니다.
  • 제가 테스트하기 원하는 로직들은 거의 모두 private 메소드이고, 테스트를 위해 해당 메소드들을 public으로 변경하는 것은 아닌 것 같다는 생각이 듭니다.
  • 해당 private 메소드를 테스트하기 위해 private 메소드를 호출하는 public 메소드를 테스트하자니 이건 또 너무 큰 단위의 테스트라고 느껴지는 것 같습니다.
  • 멘토님께서는 단위 테스트를 어떻게 진행하셨나요??
• 분업을 하다 보니, 저 같은 경우에는 제 파트가 아닌 부분에는 소홀해지고 완벽히 이해하지 못한 상태로 넘어가는 경우가 더러 있는 것 같습니다. 제가 구현한 부분이 아닌 파트에 대해서 어느정도의 이해도를 가지고 있는게 좋을까요??
• 멘토님께서는 부스트캠프 하실때 문서화 어느정도로 하셨나요?? 문서화 하기가 쉽지 않은 것 같습니다…ㅠㅠ

---

• 장 마감 시에 바로 소켓 연결하도록 하는 로직 고민해보기
  • 장 마감 되면 소켓 연결할 필요가 없어서, 스케줄러 돌려서 8시쯤에 연결하는거도 괜찮을 듯
  • 만약에 onclose 그대로 간다면, 연결 횟수 제한
• 마이페이지 자산은 소켓으로 하는 것이 좋을 듯
  • 가격 변화할 때마다 바로바로 DB 업데이트하는 거는 고민해봐야 할 듯

• 테스트

  • private 메소드는 외부에서 접근을 하면 안되는 것만 private으로 하는 거도 괜찮다.

  • public 함수에 private 함수 여러개를 사용하면 그것이 하나의 기능 → public을 테스트하면 기능 테스트

  • 개발 후 테스트가 멘토님 취향

  • 하나의 기능을 추가하면 기능에 대해서 서비스 단위로 테스트하심

    • 멘토님께서는 Controller, Action, Service, Repository 레이어 사용 우리의 Controller, Service, DomainService, Repsitory와 매핑됨

    

• 다른 사람 코드 이해

  • 일단 불가능
  • 코드 리뷰 많이 하면 남이 짠 코드 읽는 게 익숙해짐
  • 현업에서는 남 코드 고친거 공유가 의무는 아니다
  • 상황에 따라서!

• 문서화

  • 스웨거 같은거 신경쓰기
  • 기술에 대한거, 트러블 슈팅 같은거는 많이 작성하는게 좋다.
  • SSE, 소켓 명세서 자세히 쓰는거 조음
  • 남들이 하는거 보고 배우기