드디어 겜린더의 핵심이라고 할 수 있는 게임 데이터를 수집하려고 한다.
게임 데이터를 하나하나 수기로 작성했던 입장에서 너무 힘들었던 기억이 있기 때문에 꼭 데이터 수집을 자동화시키고 출시하고 싶었던 목표가 있었다.
하지만 부랴부랴 출시만 했던 서비스라 백엔드에 아주 많은 문제점이 있었고, 결국 처음부터 다시 제작했었기 때문에 시간이 많이 걸렸다. (생각보다 많은 시행착오를 겪은 것 같다.)
시행착오 흔적들
Redis 스터디 및 겜린더 서버 설계
Redis와 FastAPI를 활용해 CRUD 만들기
겜린더의 DB의 문제점과 고쳐야할 것들
MongoDB는 겜린더에 적합한 DB일까?
그리고 우연히 용산에서 알바를 하다가 사장님도 데이터 수집에 관심이 있으셔서
Selenium을 활용해 여러 데이터 스크래핑 프로그램을 만들 기회가 있었는데, 만드는 과정 중 겪었던 경험을 기반으로 이번 스크래핑 봇을 잘 만들어볼까 한다.
과거에 스크래핑 봇을 제작할 때 내 코드를 보면서 아쉬웠던 점을 몇 개 뽑자면...
1. 기능 별로 나누지 못해 코드 가독성 최악
2. 무식한(?) 예외 처리
3. 어차피 내가 개발하고 유지 보수하는 거라 협업 따위 생각하지도 않은 변수명과 구조...
하지만 겜린더는 추후에 같이 해볼 사람이 있을 것을 고려하여
내가 할 수 있는 최선을 다해 코드를 잘 작성해 보려 한다.
항상 글을 작성할 때마다 아쉬웠던 점은 글도 글대로 못 쓰지만 시각화를 잘 못해서 아쉬움이 많았다.
나중에 내가 봐도 "아니 이걸 보고 누가 이해를 할 수 있으려나?" 라는 스스로의 의문도 많이 생겼었다.
그래서 이번엔 문서화도 잘해야겠지만 정확히 로직이 어떻게 돌아가는지 쉽게 알아볼 수 있는 시각화 자료를 만들어보고 싶다는 목표가 생겼다.
사실 좀 더 빠르게 프로젝트를 진행할 수 있었는데 하도 설계를 잘해보겠다고 노션에 정리도 해보고 고심도 많이 했지만 결국 테스트 코드 몇 줄 작성해 그에 맞게 설계도 바꿔보고 하면서 진행하는 것이 뭔가 노션에 뜬구름 잡는 것보다 나았다.
상세한 전략과 정리는 깃허브에...