[항해플러스] Back-end 6기 - 1주차 회고

과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제

동시성

• 처음 동시성 문제를 단순하게 한 명의 사용자가 접근하는 방식이라 생각하여, Synchronized와 Blocking Queue를 생각했다.

TDD

• 테스트를 얼마나 작성해야할지 감이 잘 안와서 고민이 많았다.

 

문제를 해결하기 위해 어떤 시도를 하셨나요?

동시성

• Q&A를 통해 동시에 여러 사용자가 접근할 수 있다는 것을 깨닳았다.
• 이에 따라, 사용자 ID를 기반으로 인메모리 Lock을 관리하는 클래스를 만들어주었다.

TDD

• 서비스 로직에 대한 실패 위주 테스트를 진행했다.
• Interface를 적극적으로 활용하여 Stub 객체를 활용할 수 있도록 구현했다.

OOP

• 테스트를 진행하면서, 테스트하기 불편한 구조를 나누는 연습을 통해 객체간의 의존성을 덜어내는 시도를 했다.

 

문제를 어떻게 해결하셨나요?

동시성

• Lock을 거는 방식을 통해, 사용자 별로 동시성을 확보했다.
• 또한, RetrantLock의 생성자 파라미터에 true를 주어 각 사용자의 동시접근에 대한 순서를 보장할 수 있도록 구현했다.

TDD

• 3명의 사용자가 동시에 포인트 적재, 사용에 대한 요청이 들오면, 설정한 Lock에 의해 정상적으로 동작하는지를 테스트하여 문제가 되는 코드가 있는지 테스트해보고 수정하는 방식으로 문제를 해결했다.

OOP

• OCP에 따라 포인트의 충전과 사용은 해당 포인트 객체에서 수행해야 한다. 이에 따라, 기존에 서비스 로직에 존재하던 충전, 사용 관련 연산을 포인트 객체 내부로 옮겨서 연산을 수행할 수 있도록 처리했다.

아키텍처

• 단일 클래스로 존재했을 때, 테스트하기 불편했던 구조를 Interface와 Stub을 통해 단위 테스트하기 좋은 구조로 변환하여 의존성을 제거해줬다.

 

 

알게된 것

Fake와 Stub

• 코드리뷸르 진행하다가 Fake와 Stub이 서로의 코드 간에 사용방식이 같은 부분을 발견했다.
• 이에 조사를 해본 결과, Fake객체는 동적인 상황에 사용하고 Stub객체는 정적인 상황에 사용해야하는 것을 깨닳았다.

LockContainer에 대한 테스트 미흡

• Lock을 담당하는 객체 또한 테스트 대상이었는데, 이 부분을 체크하지 못 하고 넘어갔었다.

---

Keep : 현재 만족하고 계속 유지할 부분

• 객체를 OOP적으로 짜야한다는 생각은 가지고 있었지만, 이를 고민하고 코드를 구현해본적이 없었는데, 이번 기회에 이를 실천으로 옮기게 됐다.
• Interface에 대한 필요성을 다시 철저하게 느꼈다.

 

 

Problem : 개선이 필요하다고 생각하는 문제점

• 아직 꼼꼼하게 테스트하지 못 했던 까닭에 놓친 부분이 있었다.
• 생각이 너무 많아서 구현을 바로바로 옮기지 못 하는 문제가 아직 많이 남아있다.

 

Try : 문제점을 해결하기 위해 시도해야 할 것

• 조금 더 꼼꼼하게 테스트하고, 작은 부분인만큼 아키텍처와 TDD를 잘 이해하고 수행할 수 있도록 노력해야겠다.
• 테스트 중심으로 구현을 빠르게 진행하는 시도를 더 많이 해야겠다.

---

 

추가적으로, 항해에 참여하고싶다면 다음 추천 코드를 통해, 다음 과정에 대한 할인을 받아보는 것도 좋을 것 같습니다 ㅎㅎ

 

추천인 이름: 이철진

추천인 코드: rYq2PX