Android App architecture: About modularization

안드로이드 App architecture: About modularization을 알아보겠습니다.

출처:
https://developer.android.com/topic/modularization

많은 Gradle(그래들) modules(모듈)로 이루어진 프로젝트를 multi-module(멀티 모듈) project(프로젝트)라고 합니다. 이 지침에서는 multi-module android 앱을 위한 최고의 사례와 추천 patterns(패턴)을 포함합니다.

• 메모:

이 문서는 당신이 recommended app architecture에 익숙하다고 가정하고 서술합니다.

⊙ The growing codebase problem: 커지는 코드의 문제;

계속해서 커지는 코드는 확장성, 가독성 그리고 전체의 코드 품질이 시간이 지남에 따라 보통 나빠집니다. 이것은 관리자가 쉽게 관리할 수 있는 구조를 사용하지 않은 채 코드의 증가가 일어나서 그렇습니다. Modularization(모듈화)는 코드를 구조화하여 유지 보수가 쉽게 만들고 이전에 언급한 문제들을 피하는 데 도움을 줍니다.

⊙ What is modularization?: 모듈화는 무엇인가?;

Modularization은 느슨하게 연결된 코드 모음이고, 자신이 부분을 가지고 있습니다. 각각의 부분은 module입니다. 각각의 모듈은 독립적이며, 명확한 목적을 제시합니다. 작고 간단한 문제로 나누며 부수적인 문제를 풀 수 있게 해줍니다. 디자인의 복잡성을 줄이고, 큰 시스템에 유지 보수를 쉽게 만들어줍니다.

⊙ Benefits of modularization: 모듈화의 이점;

비록 유지 보수와 전체적인 코드 품질에 중점을 두지만, Modularization의 이점은 많습니다. 아래의 표에 이점을 요약했습니다.

• Reusability: 재사용성;

Modularization은 코드 공유의 기회를 주고, 많은 앱들을 같은 기초로 만들 게 합니다. Modules는 효과적인 빌딩 블록입니다. 앱은 그들 features(기능)의 합이어야 하고, features는 각각의 modules의 집합입니다. 특정한 module의 기능은 특정한 앱에서 가능하거나 불가능할 수 있습니다. 예를 들어, :feature:news는 전체 버전과 wear(웨어) 앱에서는 가능하지만, demo(데모) 버전의 앱에는 포함되지 않습니다.

• Strict visibility control: 강력한 가시성 조절;

Modules는 어떠한 것을 다른 코드 부분에 노출할지 쉽게 조정할 수 있습니다. 모든 부분에 사용 가능하지만, 특히 public(퍼블릭) interface를 internal이나 private를 사용하여 외부에서 사용하지 못하도록 막을 수 있습니다.

• Customizable delivery: 사용자 맞춤 전달;

Play Feature Delivery를 사용하여 진보된 앱 bundles(번들)을 사용할 수 있게 하려면, 당신은 특정한 앱의 features를 조건적으로 제공해 주거나 요청이 있을 때 제공해 주면 됩니다.

위에 있는 이점들은 오직 코드를 modularized 할 때 얻을 수 있습니다. 아래에 소개할 이점들은 다른 기술로도 얻을 수 있지만, modularization으로 더욱 이점을 극대화할 수 있습니다.

• Scalability: 확장성;

강력하게 결합된 코드는 하나의 변화로도 변화의 폭포를 만들어 상관없는 코드에도 영향을 주게 됩니다. 잘 modularized된 프로젝트는 관심사 분리 원칙을 준수하여 결합도가 낮습니다. 이것은 코드 수정자에게 자율성을 줍니다.

• Ownership: 주인의식;

추가적으로 자율성을 부여하듯이, modules는 책임성을 강화시킵니다. Module은 유지 보수를 해야 하는 소유자를 지정받을 수 있습니다. 소유자는 버그를 고치고, 테스트를 추가하고, 변화를 관찰합니다.

• Encapsulation: 캡슐화;

Encapsulation 뜻은 최대한 다른 module의 코드는 조금만 알아야 한다는 뜻입니다. 고립된 코드는 읽고 이해하기 쉽습니다.

• Testability: 테스트 가능성;

Testability 특성은 얼마나 쉽게 당신의 코드를 테스트하느냐입니다. 테스트 가능한 요소 코드는 고립된 상태에서 쉽게 테스트할 수 있습니다.

• Build time: 빌드 시간;

점진적 build(빌드), build cache(캐시) 또는 병렬 build 등의 몇몇의 Gralde의 기능은 modularity에 영향을 주어, build 성능을 향상시킵니다.

⊙ Common pitfalls: 일반적인 함정;

당신의 코드의 세분화 가능성은 어떤 범위의 modules을 사용하는지에 따라 결정됩니다. 더 잘게 만든 코드는 작은 단위의  modules가 만들어집니다. 코드를 modularized 구성을 할 때, 당신은 어느 정도로 세분화할지 정해야 합니다. 이것을 하려면, 코드의 크기와 복잡성을 계산해야 합니다. 너무 잘게 세분화한 것은 업무의 과중화를 초래하고, 크게 나누게 되면, modularization의 장점이 줄어듭니다.

일반적인 함정으로는 아래와 같습니다.

• Too fine-grained: 너무 잘게 분할;

Module을 만들기 위해 매번 불필요한 코드가 추가되고, build의 복잡성이 증가하게 됩니다. 복잡한 build 설정은 modules 간의 설정 일관성을 유지하기 어렵게 됩니다. 많은 불필요한 코드들은 코드의 과중화를 불러오고 이것은 유지 보수의 어려움을 발생시킵니다. 만약, 과중화가 확장성 향상에 영향을 준다면, 몇몇의 modules를 합치는 것을 고려해 보세요.

• Too coarse-grained: 너무 크게 분할;

반대로, 당신의 modules이 너무 커져서 탑처럼 되어 버리면, modularity의 이점을 잃습니다. 예를 들어, 작은 프로젝트의 경우 data layer를 하나의 module로 두는 것은 괜찮습니다. 하지만, 앱이 점차 커지면, repositories와 data sources를 독립적인 modules로 나누는 것이 필요합니다.

• Too complex: 너무 복잡함;

modularize가 항상 당신의 프로젝트에 필요한 것은 아닙니다. modularize를 결정짓는 요소는 코드의 양입니다. 만약 당신의 프로젝트가 특정한 양을 넘기지 않을 것이라고 생각한다면, 확장성과 build time 이점은 적용되지 않습니다.

⊙ Is modularization the right technique for me?: Modularization이 나에게 적합한 기술인가?;

만약 당신이 재사용성, 강력한 가시성 조절, Play Feature Delivery가 필요하다면, modularization은 필수입니다. 만약 아니더라도, 확장성과 소유권, 캡슐화, build times가 필요하다면, modularization은 고려되기 충분합니다.

끝.

카테고리: Android