회고록
블로그를 옮기게 되어 날짜가 맞지 않는다.
작성일 : 2022년 2월 21일
서비스 회사로 와서 벌써 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를 어떤 서비스에서 필요로 할 때마다 의존 주입을 해서 쓰고있던것이다.
여기서 이제 이것도 나는 바꿔야 겠다고 마음을 먹었고, 하나의 서비스 -> 하나의 리파지토리 를 의존하는 것이 가장 좋다.
라고 생각을 했다.
그리고 여러 비즈니스 로직을 담는 클래스 -> 서비스 인것 같은 뉘앙스가 많이 풍겼다.
흔히 볼 수 있는 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;
}
}아무튼 이렇게 구성을 하게 되었다.
결과
결국 전체가 더러워질 바에는 서비스가 더러워져선 안된다고 생각을 했고,
많은 사람들에게 자문을 구한 결과도 다들 방금 한 얘기를 다들 하셨다. 감사합니다~ 🙏
무언가를 호출해서 모아주는 집약체인 퍼사드 클래스가 더러워지게 된거다.
기존 코드에 비해 엄청나게 개선 되었다고 생각한다. 중구난방인 의존을 한데 모았기 때문이다.
아무튼 한달반동안 많이 성장한것 같고 더 성장해야겠다.
갈 길이 멀고 나는 아직 배가 고프다. 더 많이 더 빨리 더 높게 성장하고싶다 👊 🔥🔥🔥🔥
'Diary' 카테고리의 다른 글
| ATDD, 클린 코드 with Spring 5기 수료 회고 (0) | 2022.08.14 |
|---|---|
| 블로그를 옮기고 최신 근황 (0) | 2022.08.13 |
| 업무 회고 (0) | 2022.08.07 |
| 1개월 1일 1커밋 회고 (0) | 2022.08.07 |
