이번 회고록 또한 저번 프로젝트 회고록과 마찬가지로 늦은 감이 있다.
이번 회고록의 목적은 학생 신분의 재정상 유지하기가 어려운 서버 비용때문에, 서비스 배포를 유지할 수 없었기에
이 프로젝트의 완성도를 기록하고, 회고하는 것이다.
이 회고록의 목적이 기술적 기록이 아닌 프로젝트의 완성도에 대한 기록이니만큼, 코드나 기술적 설명 없이 Api 호출에 대한 캡처 내용으로 구성된다.
로그인, 회원가입과 같은 기본적인 기능을 제외하고 주요 기능이라 판단되는 Api들을 위주로 작성할 예정이다.
추가적으로 해당 기능을 개발하며 겪은 고민과 트러블 슈팅등 또한 간략하게 소개해보고자 한다.
프로젝트 소개
해당 Stock-simulation 프로젝트는 프로젝트 이름 그대로 모의 주식 투자 서비스이다.
가상의 돈을 사용하여, 실제 주식 변동에 대해서 가상의 주식을 사고 팔수 있도록 제작하였다.
평소에 주식투자를 해보고는 싶었지만, 돈이 없고, 잘 알지 못하여 항상 미뤄왔었지만
매번 주식에 관련된 뉴스를 보며, "아 나도 사놓을걸" 하는 아쉬움이 항상 들었었다.
그래서 투자에 대한 나의 감을 기르고, 나의 재능을 시험해보고자 이 프로젝트를 기획하게 되었다.
해당 프로젝트는 실제 주식 가격 변동에 따라서 실시간으로 주식 가격이 변동되며, 주식에 대한 지식이 많지 않은
나 혼자서의 토이 프로젝트이기 때문에 도메인에 대한 지식이 부족해 몇몇 이상한 점이 보일 수 있다.
API 요청 및 응답
해당 api들은 주요 기능만을 추려놓은 것으로 보다 더 많은 api들을 구현해놓았다.
api 테스트는 Postman을 통해 진행할 예정이며, 별도의 외부 서비스를 사용하는 api들에 대해서는 외부 서비스의 캡처를 사용할 것이다.
1. 실시간 주식 가격 업데이트
실시간 주식 가격에 대한 정보는 한국 투자 증권 KIS 의 open API를 사용하여, 받고 있다.
WebSocket 연결로 구독한 주식 정보에 관한 내용을 WebSocket으로 받아올 수 있으며, 받아온 주식 정보는 기존의 주식 정보와 비교하여, realTime db에 반영되거나, InfluxDB에 기록된다.
(여기에 주식 API WebSocket 사진)
아래는 RealTime DB를 적용하면서 한 고민들을 적어놓은 포스팅이다.
https://youngs-java-study.tistory.com/34
아래는 InfluxDB를 도입하게 된 과정을 적은 포스팅이다.
https://youngs-java-study.tistory.com/37
2. 매도, 매수
프로젝트가 주식 투자인 만큼 매도와 매수 기능은 필수적이다.
- 매수
원하는 주식의 코드와 갯수를 정해주면, 매수가 가능하다.
지금 보니 응답값을 boolean값이 아닌 좀 더 의미가 있는 값으로 사용했으면 더 좋았겠다 라는 생각이 든다.
- 매도
매도 기능 또한 마찬가지이다. 응답값이 아쉽다.
3. 계좌 조회
계좌를 조회하는 API이다.
이 기능에서는 계좌의 잔액을 함께 보여주어야 하는데, 이 잔액 업데이트를 하는 과정에서 많은 고민이 있었다.
어떻게 하면 잔액을 업데이트하는데 비용을 최소화할 수 있을까가 가장 큰 고민의 포인트였고, 난 이걸 realTime db로 해결했다.
이 외에도 동시성 문제등의 고민이 있었는데, 이건 아래의 포스팅에서 확인이 가능하다.
https://youngs-java-study.tistory.com/33
4. 거래 기록
해당 API는 거래 기록을 조회하는 API이다.
거래(매수 or 매도)를 진행하면 자동으로 거래 기록이 되도록 구현해놓았으며, 이또한 InfluxDB를 사용하여 기록할 수 있지만, 주식의 가격 변동과 같이 공공적인 데이터가 아닌 개인정보와 같은 거래 기록의 경우에는 RDB에 저장하여 데이터 관리를 해줘야 한다고 생각했기에, 이는 MySQL에 저장하였다.
여기까지가 이 프로젝트의 주요 기능들이다.
가장 힘들었던 것은 해당 프로젝트가 실제 주식 가격 변동을 받아와서 실행되는 프로젝트이니 만큼 일부 기능은 주식장이 폐장하는 순간 테스트를 해볼 수 없었다.
물론 test code로 진행하는 단위 테스트의 경우에는 진행할 수 있었지만, 통합 테스트는 할 수 없어서, 프로젝트 진행기간이 예상보다 훨씬 길게 늘어난 것 같다.
테스트 코드는 총 31개의 테스트 코드로 작성하였다.
저번 프로젝트에서 테스트 94개를 작성해보며 느낀점이, 굳이 없어도 될 테스트 코드를 짜서 무얼 하는가??
여서 최대한 정말 테스트 해봐야할 것 같다고 느끼는 부분만 테스트 코드를 작성하였다.
하지만 테스트 커버리지를 돌려보니 매우 낮은 커버리지율을 보였고, 테스트 커버리지에 대한 공부를 좀 해보았다,
사람들의 의견은 분분했다. 테스트 커버리지가 높아야 한다, 적당하면 된다 등등 여러가지 의견이 있었기에
나는 내가 직접 테스트 커버리지를 모두 경험해 볼 예정이다.
낮게, 적당하게, 완벽하게 테스트 코드를 모두 작성해볼 것이고, 이는 따로 포스팅을 할 예정이다.
만약 포스팅이 완성되면 이 바로 아래에 링크를 걸어두겠다.
ps. 다음부터는 꼭......그때그때 포스팅을 하자.....오래되니 기억이 잘 안난다...
'백엔드 멘토링' 카테고리의 다른 글
주식 프로젝트 influx DB 도입 ADR 과정 (0) | 2024.10.30 |
---|---|
[회고록] Triple Clone 프로젝트 API 완성도 기록지 (3) | 2024.09.28 |
주식 투자 프로젝트 실시간 Real time DB 적용기 (9) | 2024.09.06 |
계좌 잔액 업데이트 동시성 문제 해결 과정 (5) | 2024.09.03 |
객체지향적 Refactoring 과정의 기록 (1) | 2024.07.11 |