Code Smell mobil ishlab chiqishda: mohiyati, turlari va tuzatish tamoyillari

Code Smell nima

Code Smell (kod hidi) — manba kodidagi chuqur muammolarni yuqori ehtimollik bilan ko‘rsatadigan simptomlar uchun metaforadir. Terminning o‘zi rasmiy ta‘rifga ega emas — bu dasturchilar tajribasiga asoslangan evristikadir. Martin Fauler va Kent Bek 1999 yilda «Refactoring” kitobida birinchi marta 22 hidni tizimlashtirdilar va ularning aksariyati o‘nlab yillar o‘tgach ham dolzarbligicha qolmoqda.

Code Smell va xato o‘rtasidagi farqni tushunish muhimdir. Hid xato emas: kod kompilyatsiya qilinadi, ishlaydi va to‘g‘ri natija beradi. Muammo shundaki, bunday kodni o‘qish, o‘zgartirish va sinovdan o‘tkazish qiyin. Vaqt o‘tishi bilan har bir o‘zgarish narxi oshadi va refaktoringning to‘g‘riligiga ishonch kamayadi. Statik tahlil vositalari (SonarQube, Detekt, SwiftLint) ko‘plab hidlarni avtomatik ravishda aniqlaydi.

Evristik xarakter Code Smell har bir uzun metodni bo‘lish va har bir katta sinfni refaktoring qilish kerak degani emas. Qarorni dasturchi qabul qiladi, kontekstni baholaydi: o‘zgarishlar chastotasi, modulning tanqidiyligi, rivojlanish rejalari. Tajribali muhandislar hidni intuitiv his qiladilar — kod «yoqimsiz hidlaydi”, garchi rasmiy ravishda barcha qoidalar bajarilgan bo‘lsa ham.

Code Smell ning asosiy turlari

Fauler 22 hidni bir necha toifaga ajratdi. Mobil ishlab chiqish uchun eng dolzarbi strukturaviy hidlar, ob’ektga yo‘naltirilgan dizayn hidlari va platforma cheklovlari bilan bog‘liq o‘ziga xos muammolardir. Har bir guruhni real amaliyotdan misollar bilan ko‘rib chiqamiz.

Strukturaviy hidlar

Long Method (uzun metod) — mobil ilovalarda eng keng tarqalgan hid. Ro‘yxatdan o‘tish formasi bo‘lgan ekran ko‘pincha 200+ qatordan iborat bitta setupUI metodini o‘z ichiga oladi, u barcha View-larni yaratadi, cheklovlarni sozlaydi, hodisalarga obuna bo‘ladi va xatolarni boshqaradi. Yechim: mantiqiy bloklar bo‘yicha metodlarga bo‘lish — configureEmailField, configurePasswordField, setupConstraints, bindViewModel.

Large Class (katta sinf) — ko‘rsatish, navigatsiya, biznes mantiqi va tarmoq aloqasi uchun javobgar bo‘lgan Activity yoki ViewController. Bunday sinf Single Responsibility prinsipini buzadi va o‘nlab maydon va metodlarni o‘z ichiga oladi. Android da bu ko‘pincha turli ekranlar mantiqini o‘z ichiga olgan 1000+ qatorli Fragment bo‘ladi. Yechim: presenter/ViewModel ajratish, tarmoq ishini repozitoryga, navigatsiyani koordinatorga o‘tkazish.

Duplicate Code (kod takrori) ‘— bir xil bloklarning ilovaning turli qismlarida nusxalanishi. Oddiy misol: katalogda va sevimlilarda mahsulot kartasini ko‘rsatadigan ikkita ekran. Agar ko‘rsatish mantiqi nusxalangan bo‘lsa, bir joydagi xatoni tuzatish boshqa joyda uni tuzatmaydi. Yechim: umumiy mantiqni qayta foydalanish mumkin bo‘lgan komponent yoki kengaytmaga chiqarish.

Ob’ektga yo‘naltirilgan dizayn hidlari

Feature Envy (boshqa sinfga hasad) — bir sinfning metodi boshqa sinfning ma’lumotlaridan intensiv foydalanadi. Android da bu ViewModel User modelining maydonlariga to‘g‘ridan-to‘g‘ri murojaat qilganda namoyon bo‘ladi. Signal: agar metodni ma’lumotlaridan foydalanadigan sinfga ko‘chirish mumkin bo‘lsa — ko‘chiring. Switch Statements (shart zanjirlari) — ob‘ekt turini tekshiradigan switch yoki if-else zanjiri. Buning o‘rniga polimorfizm yoki strategy pattern dan foydalanish kerak.

