지난 주 Redis 에서 Transaction 을 주제로 포스팅 했는데, 오늘은 해당 트랜잭션이 잘 동작하고 있는지 테스트를 작성해 보았다. 트랜잭션에서 가장 중요하게 다뤄져야 할 부분은 원자성이므로, 테스트 대상은 트랜잭션 중간에 예외가 발생했을 시 롤백의 여부가 되겠다. 강제로 예외를 발생시키는 부분을 코드 중간에 넣어서 테스트를 해봐도 되지만 그렇게 되면 테스트 시에는 기존의 멀쩡한 비지니스 코드를 건드렸다가 배포시에는 다시 해당 예외 코드를 지워야 하는 번거로움이 생기며, 테스트의 자동화라는 목적도 무색해진다. 어떻게 기존의 코드를 건드리지 않고 예외를 던지게 할 수 있을까? 를 고민하다가, Decorator 패턴 / Proxy 패턴에서 그 답을 찾았다. Decorator 패턴 / Proxy 패턴..
전체 글
사실 DP 문제는 겁부터 난다. 다른 알고리즘과 마찬가지로 익숙해지고 많이 풀어보면 쉽게 느껴지지만 처음에는 도무지 내 지능이 닿지 못하는 영역인것만 같은 느낌이 들고, 그 좌절감이 참 씁쓸하기 때문이다. DP 문제는 가장 쓴 맛이 컸던 알고리즘이었다. 쉬운 문제부터 천천히 시작하자는 마음으로 만만한 녀석을 골랐다. 초기 아이디어 사실 타일 채우기는 DP 의 가장 쉬운 문제인 피보나치와 닮아있다. 다만 이전 타일에서 새로운 경우의 수를 곱해주는 것과 별개로 아예 새로운 배열이 생겨난다는 점을 염두에 두어야 한다. 처음에는 dp[n-2] *3 + dp[n-3] *2 두가지만 고려했었는데, 아예 새로운 배열도 나오겠구나 라는 생각에서 dp[n-2*i]*2 로 전부 더해주어야 한다는 생각에 닿았다. 문제풀이 ..
어제 토비의 스프링 5장 챕터를 읽으면서 Transaction 의 원자성 에 대해서 처음 알게 되었다. 사실 Transaction 을 선언함에 있어서 가장 중요하고 핵심적인 이야기로 보이는데, 이걸 이제서야 개념적인 지식으로 습득했다는 데서 다소 충격적이었다. 가끔씩 Service 단에 Transaction 이 진행되는 메서드를 작성하면서 뚜렷한 이유는 없지만 왠지 모를 불안감, 다소 완성도가 떨어지는 듯한 느낌이 들곤 했는데, 바로 원자성에 대한 보장이 없다는 점이 그 원인임을 알게되었다. 이걸 깨닫고 TIL 에 Transaction 의 특성 4가지를 정리해서 아주 그럴듯하게 정리해놓고 싶었지만 솔직히 원자성 이외의 특성들에 대해서 잘 알지도 못하면서 떠드는 것은 기만같다. 그래서 간단하게 원자성에 대..