항해 플러스 1주차 회고

항해 플러스 1주차 회고

원래는 저번주에 작성했어야 하는 1주차 회고지만.. 2주차 과제를 받고 나서 2주차 과제를 해결하기 위해 나름(?) 공부를 진행하여 2주차 과제 풀이에 우선적으로 집중하느라 이제야 작성한다.

 

1주차 과제는 TDD 기반으로 진행하는 간단한 포인트 충전, 사용 API 과제였다. (HashMap으로 구성된 DB 구조)

TDD기반 개발 경험이 없는 나는 과제 시작 전에  급하게 '테스트 주도 개발 시작하기 - 최범균', '테스트 주도 개발 - 켄트 벡' 책을 빠르게 읽고서 1주차 과제를 진행했다. (정말 다행이라고 생각)

 

사실 개발을 하면서 단위 테스트 와 통합 테스트의 차이를 잘 이해하지 못했다. (1차 멘토링을 받기 전까지 @SpringBootTest를 사용해서 통합 테스트만 만들었다.)

 

1차 멘토링 후 의존성 관련 있는 객체들은 공부 목적으로 Stub으로 구성해서도 단위 테스트를 작성해 보고, Mock으로 주입받아서 단위 테스트를 만들었다. 단위 테스트를 하던 코드를 하면서 테스트하려는 기능에 대해서 책임을 확실하게 알 수 있었다. 예시로 포인트 충전 함수는 충전을 하면서 반환되는 값이 충전 내역 히스토리 테이블에 저장되는 값이 리턴되는데, 나는 단위 테스트를 구현하면서 충전된 값을 검증하는 과정에서 계속 결과가 다르게 나왔다. 내가 Mock을 전혀 이해하지 못하고 사용하고 있구나라고 느꼈다.

 

많은 고민을 하다가 코치님들께 얻은 정보는 충전 함수에 대해서는 충전을 하면서 이 함수의 책임은 테이블에 저장되는 값! 이기 때문에 실제로 충전된 값으로 검증하면 당연히 다른 결과가 나오는 걸 알게 되었고 충전하는 부분을 도메인 객체의 책임으로 변경하고 각각 서비스계층 함수들을 테스트를 무사히 통과할 수 있었다.

 

또 한 가지 이슈는 동시성 테스트..

멀티 스레드 환경에서 여러 사용자가 동시에 충전 및 사용하는 경우.. 사실 동시성을 고려하면서 개발해 본 적이 없었다.

그래서 이 동시성 테스트를 통과하기 위해서 많은 고민을 했다.

- 사용 및 충전에 대한 클라이언트 요청이 들어오면 Queue에 담아서 순차적으로 처리?

근데  실제로 요청을 Queue에 담아서 서비스를 순차적으로 처리한다는 게.. 로직 자체가 너무 복잡해질 것 같았고, DB 대신에 HashMap으로 사용하는 간단한 프로젝트에서 저렇게 복잡하게 처리한다는 것도 조금 이상하다고 생각이 들었다.

 

결론은 이번 과제에서는 동시성 테스트는 크게 비중이 없었고, 실제 DB를 사용하는 환경이 아니었기 때문에 syncronized 키워드로 처리했다. 물론 실제 프로젝트에서는 synchronized를 사용할 일이 있을까(?) 아마 없을 것 같다.

 

synchronized (하나의 공유자원에 동시에 접근하지 못하도록 막는 것)

여러 개의 스레드가 한 개의 자원을 사용하고자 할 때 현제 데이터를 사용하고 있는 해당 스레드를 제외하고 나머지 스레드들은 데이터에 접근할 수 없기 때문에 많은 트래픽이 몰릴 경우 성능저하가 일어날 수 있다.

즉, synchronzied로 지정된 임계영역은 한 스레드가 이 영역에 접근하여 사용할 때 lock이 걸리고 다른 스레드가 접근할 수 없게 된다.

이후 해당 스레드가 이 임계영역의 코드를 다 실행 후 벗어나게 되면 unlock 상태가 되어 그때서야 대기하고 있던 다른 스레드가 이 임계영역에 접근하여 다시 lock을 걸고 사용한다.

 

30명의 사용자가 동시에 충전을 할 경우 1명씩 순차적으로 처리된다.

 

2주차가 거의 끝나가는 시점인 지금 그래도 단위 테스트랑 아주 조금(?)은  친밀감이 느껴지고 TDD에 대한 장점도 많이 알게 된 것 같다.

아직은 테스트 코드를 작성하면서 개발을 한다는 부분이 설계하는 과정에 있어서 많이 어렵지만, 이 또한 적응이 될 거라고 믿는다.

 

10주라는 기간 동안 나는 죽었다 생각하고 좋은 경험을 통해서 많은 걸 얻고 싶다.

업무와 병행하느라 지치지만, 앞으로 진행할 미션을 전부 통과하기 위해서 평일엔 적어도 2시간 이상 투자를 할 계획이다.