69 lines
4.3 KiB
Markdown
69 lines
4.3 KiB
Markdown
# گزارش تحلیل و پیشنهادات بهبود پروژه MonthlyPaymentApp
|
|
|
|
این گزارش شامل بررسی فنی ساختار پروژه و ارائه راهکارهای عملی برای بهبود کیفیت کد، نگهداری آسان‌تر و رعایت استانداردهای توسعه اندروید است.
|
|
|
|
## ۱. معماری و مدیریت وابستگی‌ها (DI)
|
|
|
|
### وضعیت فعلی
|
|
پروژه از DI دستی در کلاس `PaymentApplication` استفاده می‌کند. با رشد پروژه، مدیریت کارخانه‌های ViewModel (Factories) دشوار و مستعد خطا خواهد بود.
|
|
|
|
### پیشنهاد
|
|
استفاده از **Hilt (Dagger)** برای مدیریت وابستگی‌ها.
|
|
- **مزیت:** حذف کد‌های تکراری در `Application` و `Activity` و ساده‌سازی فرآیند تست واحد.
|
|
- **اقدام:** افزودن کتابخانه‌های Hilt به `build.gradle.kts` و استفاده از آنوتیشن‌های `@HiltAndroidApp` و `@HiltViewModel`.
|
|
|
|
---
|
|
|
|
## ۲. بازنگری در ViewModels (اصل Single Responsibility)
|
|
|
|
### وضعیت فعلی
|
|
فایل [PersonViewModel.kt](file:///E:/AndroidStudioProjects/MonthlyPaymentApp/app/src/main/java/com/oqba26/monthlypaymentapp/viewmodel/PersonViewModel.kt) با حدود ۱۰۰۰ خط کد، تبدیل به یک **God Object** شده است. این کلاس همزمان وظایف زیر را انجام می‌دهد:
|
|
- مدیریت احراز هویت (Auth)
|
|
- مدیریت لیست افراد و پرداخت‌ها
|
|
- ارسال پیامک‌های گروهی و تکی
|
|
- خروجی اکسل (Excel Export)
|
|
- جستجو در مخاطبین گوشی
|
|
|
|
### پیشنهاد
|
|
تقسیم `PersonViewModel` به کلاس‌های تخصصی‌تر:
|
|
- `AuthViewModel`: برای لاگین و ثبت‌نام.
|
|
- `PersonListViewModel`: برای نمایش و فیلتر لیست افراد.
|
|
- `SmsService` یا `SmsHelper`: برای منطق ارسال پیامک.
|
|
- `ExportManager`: برای تولید فایل‌های گزارش.
|
|
|
|
---
|
|
|
|
## ۳. جداسازی Context از لایه منطق
|
|
|
|
### وضعیت فعلی
|
|
در متدهایی مانند `processNextBulkSms(Context)` یا `exportYearlyReport(..., Context)` در ViewModel، از `Context` استفاده شده است.
|
|
- **مشکل:** این کار باعث نشت حافظه (Memory Leak) احتمالی می‌شود و تست‌نویسی (Unit Testing) را غیرممکن می‌کند.
|
|
|
|
### پیشنهاد
|
|
ViewModel نباید هیچ دانشی از `Context` داشته باشد.
|
|
- **راهکار:** برای مواردی مثل نمایش Toast یا شروع Intent، از یک `SharedFlow` برای ارسال **UI Events** به Activity استفاده کنید.
|
|
|
|
---
|
|
|
|
## ۴. بهبود لایه UI و Compose
|
|
|
|
### وضعیت فعلی
|
|
فایل‌هایی مثل `PersonScreen.kt` و `MainActivity.kt` بسیار طولانی هستند. کامپوننت‌های UI و منطق ناوبری در هم تنیده شده‌اند.
|
|
|
|
### پیشنهاد
|
|
- **شکستن کامپوننت‌ها:** بخش‌های مختلف صفحه (مانند SearchBar، PersonItem، Dialogs) را به فایل‌های جداگانه در پکیج `ui.components` منتقل کنید.
|
|
- **String Resources:** تمام رشته‌های فارسی هاردکد شده (مانند "آیا از حذف قطعی... مطمئن هستید؟") را به فایل `res/values/strings.xml` منتقل کنید.
|
|
|
|
---
|
|
|
|
## ۵. پیشنهادات فنی تکمیلی
|
|
|
|
- **نوسازی پکیج‌ها:** پکیج‌های `util` و `utils` را ادغام کنید تا ساختار پروژه تمیزتر شود.
|
|
- **Supabase Realtime:** با توجه به استفاده از Supabase، مطمئن شوید که از قابلیت Realtime برای همگام‌سازی آنی داده‌ها بین دستگاه‌های مختلف استفاده می‌کنید.
|
|
- **Room Migrations:** برای دیتابیس محلی، استراتژی مهاجرت (Migration) را مشخص کنید تا در آپدیت‌های بعدی، داده‌های کاربر پاک نشود.
|
|
|
|
---
|
|
|
|
> [!TIP]
|
|
> اگر مایل باشید، می‌توانیم با **راه‌اندازی Hilt** یا **انتقال متون به strings.xml** شروع کنیم که تغییراتی کم‌ریسک اما بسیار موثر در تمیزی پروژه هستند.
|