Data Class — faqat ma’lumot saqlaydigan, ammo xatti-harakatga ega bo‘lmagan sinf. Data class (Kotlin da) yoki struktura (Swift da) o‘z-o‘zidan hid emas. Muammo bu ma’lumotlar bilan ishlaydigan biznes mantiqi inkapsulyatsiya qilinish o‘rniga butun kod bazasiga tarqalganda yuzaga keladi. Refused Bequest — merosxo‘r ota-onaning metodlarining ko‘pchiligidan foydalanmaydi va ularni bo‘sh qoliplar bilan bekor qiladi. Noto‘g‘ri meros belgisi: merosni kompozitsiya bilan almashtiring.

Mobil ishlab chiqishdagi hidlar

God Activity / God Fragment — hamma narsani biladigan Activity yoki Fragment: hayotiy tsikl, ma’lumotlar, navigatsiya, ruxsatnomalar, DI haqida. Bu ilovaning saqlanishi eng qimmat sinfidir. Yechim: MVVM, MVI yoki Clean Architecture arxitektura naqshlari mas’uliyatni taqsimlaydi. Giant ViewController — iOS uchun analog, unda UIViewController ekranning barcha mantiqini o‘z ichiga oladi va ko‘pincha 500 qatordan oshadi.

Hardcoded Resources — satrlar, ranglar, o‘lchamlar, API URL lari to‘g‘ridan-to‘g‘ri kodga kiritilgan. Android da bu R resurs tizimidan foydalanishni buzadi, iOS da — NSLocalizedString va Asset Catalog ni. Tuzatish: barcha satrlarni strings.xml yoki Localizable.strings ga, URL larni konfiguratsiya fayliga, o‘lchamlarni dimens ga chiqaring. Leaking Context — Activity yoki ViewController ga havolani komponentning o‘zidan uzoqroq saqlash. Xotira oqishi va qulashlarga olib keladi. Yechim: zaif havolalar, Jetpack Lifecycle, RxSwift DisposeBag.

Code Smell ni qanday topish mumkin

Code review — hidlarni aniqlashning eng ishonchli usuli. Inson ko‘zi avtomatik analizatorlar o‘tkazib yuboradigan g‘ayritabiiy konstruksiyalarni sezadi. Kodni ko‘rib chiqish samaradorligi jamoa odatiy hidlarning tekshiruv ro‘yxatidan foydalansa oshadi. Bir seansda 200–400 qatordan ko‘p kodni tekshirish tavsiya etilmaydi — bu chegaradan keyin diqqat pasayadi va hidlar chetlab o‘ta boshlaydi.

Statik tahlil strukturaviy hidlarni qidirishni avtomatlashtiradi. Android uchun standart vositalar Detekt (Kotlin) va Android Lint, iOS uchun — SwiftLint va SonarQube dir. Bu vositalar uzun metodlarni, katta sinflarni, kod takrorini va boshqa ko‘plab muammolarni topadi. Qoidalarni loyihaga mos ravishda sozlash muhim — standart konfiguratsiyalar ko‘pincha juda qattiq yoki aksincha, tanqidiy hidlarni o‘tkazib yuboradi.

Kod metrikalari ob’ektiv mezonlarni beradi: Cyclomatic Complexity (chegara >10 diqqat talab qiladi), Lines of Code per Method (chegara >30), Depth of Inheritance (>3 — o‘ylash uchun sabab). CodeMetrics (Xcode) va Gradle Metrics Plugin kabi vositalar vaqt davomida metrikalarning o‘zgarish grafiklarini quradi. Agar metodning murakkabligi oxirgi kommitdan keyin 5 dan 15 ga oshgan bo‘lsa — bu refaktoring uchun signaldir.

// Misol: Cyclomatic murakkabligi = 7 bo‘lgan metod (chegara 5 dan yuqori)
fun processOrder(order: Order) {
    if (order.status == Status.NEW) { /* 10 qator */ }
    else if (order.status == Status.PAID) { /* 15 qator */ }
    else if (order.status == Status.SHIPPED) { /* 20 qator */ }
    else if (order.status == Status.DELIVERED) { /* 8 qator */ }
    else if (order.status == Status.CANCELLED) { /* 5 qator */ }
    else { throw IllegalStateException() }
}

// Tuzatish: switch o‘rniga polimorfizm
interface OrderHandler {
    fun handle(order: Order)
}

