모듈화를 위한 전투
앞선 글을 작성하고 프로젝트를 진행하는 동안 Compose가 디자인 개발에 참여하여 어느 정도 이해하면서 개발할 수 있었습니다. Compose로 프로토타입을 만든 후 Pluu, Skydoves, TaeHwan의 Github에 가서 기능을 추가할 여러 Android 프로젝트를 살펴봤습니다. 지금까지 수행한 프로젝트 또 다른 방법아키텍처 설계에 도움을 준 것 같습니다.
Github 프로젝트와 내 프로젝트의 차이점
Data, Domain, Presentation을 하나의 모듈에 넣고 하나의 패키지로 분리했습니다. 그러나 Github에 업로드된 프로젝트는 날짜, 도메인 및 현재와 관련하여 자세히 설명되어 있습니다. 모듈화그래서 헤어졌다.
고민 끝에 Android 권장 아키텍처를 엔터프라이즈 프로젝트에 적용하기 위해 뷰, 도메인 및 데이터 패키지를 생성하고 삽입했습니다. 모듈화를 했다면 확실히 유지보수가 쉬웠을 것이다.
안드로이드 앱 모듈화 가이드 | 안드로이드 개발자 | 안드로이드 개발자
그래서 깃허브 프로젝트를 보고 모듈화하려고 했더니 build.gradle도 내 것과 달랐다.
저는 groovy-DSL을 사용했는데 github 프로젝트는 Kotlin-DSL을 사용하는 것 같습니다.
그래서 모듈화 전에 코틀린 DSL그동안 연구하고 개발한 버그들을 정리하려고 합니다.
코틀린 DSL이란?
DSL은 Domain-Specific Language의 약자로 특정 도메인(저는 Android입니다)에 대한 작업 및 작업을 간결하게 설명할 수 있는 언어입니다.
장점과 단점?
장점
1. 가독성 향상
build.gradle을 보면 여기까지는 길고 복잡해서 이해하기 어려웠는데 간결해지면 여러 모듈이 포함된 프로젝트처리할 때 유용
2. 더 나은 IDE 지원
코드 완성, 오류 강조 표시 및 리팩토링 도구(변수 리팩터링 가능)를 지원합니다. 따라서 오류 가능성을 줄일 수 있습니다.
3. 모듈화 개선
종속성을 쉽게 관리하고 종속성의 중복 선언을 방지합니다.
불리
1. 클린 빌드는 Groovy DSL보다 느립니다.
2. Java8 이상에서 작동
다중 모듈 프로젝트에서 가독성과 유지 관리 용이성 때문에 Groovy DSL에서 Kotlin DSL로 전환하기로 결정했습니다.
buildSrc란 무엇입니까?
buildSrc는 빌드 로직을 작성할 수 있는 특수 디렉토리입니다. (Gradle이 자동으로 루트 프로젝트의 일부로 인식하기 때문입니다.)
buildSrc의 코드는 빌드 프로세스의 일부로 컴파일 및 실행되므로 모듈에서 재사용할 수 있는 다른 빌드 논리를 정의하는 데 사용할 수 있습니다.
이를 통해 읽기 쉬운 코드를 프로젝트 전체에서 공유할 수 있으므로 유지 관리가 용이해집니다.
build.gradle.kts
plugins {
'kotlin-dsl' // Too many characters in character literal 에러 발생
"kotlin-dsl" // Unresolved reference:buildSrc의 파일 인식 못하는 에러 발생
`kotlin-dsl` // 에러 발생 하지 않음
}처음이라 전개를 몰라서 자잘한 실수를 많이 한 것 같아요.
졸업 증서
kotlin-dsl을 사용하면 Android 프로젝트(특히 여러 모듈이 포함된 프로젝트)를 쉽게 유지 관리할 수 있습니다.
이를 바탕으로 다음 포스팅은 앱 모듈화 이후에 올릴 예정입니다.