현재 운영중인 학교 챗봇 서비스가 있는데,
java-spring 첫 프로젝트라 코드와 로직이 매우 비효율적이다.
원래는 교수님의 허락으로 연구실의 서버를 사용해 서비스의 응답 속도에 큰 문제는 없었는데, 졸업 후 서버를 무료 버전의 구글 클라우드 서버로 이전하여 응답 속도가 현저히 낮아졌다.
p95 응답시간이 2.9s에서 4.4s로 늘어났다.
**p95란 백분위율을 나타내는 것인데, p95가 4초라면 100개의 응답 중 95개가 4초 이하이고, 나머지 5개는 그 이상이라는 의미이다.
리팩토링 하려는 부분은 학교와 학과에 대한 공지사항을 알려주는 기능이다. 사용자가 기능을 요청했을 때, db에 저장된 사용자의 학과 정보를 가져와 해당 학과의 공지사항을 찾은 후 응답을 해주는 방식이다.
공지 데이터를 가져오는 순서는 취업, 공지, 학업 등 학과의 게시판에 있는 카테고리들이 저장된 카테고리 테이블와 카테고리에 해당하는 공지들이 저장되어 있는 공지 테이블 이렇게 나누어져 있다.
이전에는 단과대학별로 공지 데이터를 관리하여 category 및 notice의 레포지토리들이 각 10개씩 존재했다. Service 클래스가 다수의 Repository 를 참조하여 무리하게 여러 책임을 맡았던 구조였다.
이 때문에 Service 클래스에서는 switch-case문을 사용하여 어떤 단과대학인지 구분하는 코드를 작성해야 했고, 너무 무거운 클래스가 되었다.
이에 객체 지향 원칙인 SOLID의 단일 책임 원칙을 적용하여 하나의 서비스 클래스는 하나의 레포지토리 클래스만 접근하도록 모든 단과대학의 데이터를 하나로 합쳐 구조를 개선하였다.
이에 따라 코드 수정도 진행하였다.
우선 개발 로직부터 정정하였고, 중복 코드를 최소화하고, 장황한 메소드는 한 메소드에 하나의 역할만 하도록 여러 개의 메소드로 분리하는 작업부터 순차적으로 진행하였다.
이와 같이 Service 클래스에서는 데이터를 가져오고 가공하는 역할만 하도록 하였고
하나의 메소드는 5줄이 넘어가지 않도록 분리하였다.
이전에는 카테고리에 해당하는 공지id와 공지 내용 등을 HasMap 형태로 매핑하여 다시 데이터를 추출하고 찾는 과정이 필요해 코드가 매우 복잡해졌었는데,
리팩토링 시, List 형태로 바로 반환하여 불필요한 데이터 변환 과정을 제거 하였다.
이렇게 전체적으로 불필요한 코드도 많이 제거하고, 로직도 더 간소화시켜 응답 속도가 4.27s 에서 1.06s으로 눈에 띄게 감소하였다.
특별히 디자인 패턴의 구조라던지 객체지향의 원칙과 같이 이론적인 개념을 적용한건 아니지만, 단순히 중복 코드를 제거하고, 로직을 단순화시킨 것만으로도 이렇게 큰 속도 차이가 난다는 것이 새삼 놀라웠다..
여기까지가 1차 리팩토링이었고,
디자인 패턴과 객체 지향 프로그래밍에 대해 더 공부하여 다시 한번 리팩토링을 점점 개선해 나갈 예정이다.
