레거시 Spring Framework Project 패키지 리팩토링

오늘은 팀원들과 협의해 리팩토링을 진행했던 이야기를 정리해보려 합니다.

새로운 회사, 새로운 팀원, 기존 인원들의 개발 스타일에 적응해 나가며 이것저것 건의하고 의견을
들어보고 개선해 나가야할 점들을 피력하고 있습니다.

입사초기 Spring Framework와 Mybatis로 구성된 백오피스 서버  추가 기능개발 및 유지보수 업무를 진행했었습니다. 업무를 진행하며 큰 허들을 느꼈던 부분이 있었는데 그부분은 바로 지금은 너무나 당연 Dto 대한 책임
분리였습니다.

Spring Web Server를 구현한다면 일반적으로 데이터 전달을 위해 Dto를 많이 활용하실 겁니다. 다만
제가 기능 추가, 유지보수업무를 받은 프로젝트는 모든 데이터를 HashMap으로 관리하고 상태를 변경하고 영속성에 저장하는 역할까지 책임지고 있었습니다.

이러한 이유로 코드로 도메인을 파악하는데 많은 노력이 필요했고 책임의 혼재로 인해 특정 상태값이 어느 비즈니스 로직에서 업데이트되고 프론트 응답을 위한 상태값인지 영속성 영역에 전달을 위한 값인지 도무지 분간이 어려운 상태였습니다.

이러한 문제점으로 인해 매번 해당 프로젝트를 수정할때 모두들 스트레스를 받는 상황이였습니다.
그래서 저는 모두가 스트레스를 받는 상태를 해소하기 위해 어떻게 이 문제를 해결하면 좋을지 고민하게 되었는데
다음과 같이 진행을 하게 되었습니다.
 
개선 프로젝트 진행 방법
1. 모든 요청, 응답, 영속성을 모두 HashMap으로 구성한 이유는 무엇인가?
2. 팀원 모두 이러한 문제점을 인지하고 있는가?
 
무엇보다 중요하게 생각한건 팀원들에 의견이였습니다. 그렇게 생각한 부분은 내가 생각한건 팀원들도 다 생각한 부분일 수 있고 제가 미쳐 생각하지 못한 문제점 때문에 그렇게 구성했을 수도 있기 때문입니다. 그리고 무엇보다 모두다 함께 개발을 진행하기 때문에 합의된 의견과 모두다 함께 개선하고 같은 규칙을 지켜나가야 이 개선점들이 빛을 발휘하기때문이였습니다.

개발팀원들에게 리서치를 해본경과 결론은 다음과 같았습니다.
1. 모든 요청, 응답, 영속성을 HashMap으로 처리한 부분은 초기 개발자분들이 임베디드 개발자셨기 때문에 객체지향적 개발 방법론에 익숙치 않아 HashMap으로 모두 처리했다.
2. 모든 팀원들이 이러한 문제점을 알고있고 개선해야할 부분이라고 인지하고 있었지만 백오피스를 담당하는 서버이고 그때그때 많은 시간이 소요되지만 기존 규격대로 개발을 진행해왔다.

위 리서치를 한 이후 아래와 같은 리팩토링 방향성을 잡게 되었습니다.
 

HashMap Refactoring

BackGround
책임의 혼재로 비즈니스 로직 파악이 어려운 부분을 해소하기위해 HashMap 리팩토링

ActionItem
Front -> Server 데이터 요청에 대한 객체는 dto/request 경로에 정리한다.
Server -> Front 데이터 응답에 대한 객체는 dto/response 경로에 정리한다.
Server -> Db 질의에 대한 객체는 dto/criteria  경로에 정리한다.
Db -> Server Db 질의 결과값은 vo 경로에 정리한다.
신규 개발건에 대해서는 HashMap 사용을 지양 한다.
HashMap이 사용된 기술부채는 기능 패키지별로 하나씩 해소해 나간다.

  project-root/
  ├── src/
  │   ├── main/
  │   │   ├── java/
  │   │   │   └── com.temp/
  │   │   │       └── exam
  │   │   │           └── dto/
  │   │   │               └── criteria/: Server -> Db 질의 객체 
  │   │   │                   └── ExamCriteria.java
  │   │   │               └── request/: Front -> Server 요청 객체
  │   │   │                   └── ExamReq.java
  │   │   │               └── response/: Server -> Front 응답 객체
  │   │   │                   └── ExamResp.java
  │   │   │           └── vo/ : Db -> Server 결과값 객체
  │   │   │                   └── ExamVo.java

 
가장 중요하게 생각한건 HashMap 책임 분리를 위한 Dto구조이고 마지막으로 모든 기술부채를 한번에 해소하지말고 특정 기능들을 추가하거나 유지보수 해야할때 그때 해당 기능 패키지들의 구조를 우리가 정의한 구조대로 하나씩 개선해 나가자로 포인트를 잡았습니다.

이를 통해 팀원들에게 설명을 진행했고 모두가 공감했기때문에 해당 내용을 프로젝트 Readme에 정리하여 모든 팀원들이 나아가야할 방향성으로 정리하게 되었습니다.

리팩토링을 진행하며 가장 중요하게 생각했던 가치들을 정리해보겠습니다.
1. 왜 그렇게 하지 않았는지보다 왜 그렇게 하지 못했을까를 고민해 보자.
2. 팀원들에 이야기를 들어보고 어떤 공감대가 있는지 이야기 해보자.
3. 내가 틀릴 수 있음을 인지하고 다른 팀원들이 생각하는 다른 개선방법을 생각해보자
4. 팀원들에게 큰 부담이 가지않도록 점진적으로 나아갈 수 있는지 생각해보자.
5. 확신이 서지 않는다면 일부분 새로운 개선 방법을 적용해보고 평가를 받아보자.
 
마지막으로 클래스를 너무 많이 많들면 복잡해지지 않나라는 피드백을 받았었는데 복잡해 보이지만 실질적으로 새로운 기능을 추가하거나 유지보수를 할때 책임이 명확해지기 때문에 수정해야할 부분도 명확해진다고 설명드렸습니다. 
 
이러한 설명을 드릴 수 있었던 부분은 경험도 경험이지만 책을통해 용기를 얻은 부분도 있어서 해당 내용을 공유하며 글을 마무리 하겠습니다
 
책: 만들면서 배우는 클린아키텍쳐
" 웹 컨트롤러를 나눌 때는 모델을 공유하지 않는 여러 작은 클래스들을 만드는 것을 두려워해서는 안 된다. 작은 클래스들은 더 파악하기 쉽고, 더 테스트하기 쉬우며, 동시 작업을 지원한다. 이렇게 세분화된 컨트롤러를 만드는 것은 처음에는 조금 더 공수가 들겠지만 유지보수하는 동안에는 분명히 빛을 발할 것이다. "