레거시 코드 변경

유지보수를 어렵게 만드는 요소들을 모두 뜯어고치고 싶었다.

결국 제가 하고 싶었던 부분은 하나의 서버에서라도 통일된 방법으로 일관성있는 코드를 작성하고 처음 오신분들이라도 빠르게 코드를 분석하고 적응 할 수 있도록 기반을 만들어 놓고 싶었다.

코드파악중에 문제점 이라고 생각했던 부분

이정도의 문제점이 있었으면 아래와 같은 방법으로 해결을 했다.

1번의 문제는 비슷한 역활을 하는 DTO를 여기저기에서 마구 재활용을 하고 있었다. 그렇기 때문에 API 스펙이 변경되는 경우에 이곳저곳에서 문제가 터졌다.

그래서 우리는 단일책임원칙(single responsibility principle)을 지키기로 했다.

비슷하게 생겼어도 엄연히 다른 역활을 하는 DTO를 명확하게 구분하기 시작했고 하나의 문제를 고칠때 하나만 고치면 되는 상황으로 나아갔다.

데이터를 Request객체 Response 객체를 사용했고 서비스단으로 데이터를 넘길때는 wapping 할수 있는 클래스로 넘겼다. 명확히 단일책임원칙을 적용했다.

그래도 개발하면서 명확하게 중복되는 DTO는 따로 공통 패키지에서 관리를 했다.

2번의 문제는 소중히 다뤄야하는 엔티티 객체를 아무곳에서나 변경을하고 있었고 어디에서 어떻게 왜 데이터가 변하는지 추적하기 힘들었다. 그래서 setter 어노테이션을 모두 지우고 데이터의 불변성을 유지하려고 노력했다.

또한 entity 객체에 무분별하게 사용되었던 @Data 어노테이션을 제거하는 작업과 꼭 필요한 어노테이션만 사용하기로 했다.

뿐만 아니라 객체의 동등성 비교를 위해 equals와 hashCode 메소드를 오버라이드를 강제하였다.

3번의 예외처리에 대해서 통일된 방법이 없어서 어떤곳은 controller에서 일일이 try-catch를 하는 곳이 있는가 하면 예외처리를 하지 않는 곳도 존재했다.

이러한 부분을 해소하기 위해서 한곳에서 비즈니스 예외처리를 관리하기 시작했고 예외처리에 대한 유지보수가 편해졌으며 어떠한 예외가 존재하는지 가독성이 높아졌다.

4번은 단순히 서비스 로직에 어노테이션을 통해서 트랜잭션을 사용했다. 이를 통해서 더티체킹을 활용 가능하게 코드를 수정했다.

5번 의 문제를 해결하는데 가장 많은 고민을 했습니다. 그 이유는 DDD에 대한 이해 및 응용이 부족했었고 그러한 부분을 스터디를 통해서 고민들을 해결해 나갔다. 아래와 같은 방법으로 문제를 해결해 나갔다.

객체의 상태변화를 setter를 통해서 변경되던 부분을 엔티티 객체 스스로 값을 변경 할 수있게끔 메소드를 통해서 변경을 하도록 하였다.

애매한 로직을 처리하기 위해서 하나의 유스케이스(어플리케이션 서비스)에서 도메인 서비스(도메인 규칙)을 따로 관리를 했다.

즉 DDD 관점의 프로그래밍을 통해서 코드 자체가 주석이 되도록 코드를 작성하고 싶었다.

6번 유스케이스의 코드를 아주 직관적으로 리펙토링하기로 했다. 비개발직군의 동료와 코드를 보며 소통하기 할 수 있을정도의 직관적

방향으로 가기로 했기 때문에 일급 컬렉션을 이용해서 줄이기로 했다.

이러한 형태로 코드를 리펙토링하면서 생겼던 고민들은 많은 패키지가 생겼으며 단일책임원칙을 지켜가면서 중복제거를 해야한다는 어려움과 명확하게 도메인 규칙을 분리해내는데 어려움을 겪었다.

AwakeDev