[TodayKeywords] 오늘 공부한 키워드
애자일: 기민하다. 라는 뜻으로 애자일 방법론은 워터폴방식과 다르게, 짧은단위를 나누어 기능을 개발하고 요구사항 및 피드백을 통해 빠른 개선 및 개발을 진행하는 것.
[NextKeyworks] Study Queue
- HTTPS
- SOLID
- loop label
- CSV
- 파일입출력
- UML
- UTC
- epoch time / Instant time
- MVC
- URL ClassLoader
- Secure ClassLoader
- JNI
- GC
- HOF
- 자바 해시코드(hashCode)
- OSI 7 계층
- PCB
- 스프링 설계철학
- RESTful
- 준 영속성
- 지연로딩
- 프록시객체
- jpa - mybatis 의 차이
- orm - mapper 의 차이
- 쿠키/세션/로컬 스토리지
- HttpMessageConverter
[회고] 221216 : 리팩토링
오늘은 과제에서 가장 신경쓰였던 반복로직의 분리를 해결하기 위해 시간을 보냈다. 먼저 파사드 패턴에 대해서 스터디를 했을때, 파사드 패턴은 주로 하위 단계가 있는 과정에서 그것을 연속적으로 사용하는 경우에 쓰기위한 방법이다. 따라서, 특정로직을 주요로직들을 실행시키기 전에 실행한다라는 내 목적과는 맞지 않는 부분이 있어서 적용을 포기했다. 전략패턴, 어댑터 패턴등등 다양한 디자인 패턴들에 대해 조사해보았지만 나와 같은 문제에서 사용하기 적합한 로직을 발견 할 수 없었다.
그러던 중 Service 분리 라는 키워드를 검색해보았고, 이 글을 발견 할 수 있었다. 이 분은 서비스코드가 복잡해지는 것에 대한 고민을 하셨고, 그에 따라 관심사를 서비스단에서 컨트롤러단으로 옮기셨다고 한다. 글을 읽다보니 '어 그러고 보니, 인증/인가가 추가되면서 생성,수정,삭제에서 너무 많은 책임을 지고 있잖아..?' 라는 판단이 들었다. 생각해보니, 로그인의 요청을 받은 곳은 컨트롤러이니 요청받은 것을 해결하기 위한 책임은 컨트롤러에서 져야하지 않나..? 그럼 위 글 처럼 서비스를 분리시켜놓고, 그것을 필요한 것만 가져다쓰면 되지 않을까 라는 생각이 떠올랐다.
곧바로 리팩토링에 착수하였다. 서비스에 많은 책임을 가지고 있는 로직을 v1, 컨트롤러에서 많은 책임을 가지고 있는 로직을 v2로 정의하고, 컨트롤러와 서비스만을 리팩토링하였다. 기존 로직을 보면서 서비스 인터페이스를 작성하였는데, 처음에는 굉장히 쉽지 않았다. 하지만, 몇시간동안 헤매면서 작성하다보니 공통적인 패턴이 보였고 서비스 인터페이스를 모두 작성 할 수 있었다. 생각해보니, 이전서비스에서 이렇게 쪼개어 작성했고, 컨트롤러단에서 서비스들을 갖다가 썼었었다. 하지만, 서비스는 곧 비즈니스로직이라는 생각을 갖추게 되면서 의도적으로 모든 책임이 서비스로 몰리게 되면서 서비스에서 많은 반복과 복잡도를 지니게 만든것 같았다.
컨트롤러에서 잘 만들어진 서비스들을 과정에 맞게 잘 가져다쓰니, 큰 비용없이 눈에 보기쉬운 로직을 완성 할 수 있었다. 전체적으로 로직이 반복되기 때문에 그냥 필요한 순서에 맞는 것을 잘 가져다 쓰면 되었다. 또한 이렇게 되니, 서비스의 각 메소드는 자신의 역할에 맞는 비즈니스로직만 실행하면 된게 가장 큰 장점이었다. 즉, 서비스에서 외부의 로직을 신경쓰지 않아도 되었다. 리팩토링이라는 것을 항상 미뤄왔는데, 리팩토링을 통해 더욱 만족스러운 로직이 작성되는 것을 보면서 뿌듯함을 느꼈다.