[20220306] 개발자 일기 & TIL

가면 갈수록 그 회사의 코드가 문제를 일으킨다. 계속해서 '그 회사'라고 할 수 없으니 앞으로 클라이언트 S라고 하겠다.(Spaghetti code에서 따옴) 클라이언트 S의 코드는 고의로 유지보수가 어려우라고 짰다고 볼 수밖에 없을 정도로 악랄하다. 스프링 부트 프로젝트의 controller에서 repository를 이용해 필요한 데이터를 담은 객체에 필요한 데이터만 getter와 setter로 접근하는 것이  아니라, 일단 controller에서 repository를 이용해서 가격 변수를 모두 꺼낸다. 그리고 요청이 들어오면 if문을 통과하면서 필요한 변수를 예약 정보를 위한 다른 DTO에 넣어준다. 문제는 if문 분기에 해당하는 변수만 넣어준다는 말이다. 모든 가격 변수를 쓰지도 않을 거면서 일단 변수를 선언한다는 점이 어이없다. 그러면 DTO를 쓰는 이유도 없고 말이다.

 

이거는 지난 2월에도 언급했었는데 이번에 가격 계산에 문제가 생기면서 코드를 다시 보면서 어처구니없는 부분을 또 하나 발견했다. Repository로 List에 일정 객체를 받아오고 일정 List를 for문으로 돌리면서 각 경우에 따라 로직을 수행한다. 근데 Repository를 보니... @Query의 쿼리문에 limit 1이라고 쓰여있었다. 즉, 항상 한 건만 가져온다. 그런 List가 아니라 단일 객체로 받아오고, 요소가 하나밖에 없는 List를 for문으로 돌리고 있었던 게 된다. 이건 너무 의도적인 것 같다.

 

일단 이 코드의 악랄함 때문에 원래 요청사항을 해결하는데 문제가 있었던 거 같다. 코드를 이해하는 데 정신을 쏟다 보니 가격 계산 기능 신경을 못쓴 것 같다.

 

일단 어느 정도 고쳤다 싶은 것을 금요일에 반영했는데 문제가 있다고 해서 토요일에 다시 되돌렸다. 일단 내 심정은 말하지 않아도 다들 알 것이므로 생략한다.

 

TIL

Spring 컨트롤러가 여러 개일 때 공통의 기능을 특정 컨트롤러에 넣을 경우 다른 컨트롤러에서는 사용할 수 없다. static으로 메서드를 선언해도 내부에서 참조하고 있는 repository 같은 객체들도 static으로 선언해야 해서 문제가 생긴다. 그렇다고 다른 컨트롤러를 new 예약어로 생성하는 것은 스프링의 동작 원리에 반한다. 스프링은 IoC 컨테이너에게 객체 생성 권한을 위임했는데 자기가 직접 객체를 생성하게 되기 때문이다. 그래서 대안을 찾은 것이 service에 메서드를 넣는 것이다. service의 기능이 비즈니스 로직을 담당한다고 개념적으로만 알고 있었는데 이번에 찾아보면서 역할을 좀 더 이해하게 된 것 같다. 컨트롤러에서는 비즈니스 로직을 모아서 서비스로 이관시킨다. 그러면 스프링 Web MVC는 다음과 같이 레이어가 분리된다.

 

Controller - Presentation Layer

Service - Business Layer

DAO/Repository - Persistence Layer

DTO/Entity - Database Layer

 

즉, 컨트롤러에서는 웬만하면 Presentation과 관련된 기능만 넣도록 해야겠다. 예를 들면, 뷰에서 사용할 model 객체에 비즈니스 로직에서 수행한 결과를 넣어주기, 어떤 뷰를 반환할지 결정하기 등이다.