feature와 core 모듈을 추가하여 멀티 모듈 구조를 구성합니다. #2
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR introduces a multi-module architecture by adding feature and core modules to organize the codebase into a more maintainable structure. The changes establish a clear separation of concerns with feature modules for UI functionality and core modules for shared business logic and infrastructure.
- Adds feature modules (home, login) for UI-specific functionality
- Creates core modules (domain, data, network, preference, ui, designsystem) for shared components
- Configures module dependencies following clean architecture principles
Reviewed Changes
Copilot reviewed 45 out of 60 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| settings.gradle.kts | Registers all new modules in the project build configuration |
| feature/home/build.gradle.kts | Configures home feature module with dependencies on core modules |
| feature/login/build.gradle.kts | Configures login feature module with dependencies on core modules |
| core/ui/build.gradle.kts | Sets up UI core module with dependency on designsystem |
| core/data/build.gradle.kts | Configures data module with dependencies on domain, network, and preference |
| core/domain/build.gradle.kts | Sets up domain module as a pure Kotlin library |
| core/network/build.gradle.kts | Configures network module as Android library |
| core/preference/build.gradle.kts | Sets up preference module as Android library |
| core/designsystem/build.gradle.kts | Configures designsystem module as Android library |
eshc123
force-pushed
the
feature/build-logic-application
branch
from
eff1485 to
8c365a2
Compare
eshc123
force-pushed
the
feature/multi-module
branch
from
08fd1e7 to
5506d3d
Compare
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| testImplementation(libs.junit) | ||
| androidTestImplementation(libs.androidx.test.ext.junit) | ||
| androidTestImplementation(libs.espresso.core) | ||
| } |
There was a problem hiding this comment.
{
"lgtm": false,
"review_comment": "# 코드 리뷰\n\n## 잠재적인 문제\n1. compileSdk가 36으로 설정됨:\n * Android SDK의 최신 버전이 아닐 수 있습니다. 2023년 현재 Android 14(UDK 34) 이상을 사용하는 것이 가장 좋습니다. SDK 업데이트 여부를 확인하세요.\n\n2. minSdk 버전:\n * 최소 SDK 버전인 26은 여전히 사용 가능하지만, 최신 표준에서는 30 또는 31 이상을 사용하는 것이 권장됩니다. 앱의 사용자층을 고려할 때 이 점을 재검토할 필요가 있습니다.\n\n3. isMinifyEnabled 설정:\n * release 빌드 타입에서 isMinifyEnabled가 false로 설정되어 있는 경우, 코드 난독화가 이루어지지 않아서 보안 취약점이 발생할 수 있습니다. 가능하면 true로 설정하는 것이 좋습니다.\n\n4. Proguard 및 Consumer Proguard 파일:\n * `consumerProguardFiles("
| val appContext = InstrumentationRegistry.getInstrumentation().targetContext | ||
| assertEquals("com.plottwist.feature.login.test", appContext.packageName) | ||
| } | ||
| } |
There was a problem hiding this comment.
이 코드 패치에서 몇 가지 잠재적인 문제 및 개선 사항이 발견되었습니다:
-
패키지 이름 확인: 테스트에서 사용된 패키지 이름
com.plottwist.feature.login.test가 앱의 실제 패키지 이름과 일치하는지 확인하십시오. 일반적으로 테스트 패키지는build.gradle또는 프로젝트 구조에서 명확하게 정의되어 있어야 합니다. 이러한 불일치는 테스트의 정확성에 영향을 줄 수 있습니다. -
주석 및 문서화 개선: 주석이 있지만, 테스트에 대한 설명이 더 명확하면 좋겠습니다. 예를 들어, 어떤 기능을 테스트하는지, 예상 결과는 무엇인지 추가 설명이 도움이 될 수 있습니다.
-
의존성 관리: androidx.test.ext.junit 패키지와 AndroidJUnit4의 추가 버전 관리를 고려해야 합니다. 종속성 충돌이 발생할 수 있으므로 Gradle을 검사하여 최신 안정 버전을 사용하는 것이 좋습니다.
-
에러 처리: 현재 테스트는 기본적인 성공/실패 시나리오만 처리하고 있습니다. 더 복잡한 기능이나 예외 상황을 계획하고 있는 경우, 실패 사례를 다루는 추가 테스트를 구현해야 합니다.
-
JUnit 버전: JUnit4를 사용하는 대신 JUnit5로의 전환을 고려하는 것이 좋습니다. JUnit5는 더 많은 기능과 유연성을 제공하며, 지속적인 발전이 이루어지고 있습니다.
위 사항들을 반영하여 코드를 개선하면 안정성과 유지 관리성에서 큰 이점을 가져올 것입니다.
| <?xml version="1.0" encoding="utf-8"?> | ||
| <manifest xmlns:android="http://schemas.android.com/apk/res/android"> | ||
|
|
||
| </manifest> |
There was a problem hiding this comment.
코드 패치에 XML 매니페스트 파일이 포함되어 있지만, 해당 파일의 구조가 불완전합니다. 매니페스트 태그 안에는 최소한 패키지 이름, 애플리케이션 클래스, 권한(필요한 경우) 등의 정보가 포함되어야 합니다. 또한, <application> 태그와 다른 필요한 구성요소들이 빠져 있습니다. XML 파일이 제대로 구성되지 않으면 애플리케이션이 실행되지 않거나 예기치 않은 오류가 발생할 수 있습니다. 추가적으로, XML 파일의 인코딩 및 버전 정보는 올바르게 설정되어 있지만, 전체적인 완전성을 위해 내용을 더 추가해야 합니다.
| fun addition_isCorrect() { | ||
| assertEquals(4, 2 + 2) | ||
| } | ||
| } |
There was a problem hiding this comment.
코드 패치에 간단한 유닛 테스트가 포함되어 있지만, 몇 가지 주의해야 할 점이 있습니다.
-
테스트의 유용성: 현재 작성된 테스트는 매우 기본적이고 단순합니다. 실제 애플리케이션의 다채로운 기능을 테스트하기 위해 더 다양한 테스트 케이스를 추가하는 것이 좋습니다.
-
테스트 이름: test 메소드 이름이 'addition_isCorrect'로 설정되어 있지만, 이 메소드는 특정 기능 외에도 다양한 연산이나 모듈을 테스트하는 메소드로 설계될 수 있습니다. 더 명확한 이름을 지어 테스트의 목적을 잘 표현해야 합니다.
-
패키지 구조: 테스트 클래스가 본래 패키지인 'com.plottwist.feature.login' 내에 잘 위치해 있는지 검토해야 합니다. 이 패키지가 해당 테스트와 관련이 없으면 유지 보수에 어려움이 생길 수 있습니다.
-
테스트 환경: 만약 해당 테스트가 다른 동작이나 리소스에 의존하는 경우 Mocking 또는 Stubbing을 사용하여 독립적으로 테스트를 수행하도록 고려해야 합니다.
이러한 점을 보완하면 코드의 품질과 안정성을 높일 수 있습니다.
|
|
||
| rootProject.name = "tuk" | ||
| include(":app") | ||
| include(":core:network") |
There was a problem hiding this comment.
코드 패치는 새로운 모듈 :feature:login을 포함하는 것으로 보입니다. 하지만, 다음과 같은 우려가 있습니다:
-
의존성 문제: 새로운 모듈이 다른 모듈들과의 의존성 충돌을 일으킬 수 있으므로, 전체 프로젝트에서 의존성 그래프를 점검해야 합니다.
-
모듈 통합 테스트:
:feature:login모듈이 다른 기능과 잘 통합되는지 확인할 필요가 있습니다. 이를 위해 통합 테스트를 추가하여 코드가 예상대로 작동하는지 검증해야 합니다. -
코드 스타일 및 일관성: 전체 코드베이스와의 일관성을 유지하려면 코드 스타일 가이드에 따라 파일 구조 및 명명 규칙을 점검하세요.
이러한 사항들을 해결한 후에 merge를 고려하는 것이 좋습니다.
작업
참고사항
flowchart TB %% ───────────── Core ───────────── subgraph Core direction LR coreRoot[ ]:::anchor designsystem["core:designsystem"] ui["core:ui"] domain["core:domain"] data["core:data"] network["core:network"] prefs["core:preference"] ui --> designsystem data --> domain data --> network data --> prefs end %% ─────────── Feature ──────────── subgraph Feature direction LR featureRoot[ ]:::anchor home["feature:home"] login["feature:login"] home --> ui home --> designsystem home --> domain login --> ui login --> designsystem login --> domain end %% ──────────── App ─────────────── app["app"] %% ---- 앱 의존성 (두 줄) ---- app --> featureRoot app --> coreRoot %% 스타일: 집합 노드는 보이지 않게 classDef anchor width:0px,height:0px,stroke:none,fill:none;