Code smell — dastur kodida chuqurroq dizayn yoki maintainability muammosi bo‘lishi mumkinligini ko‘rsatadigan belgi. U compile xatosi yoki isbotlangan bug emas. Uzun method, takroriy kod, haddan tashqari katta class yoki bir-biriga kuchli bog‘langan modullar kod smell hisoblanishi mumkin. Smell kontekst bilan baholanadi; har aniqlangan belgi avtomatik refactoring talab qilmaydi.
Keng tarqalgan belgilar
Long method ko‘p darajadagi abstraction va turli mas’uliyatni bitta joyga jamlaydi. Large class ko‘p sabab bilan o‘zgaradi. Duplicate code bir qoida bir nechta nusxada saqlanishiga olib keladi. Long parameter list function contractini tushunishni qiyinlashtiradi va birga yuradigan qiymatlar alohida type bo‘lishi mumkinligini ko‘rsatadi.
Feature envy method o‘z classidan ko‘ra boshqa obyekt fieldlariga ko‘proq murojaat qilganda yuz beradi. Shotgun surgery bitta biznes o‘zgarishi ko‘p faylga mayda edit talab qilishidir. Divergent change esa bitta modul turli mustaqil sabablar bilan tez-tez o‘zgarishini bildiradi. Bu belgilar responsibility chegarasi noto‘g‘ri bo‘lishi mumkinligini ko‘rsatadi.
Aniqlash
Code review o‘qish va o‘zgartirish qiyinligini kontekstda ko‘radi. Static analyzer complexity, method uzunligi, duplication va dependency cycle’ni o‘lchaydi. Threshold universal emas: generated parser bilan qo‘lda yozilgan domain service bir xil mezonda baholanmaydi.
Version control tarixi change couplingni ko‘rsatadi. Doim birga o‘zgaradigan fayllar mantiqan bir modulga yaqin bo‘lishi yoki yashirin contractga ega bo‘lishi mumkin. Incident va defect ma’lum smell atrofida takrorlansa refactoring ustuvorligi oshadi.
Refactoring qarori
Smell topilganda avval qaysi o‘zgarishni qiyinlashtirayotgani tushuniladi. Extract Method uzun blokni nomlangan operationga ajratishi, Move Method feature envy’ni kamaytirishi, Introduce Parameter Object bog‘liq parametrlarni typega birlashtirishi mumkin. Refactoring observable behaviorni o‘zgartirmasligi va test bilan himoyalanishi kerak.
Har smellni yo‘qotish yomon natija berishi mumkin. Juda ko‘p kichik method control flow’ni tarqatadi, premature abstraction esa hali o‘xshamagan kodni majburan birlashtiradi. Ikki nusxa ba’zan tasodifiy o‘xshashlik bo‘lib, keyin turli yo‘nalishda rivojlanadi. Rule of three kontekst yig‘ilguncha kutishni tavsiya qilishi mumkin.
Texnik qarz bilan aloqasi
Code smell texnik qarzning ko‘rinadigan alomati bo‘lishi mumkin, lekin qarz biznes tanlovi va kelajak xarajati bilan bog‘liq kengroq tushuncha. Smell inventory’sini sanashning o‘zi qiymat bermaydi. Change lead time, defect va developer tushunish vaqti bilan bog‘langan joylar avval tuzatiladi.
Refactoring kichik commitlarda, feature o‘zgarishidan ajratib bajarilsa review osonlashadi. Formatter va rename kabi mexanik o‘zgarish semantik editni yashirmaydi. Performance-sensitive kod optimallashtirish sabab g‘ayrioddiy ko‘rinsa benchmark va izoh uning niyatini saqlaydi.
Test kodidagi smell
Testlar ham maintainability muammosiga ega bo‘ladi. Bir test juda ko‘p behaviorni tekshirsa failure sababi noaniq, haddan tashqari mock esa real integration contractini yashiradi. Sleep bilan timing kutish flaky test yaratadi; observable condition va timeout ishlatiladi. Har test katta fixture nusxalasa builder yoki factory kerak bo‘lishi mumkin, ammo universal factory muhim qiymatlarni yashirmaydi. Production private methodini test qilish uchun public qilish encapsulationni buzadi. Test smell tuzatilganda assertion kuchi saqlanadi; shunchaki flaky testni o‘chirib qo‘yish signalni yo‘qotadi.
Smell uchun suppression qo‘yilsa, uning sababi va amal qiladigan kod doirasi tor saqlanadi.
Bog‘liq tushunchalar
Refactoring, Technical debt, Extract method, Cyclomatic complexity, Duplicate code, Cohesion, Coupling