GitHub 저장소
STEP 2 목표
변경 사항
개선할 점
배운 점
궁금한 점
나가며
📆 기간 : 2023.03.16~ 2023.03.27
들어가며
이번 3,4 단계에서는 처음으로 db를 사용해보았다. 재미있었지만 또 어려웠다. 학교에서 db를 배울 때 재미있었는데 실제로 자바에서 사용해보려니까 조금 다른 감이 없지 않아 있었다.😂
GitHub 저장소
STEP 2 목표
추가된 요구사항
- 승패 및 점수 계산
- 어플리케이션 종료에도 db적용을 통해 재시작이 가능해야 한다.
DB를 잘 사용해보는 것이 step2 의 목표이다.
변경 사항
Status
status 명령어를 통해 점수를 알 수 있다. 처음에 명세를 보고 이해를 하지는 못하였으나 게임을 시작하였을 경우 status입력을 통해 입력한 상황에서 점수와 승,무,패를 출력하는 방식으로 구현하였다. 왕이 잡혀 게임이 끝날 경우에는 점수를 출력하지 않고 승패만 출력하였다.
PieceType
처음에는 기물별로 isPawn, isKing, ... 과 같은 기물을 검증하는 방식을 사용하였다. 하지만 이렇게 진행하다 보니 인터페이스에는 한 기물을 위한 메소드가 계속해서 생겼다. 이렇게 진행하는 것 보다 PieceType이라는 enum을 갖고 원래 기물이 상수로 가지고 있던 형식(고유 이름, 점수) 들을 enum타입에 넣고, 기물이 어떤 기물인지 인지할수 있다 라고 생각하여 수정하게 되었다. 물론 처음부터 이렇게 한 것은 아니였다. 예를들어 왕 기물이 자신이 왕이라는 타입을 가지고 있어야 할까? 라고 많이 고민 하였다. 결국 기물타입을 사용한 이유는 자신의 타입을 가지고 있을 필요는 없지만 가지고 있음으로써 취할 수 있는 이점이 좀 더 많은 것 같아서 이렇게 선택하였다.
게임 흐름
HOW TO RUN
- docker-compose 파일을 이용하여 DB 띄운다.
- 자동으로 ddl 파일이 입력된다.
- 게임을 시작한다.
- 게임 이름을 입력한다.
- 게임 이름이 존재할 경우 저장되어 있는 특정 게임이 불러와진다.
- 게임 이름이 존재하지 않을경우 새로운 게임이 시작된다.
- start 후 게임을 진행하고 end를 입력 할 경우 DB에 게임이 저장된다.
- 왕이 잡혀 게임이 end 되었을 경우 DB에 게임이 저장되지 않는다.
DB 연결
나는 처음에는 삼성 노트북을 사용하느라 윈도우의 로컬, 도커 환경에 익숙했는데 맥북으로 바꾸면서 어려워졌다. 그래서 처음에는 맥북의 로컬에서 진행을 하며 구현을 하고 후에 도커로 사용하였다.
자바에서 db연결은 능숙하지 않아서 네오가 수업시간에 진행한 코드로 진행을 하였다.
다만 db connection을 어떻게 처리하면 좋을지에 대해 생각을 해봐야할 것 같다. 토니는 DB pool을 생각해보라 하였다.
DB 설계
나는 이번 체스 db로 체스 방을 통해 입장하여 게임방 이어하기를 구현하고자 하였다.
그러다 보니 테이블은 게임 테이블, 보드 테이블 두개를 설계하였다.
Game테이블은 게임의 이름과 그 게임의 순서를 두었다.
board테이블은 보드 이름(외래키), file좌표, rank좌표, 기물 타입, 기물의 팀을 두었다.
DAO
service레이어에서 dao를 통해 db와의 접근연결을 할 수 있도록 진행하였다.
개선할 점
TDD
고질병이다. 처음에는 잘 진행하다가도 리팩토링을하고 새로운 로직을 추가 하는데 있어서 TDD적인 부분을 잘 신경쓰지 못하는 것 같다. TDD가 은총알은 아니지만 도메인 로직을 짤때는 적용해보는 습관을 가지면 좋을 것 같다.
DB
실수로 잘못된 ddl을 올렸다.. 그래서 게임이 정상적으로 작동하지 않았다.
패키지 경로
테스트 패키지 경로에 관해 실수를 하였는데, 인지하지 못하고 있었다. 또한 test 더블인 fake객체는 test패키지에 있는 편이 좋다고 하여 수정하였다.
배운 점
정적 팩토리 메소드
util 패키지
DCI패턴
Instance of 사용
자세한 메소드 네잉밍 컨벤션
Docker DB사용
Dao
테스트 더블
커넥션 풀
try-with-resource
궁금한 점
JDBC에서 db연결 비용을 줄이기 위한 방법 ?
jdbc에서는 db연결을 위해 connection을 생성하는 비용이 무척 큰 것으로 알고 있다. 그래서 처음에는 connection을 한번 생성하고 사용하였는데 이를 더 좋게 사용할 방법이 있는지 궁금하다.
보통 현업에서 DB와 연결에 대해 고려할 때에는 커넥션 풀 이라는 개념이 사용되어요. 이는 여러 요청을 받을 수 있는 웹 서버가 커넥션을 관리할 수 있는 방법이다. 하지만 지금의 체스 는 굳이 커넥션 풀을 사용할 필요가 없어보인다.
DB테스트를 작성하는 좋은 방법
현재 테스트를 사용하기 위해서는 실제 db를 띄움으로써 처리하여야한다. 그러면 테스트를 위해 db 사전 준비를 해야하는 경우가 발생하는데 이를 해결하는 좋은 방법이 뭐가 있을까 ?
목, 스텁, 페이크 와 같은 객체를 사용해 테스트 더블을 할 수 있다. DAO는 두가지 역할을 한다. 1. 쿼리를 통해 db를 찔러서 데이터를 가져온다. 2. 입력받은 정보를 기반으로 반환해야하는 정보를 반환한다.
1번은 db커넥션, 작성쿼리가 잘 반영되는지 실db를 띄워서 테스트하면 좋다. 2번은 db커넥션,쿼리가 잘 동작한다고 가정하고 입출력을 검증하면 된다고 생각한다. 이럴 경우 테스트 더블을 쓴다.
나가며
처음으로 db에 관하여 작성을 하였다. 재미있었지만 어려웠다. 이번 체스 미션을 통해 많은 것을 배웠던 것 같다. 중간에 레벨인터뷰라는 과정이 있어서 100% 시간을 투자하지는 못했지만 최대한 배워가면서 해보려고 노력했던 것 같다.
'우아한테크코스' 카테고리의 다른 글
[우아한테크코스 5기] 웹 자동차 경주 1단계 학습 로그 (1) | 2023.04.23 |
---|---|
[우아한테크코스 5기] 레벨1 레벨인터뷰 회고 (0) | 2023.04.06 |
[우아한 테크코스 5기] 체스 1단계 학습 로그 (0) | 2023.03.26 |
[우아한 테크코스 5기] 블랙잭 2단계 학습 로그 (1) | 2023.03.18 |
[우아한 테크코스 5기] 블랙잭 1단계 학습 로그 (0) | 2023.03.12 |