refactor: 프로젝트 Modularization 적용 (2)

[s9hn]

📌𝘐𝘴𝘴𝘶𝘦𝘴

• closed refactor: 프로젝트 Modularization 적용 (2) #622

📎𝘞𝘰𝘳𝘬 𝘋𝘦𝘴𝘤𝘳𝘪𝘱𝘵𝘪𝘰𝘯

• build-logic 모듈을 생성했습니다.
  • build-logic, precompiled script 방식으로 convention plugin을 구현했습니다.

📷𝘚𝘤𝘳𝘦𝘦𝘯𝘴𝘩𝘰𝘵

💬𝘛𝘰 𝘙𝘦𝘷𝘪𝘦𝘸𝘦𝘳𝘴

플러그인 구현은 2번째인데, 하다보니 욕심이 생겨서 이것저것 챙기려다보니 오래걸렸습니다.
관련해서 포스팅도 준비중인데, 이것 또한 시간이 좀 걸리겠습니다.

현재 방식처럼, Precompiled Script Plugins 방식을 구현하게 되면 dependencies 스코프(블럭) 내에서 수신객체로 'DependencyHandlerScope'를 수신하게 됩니다. 그러나 이 객체론 상위 타입의 'Project'에 접근할 수 없으므로 libs(toml)에 접근할 수 없습니다. 그렇게 되면 직접 버전을 명시하여 사용해야 합니다.
따라서 이를 해결하기 위해 'Project'를 수신할 수 있는 확장함수 'websosoDependencies'를 만들어 해결했습니다.

추가로 고민인 점은,
기존에 제공되는 'dependencies 스코프(블럭)'을 사용할 수 없기에 'websosoDependencies(Custom DSL)'을 만들어 사용합니다.
이 과정중에 어쩔 수 없이 WebsosoDependencyScope 객체를 생성하게 되는데, 본 객체가 어떤 중요한 상태값을 관리하진 않지만
websosoDependencies DSL 함수가 호출될 때마다 객체가 생성되는게 조금 마음이 불편하네요.. (그렇게 많이 생성되진 않겠지만)
이를 다른 방법으로 해결하기 위해선, 지금처럼 Script 형식이 아닌 코틀린 함수로 구현해 주입받는 방법도 있습니다.

한줄요약:
함수를 통한 플러그인 주입 vs 현재 방식
무엇이 좋을까요..?

빌드 관련 업무이니 꼼꼼하게 봐주세요!

[junseo511]

저같은 경우에는 build-logic을 구성할 때

1. Plugin를 반환하는 클래스를 만들고 apply를 오버라이딩한 다음
2. build-logic 내부에 있는 그래들에서 register를 해주었어요

이렇게 했을 때의 장점은 플러그인을 관리할 때의 응집도를 높일 수 있고,
별도로 인스턴스를 생성하고 넣어주는 것이 아닌 Plugin 인스턴스에 직접 접근해서 적용할 수 있습니다.

단점으로는 초기 컴파일시 플러그인을 만들어주는 과정이 필요하고,
id에서 수정 사항이 생겼을 때 id값을 바꿔주기 조금 번거롭다는 점...?! 이 있겠네요
단, id는 자주 바뀌는 값이 아니니 괜찮을 듯도 싶구요

Precompiled Script Plugins 라는 네이밍으로 미루어 보았을 때 스크립트 형식으로 미리 컴파일이 되는 것 같은데
현재 WebsosoDependencyScope가 생성될 때 꽤 많은 메서드를 담고 있는 것으로 보입니다!
스코프를 강제적으로 사용하게 되는 의존에 대한 문제점도 있을 것 같구요!

이렇게 했을 때의 산군이 생각하는 장단점은 무엇이고 왜 이 방법을 채택하셨는지 궁금합니다!

[m6z1]

저는 객체로 만들어도 괜찮다고 생각합니다!
응집도 있게 모여있으니 좋네요 👍
공백 코멘트 확인해주시면 저도 알려주세요 궁금하네요
고생하셨습니다!

[s9hn]

준서가 언급해준 Convention Plugin 구현 방식은 본 영상에서 언급되는 Binary Plugin 구현 방식과도 같아요.
영상에서 언급한대로 해당 방법은 반복적으로 클래스를 작성해주어야하는 번거로움이 있어요.
반대로 기본적으로 precompiled script plugin 구현 방식은 Binary Script Plugin 방식의 장점을 흡수해요.
오히려 반복적으로 클래스를 수정하지 않고 스크립트만 작성해도 내부적으로 알아서 Plugin을 사용하죠.
그렇기에 간단한 스크립트 형식을 이용하는 precompiled script plugin을 사용하기로 했어요.
이 방법은 Gradle 공식문서에서도 공식적으로 언급하고 있는 Convention Plugin 구현 방식이에요.

빌드 업무와 관련된 해당 모듈은 수정사항이 빈번히 발생하지 않아요. 따라서 리소스 비용에 신경쓰기보단 모두가 간단하게 사용할 수 있는
범용적인 스크립트 만들기에 집중했어요.
WebsosoDependencies 스코프도 그러한 이유로 설계했어요. 기존 스크립트 문법을 사용할 수 있도록 말이죠.

현재 구현 방식의 장단점에 대한 제 생각은 'To Reviewer'에 작성했어요.
이해하기 쉽게 얘기하자면,
'기존에 스크립트를 작성하는 것처럼 작성하고 싶다'라는 니즈를 함수로 구현할지 스크립트 파일로 구현할지에 대한 차이입니다!

[junseo511]

앱 규모가 크지 않으니까 팀 내부 인원이 편하게 사용하기 위해서는 현재처럼 객체 생성 방식도 좋을 것 같습니다 👍