업무 리팩토링에 대한 회고

Lee Seung Jae·2022년 2월 21일

diary

회고록

일단 만들고 끝내는 일명 SI 업체에서 벗어나고 싶은 욕구가 무엇보다 컸고,

그 결과 지금 서비스 회사로 이직하게 되었다. (이렇게 되면서 이전의 경력은 물경력이기에 모두 청산했다.)

그리고 이직한지 벌써 1달 반 정도가 지나가고 있다.

스타트업인지라, 먼저 있었던 사람들을 욕할건 아니다.

그렇지만 지금 그렇게 쳐나가면서 생겼던 기술부채로 인해서 신규 개발건이 들어왔을 때

유지보수가 힘든 점들이 많다.

무책임했던 누군가

기존에 있던 백엔드 개발자가 나가고 없었기에 모르겠지만 그사람은

~~자바에 엄청난 자부심이 있다고 했다.~~ <<-- 이렇게 하면 안되지만 정말 못짰다..🤬

협업이라는 것을 싫어했고, 자기의 의견이 맞았으며, 코딩 컨벤션 또한 지켜진게 없었다.

그리고 외주로 뭔가 개발이 왔던건줄 알았던 코드가 그 사람의 코드였다...

악취나는 코드의 예시들

클래스가 MAIN_CLASS, main_class, MainClass, mainClass 등등... 네이밍이 상당했다.

이걸 나의 사수분께서는 JDBC -> JPA로 리팩토링을 하고 계셨던 찰나에 내가 입사를 했던 것이다.

많이 봐서 익숙했던 HTTP 상태 코드도 쓰지 않고 커스텀으로 200을 정의했는데 이게 에러였나? 그랬다.

switch(STATUS_CODE) {
    case 200: 
    case 201: 
    case 202: 
    case 203: 
    case 204: 
    // 이렇게 엄청 많이 있었다
}

이렇게 아마 300번까지 있나 그런다.. 너무 보기싫다.. 😇

아니 ResponseBody를 전역에서 설정해준것이 바로 @RestController가 아닌가?

난 내 지식이 의심스러울 정도였다.

간략하게나마 써보자면...

예를들어 유저를 조회하려는 API가 있다고 하면..

나름의 컨벤션이 있던건 같다. 클래스 뒤에 1은 create, 2는 read, 3은 delete, 4는 update였다 ㅋㅋㅋㅋ

아직도 웃기다.. 🤣🤣🤣🤣

아 아래 예시는 조회인데 조회 API 클래스만 따로있다.

그러니까 위에서 했던 1, 2, 3, 4 일련의 동작들이 하나로 엮인게 아니라

1기능 당 1개의 컨트롤러다.

@RestController
public class h_user_info_2 {
    
    @ResponseBody
    @RequestMapping(value = "/pood/user/view/2", method = RequestMethod.POST)
    public String USER_INFO_LIST_VIEW(@RequestBody h_user_info_vo2 header) { // 이런식으로 받아온다.. + 조회인데 POST + api 뒤에 숫자도 붙는다..
        // 왜 실행하고 있는지 모르겠는 로직...
        // 뭐 대략 이런식으로 돌아간다
        return response;
    }
}

아무튼 뭐 이런식으로 구성이 되어있었으니 상당히 머리아프고 파악도 못해먹겠다.

그래서 사수도 엄청 답답했을 것이다.

이걸 JPA로 바꾼 사수님은 👍👍👍

하지만 그래도 이거로는 부족했다.

객체지향적으로 코드를 구성해보자

일단 바꾼것, 가독성을 높인건 사실 맞다.

하지만, 여기서도 문제가 있었는데 흔히 보는 JPA의 Repository인 UserRepository (예시)

이 Repository를 어떤 서비스에서 필요로 할 때마다 의존 주입을 해서 쓰고있던것이다.

여기서 이제 이것도 나는 바꿔야 겠다고 마음을 먹었고, 하나의 서비스 -> 하나의 리파지토리 를 의존하는 것이 가장 좋다.

라고 생각을 했다.

그리고 여러 비즈니스 로직을 담는 클래스 -> 서비스 인것 같은 뉘앙스가 많이 풍겼다.

스크린샷 2022-01-26 오후 9 55 21

흔히 볼 수 있는 Layered Architecture 로 구성이 되어있다.

근데 참조가 너무 많은거다. 😭 이 상황에서 퍼사드 패턴을 떠올렸다. 🤔

구성

그래서 Controller -> Facade -> Service -> Repository 로 의존의 흐름을 넘기는 것을 생각했다.

그래서 여러 서비스 클래스를 한데모아 Facade에서 각 서비스들을 조합해서 붙여주는 식으로 정리를 했더니

의존 방향도 틀이 맞춰지고, 서비스단과 리파지토리 단위테스트를 쉽게 가져갈 수 있게 되었다.

@RestController
public class Controller {
    private final Facade facade;
    
    public Controller(final Service service) {
        this.service = service;
    }
}

@Facade // 어노테이션을 새로 정의해주었다
public class Facade {
    private final Service1 service1;
    private final Service2 service2;
    private final Service3 service3;
    
    public Facade(final Service1 service1, final Service2 service2, final Service3 service3) {
        this.service1 = service1;
        this.service2 = service2;
        this.service3 = service3;
    }
}

// 이런게 3개 있다.
public class Service1 {
    private final Repository1 repository1;
    
    public Service1(final Repository1 repository1) {
        this.repository1 = repository1;
    }
}