이야기에 앞서,
취준 스터디를 진행하며
개발에 도움이 될 수 있는 영상을 보고 서로 이야기를 나누는 시간을 가졌다.
해당 링크는
https://www.youtube.com/watch?v=RVO02Z1dLF8 이고,
내용은
지속 성장 가능한 코드를 만들어가는 방법
에 대해 토스 페이먼츠 개발자분께서 말씀해주신다
해당 영상의 내용은,
패키지와 레이어, 그리고 모듈 중심으로 말씀해주셨다.
패키지
패키지는 현재 상황 점검하며 전략에 따라 응집에 대해 유연하게 지켜야 함.
예를 들어,
햄버거 클래스를 만들기 위해 빵, 치즈, 패티를 만들어줄 클래스들은
하나의 패키지(응집)에 있어야 하는것과 같다.
패키지를 만들때, 역할보단 개념끼리 뭉쳐라
즉, 햄버거 클래스를 예를 들면,
빵, 치즈, 패티라는 역할보단 햄버거 라는 개념으로.
하지만, 같은 패키지에 묶을 개념이 같은 클래스가 너무 많다면?
-> 하나의 패키지에 너무 많은 클래스가 있어도 응집이 깨진다.
-> 패키지에서 더 자세한 개념화를 진행하면 된다.
(햄버거 -> 싸이버거, 치즈버거, 새우버거)
이런식이면 import문을 통해서도,
'아, 이친구들은 햄버거와관련된 패키지에서 온걸 보니까 해당 패키지와 관련된 친구들이구나!' 라는 인식이 가능해진다.
관련된 내용을 설명하는 패키지는 다음과 같다.
아래 구조의 빨간색은, 카드와 관련된 클래스들에도 불구하고,
패키지의 구조상 중구난방으로 import문의 순서가 작성되어있다.
그러한 패키지 구조를 수정하면
"아, order와 store 개념 패키지(안에 카드라는 역할이 있는)로 지불을 사용하는구나!"를 알 수 있다.
더 가독성이 좋게 이렇게 바뀐다.
레이어
서로 잘못 참조하지(역류)하지 않아야한다.
스프링 MVC 패턴으로 예시를 들면,
컨트롤러 클래스에서 서비스 클래스를 참조하고,
서비스 클래스에서 리파지토리 인터페이스의 구현체 클래스 참조는 가능하지만,
그 반대는 허용될 수 없다! 이런식으로.
해당 내용을 지키지 않는다면,
장기적으로 코드가 복잡해지고 코드의 확장에 발목이 잡힌다.
이러한 내용을 import문으로 알 수 있다.
모듈
역할의 경계가 뚜렷하게 정의되어 있고,
기술 또한 격리되어 있고,
각 모듈별 테스트가 가능하도록 코드가 짜져있어야 한다.
그래야 모듈의 분리도가 좋다는 내용이다.
쉽게 예시를 들면,
비즈니스로직에는 라이브러리가 없어야 좋다.
라이브러리만 따로 모듈로 빼놓으면, 라이브러리 변경시 해당 내용만 수정하면 되니깐. (이러한 내용을 import문으로 알아볼 수 있음.)
위 사진에서 보면,
Member의 비즈니스로직을 담당하는 MemberService 클래스에서
메일을 보내기 위해 필요한 라이브러리나
S3에 데이터를 저장하기 위해 필요한 라이브러리를 사용하지 않는다.
해당 라이브러리를 사용하는 클래스를,
각각 mailService, storageService 클래스로 만들었고,
MemberService 클래스로 DI 받고있다.
내가 이해한게 맞다면, 모듈을 위와 같은 느낌으로? 관리해라! 라는 이야기같다.
이렇게 지속가능한 코드에 대해 세가지를 말씀해 주신다.
그와 덧붙여
지속가능한 소프트웨어는,
계속해서 SW를 통제해야 하기 때문에,
지속 가능한 코드를 기반으로 실행된다.
지속 가능한 코드는,
확장에 용이하고, 서로 잘 분리되어야 한다.
분리되어진 클래스들은 적절하게 패키징되어야 한다.
이러한 방식으로 단순히 토스 페이먼츠만의 SW를 만드는 것이 아니라,
산업을 이끌어갈 진화하는 SW를 만드려고 한다.
라는 내용에 대해 이야기해 주신다.
지속 가능한 코드가 지속 가능한 SW를 만들고, 해당 SW는 점점 진화해서 산업을 이끈다.
나는 이 말이 너무 와닿았고, 멋있었다.
리팩토링
내가 해당 영상을 보고, 가장 부족하다고 느낀 부분이 패키징 부분이었다.
그래서 해당 부분을 리팩토링 했다.
처음엔,
사진에서 보다시피 그냥 개념이 아닌 역할별로 나누어져있다.
심지어,
인증의 역할과 관련된 패키지는 mail과 관련 없음에도 불구하고
auth 패키지 안에는 mail이라는 패키지도 존재한다.
나는
domain 패키지에서 프로젝트와 DB 구조에서 핵심 역할을 하는 domian entitiy를 기준으로 하위 패키지를 구성하고,
global 패키지에서 프로젝트에서 전적으로 사용할 수 있는 클래스 들로 구성하려고 했다.
위와 같이 고쳤다.
천릿길도 한걸음부터라고, 무언가 더 깔끔해지고 보기 좋아졌다는 생각이 든다.
당장 MemberService의 import문만 봐도,
훨씬 더 가독성이 좋아진 모습이다.