Avtomatik hid qidirish kodni ko‘rib chiqishni o‘rnini bosa olmaydi: statik analizatorlar faqat strukturaviy muammolarni topadi, ammo semantik hidlarni (Feature Envy, Inappropriate Intimacy) aniqlay olmaydi. Avtomatik vositalar va inson nazoratining kombinatsiyasi eng yaxshi natijani beradi. CI/CD quvurini shunday sozlangki, murakkablik yoki metod uzunligi chegaralari oshib ketganda qurilish muvaffaqiyatsiz bo‘lsin.

Code Smell ni qanday tuzatish kerak

Refaktoring — kod hidlarini bartaraf etishning asosiy usuli. Fauler o‘nlab refaktoring texnikalarini tavsiflaydi, ularning har biri ma’lum bir hidga qo‘llaniladi. Extract Method — uzun metodlar uchun, Extract Class — katta sinflar uchun, Move Method — Feature Envy uchun. Refaktoringni kichik qadamlar bilan bajarish, har bir o‘zgarishdan keyin kodning ishlashini saqlash muhimdir.

Refaktoringdan oldin testlar — majburiy shart. Agar kod birlik testlari bilan qoplanmagan bo‘lsa, refaktoring noma’lum natija bilan qayta yozishga aylanadi. Testlari bo‘lmagan legacy kod uchun Characterisation Tests dan foydalaning — joriy xatti-harakatni qayd etadigan testlar yozing, keyin refaktoring qiling. Testlash refaktoringdan keyin biznes mantiqi buzilmaganligiga ishonch beradi.

Bosqichmalik — mobil ishlab chiqishda hidlarni muvaffaqiyatli bartaraf etishning kalitidir. God Activity ni to‘liq qayta yozishga urinmang. Avval navigatsiya qatlamini, keyin ma’lumot qatlamini, so‘ngra ko‘rsatish mantiqini ajrating. Har bir qadamni kommit va testlar bilan kuzatib boring. Feature toggle dan foydalanib refaktoringni foydalanuvchilarning bir qismi uchun yoqing va muammo bo‘lsa qaytaring.

• Extract Method — uzun metodni tushunarli nomlar bilan bir necha qisqa metodlarga bo‘ling
• Extract Class — bog‘liq maydon va metodlar guruhini alohida sinfga ajrating
• Replace Conditional with Polymorphism — switch ni sinf ierarxiyasi bilan almashtiring
• Introduce Parameter Object — parametrlar guruhini ob‘ektga birlashtiring
• Replace Inheritance with Delegation — extends ni kompozitsiya bilan almashtiring

IDE vositalari ko‘plab refaktoring texnikalarini avtomatlashtiradi. Android Studio va IntelliJ IDEA o‘rnatilgan refaktoringlarni taklif qiladi: Extract Method, Extract Interface, Pull Members Up, Encapsulate Fields. Xcode (14 versiyasidan boshlab) Swift uchun refaktoring qo‘llab-quvvatlashini yaxshiladi. Avtomatik refaktoringlardan foydalanish kodni qo‘lda nusxalash bilan solishtirganda xato xavfini kamaytiradi.

Mobil ishlab chiqishda Code Smell

Mobil ishlab chiqish platforma cheklovlari bilan bog‘liq o‘ziga xos hidlarni qo‘shadi. Android da bu Context oqishi, yopilmagan Cursor, Lifecycle dan noto‘g‘ri foydalanish. iOS da — closure lar orqali retain cycle, Auto Layout bilan noto‘g‘ri ishlash, ulkan ViewController. Bu hidlar nafaqat saqlashni yomonlashtiradi, balki to‘g‘ridan-to‘g‘ri ilovaning ishlashi va barqarorligiga ta’sir qiladi.

Callback Hell — asinxron operatsiyalar bilan ishlaydigan kod uchun xarakterli hid. Ichma-ich callback lar (callback inside callback) kodni o‘qib bo‘lmaydigan va tuzatish qiyin qiladi. Yechim: korutinlar (Kotlin), async/await (Swift 5.5+), RxJava/RxSwift yoki Combine. Google I/O 2023 ma’lumotlariga ko‘ra, callback uslubidan korutinlarga o‘tgan loyihalar xatolar sonini 30% ga kamaytiradi va yangi funksiyalarni qo‘shishni tezlashtiradi.

Platform Coupling — biznes mantiqining platforma komponentlariga qattiq bog‘liqligi. Bunday mantiqni sinash emulyatorni ishga tushirishni talab qiladi, bu esa teskari aloqa siklini sekinlashtiradi. Tuzatish: Clean Architecture kodni Domain (platformaga bog‘liq bo‘lmagan toza Kotlin/Swift) va Data/UI (platforma bog‘liqliklari bilan) qatlamlariga ajratadi. Biznes mantiqi emulyatorsiz JVM da sinovdan o‘tkaziladi.