Makaron kodi nima

Makaron kodi (spaghetti code) — kodni tavsiflovchi metafora bo‘lib, uning strukturasi bir tarelka spagettini eslatadi: alohida iplar (mantiqiy bloklar) bir-biriga o‘ralashib, yopishib va ajralmas bo‘lib qolgan. Bunday kodda qatlamlar, modullar yoki komponentlarni ajratib bo‘lmaydi — hammasi bitta katta massada aralashib ketgan.

Yomon koddan farqli o‘laroq, makaron kodi fundamental arxitektura muammosidir. Hatto mukammal formatlangan kod yaxshi o‘zgaruvchi nomlari bilan spagetti kod bo‘lishi mumkin, agar uning arxitekturasi xaotik bo‘lsa. Muammo dasturning struktura darajasida, yozish uslubida emas.

IEEE ma‘lumotlariga ko‘ra (2022), yirik loyihalardagi barcha xatolarning taxminan 35% aynan kodning chalkash strukturasidan kelib chiqadi, dasturchining mantiqiy xatolaridan emas. Dasturchi xato qiladi, chunki vazifani noto‘g‘ri tushungani uchun emas, balki spagetti kodda bajarish oqimini kuzata olmagani uchun.

Boshqa anti-patternlardan asosiy farq

Agar yomon kod bitta funksiya yoki fayl miqyosida yomon kod bo‘lsa, makaron kodi butun dastur miqyosida yomon arxitekturadir. Ugra alohida yaxshi yozilgan funksiyalardan iborat bo‘lishi mumkin, ammo ularning o‘zaro ta‘siri xaotik va oldindan aytib bo‘lmaydigan.

Atama tarixi va goto davri

Atama “spaghetti code” 1970-yillarda goto operatorining tanqidi bilan birga paydo bo‘ldi. Dasturlashning ilk tillarida (BASIC, FORTRAN, COBOL) goto bajarish oqimini boshqarishning asosiy usuli edi. Dastur raqamlangan qatorlar ketma-ketligidan iborat bo‘lib, goto ularning istalganiga sakrashga imkon berar edi. Bu ochilishi mumkin bo‘lmagan sakrashlar to‘plamini yaratardi.

1968-yilda Edsger Dijkstra “Go To Statement Considered Harmful” nomli mashhur maqolasini nashr etdi va bu strukturali dasturlash davrining boshlanishini belgiladi. Dijkstra har qanday algoritmni goto holda faqat uchta konstruksiyadan foydalanib amalga oshirish mumkinligini isbotladi: ketma-ketlik, tarmoqlanish (if) va sikl (while). Bu zamonaviy dasturlashning asosiga aylandi.

Strukturali dasturlash muammoni to‘liq bartaraf etmadi. Makaron kodi yangi darajaga o‘tdi — jismoniy goto o‘rniga dasturchilar mantiqiy “goto” yarata boshladilar: global o‘zgaruvchilar, JavaScript-da callback hell, murakkab chaqiruv zanjirlari va komponentlar o‘rtasida yashirin bog‘liqliklar. Muammo qoldi, faqat shakli o‘zgardi.

Zamonaviy goto shakllari

Callback hell JavaScript-da, chuqur ichlashtirilgan Promise, xatolarni boshqarmasdan async/await, kim va qachon ishga tushirishi noma‘lum bo‘lgan hodisalar — bularning barchasi spagetti kodining zamonaviy turlari. Anti-pattern yashaydi va rivojlanadi, faqat endi goto operatoridan foydalanmaydi.

Loyihada spagetti kodining belgilari

Qatlamlarning yo‘qligi — birinchi va asosiy belgi. Makaron kodida biznes mantiqi, ma‘lumotlar bazasi bilan ishlash, HTML shablon va tarmoq aloqasi bitta faylda yoki hatto bitta metodda aralashib ketgan. Ma‘lumotlar bazasi so‘rovining o‘zgarishi UI ko‘rinishini buzishi mumkin, chunki bu qatlamlarning kodi ajratilmagan.

Global o‘zgaruvchilar va singletonlar — ikkinchi aniq belgi. Dastur holati global ob‘ektlarda saqlansa, bajarish oqimi oldindan aytib bo‘lmaydigan bo‘ladi. Istalgan funksiya global holatni o‘zgartirishi mumkin va bu qayerda va qachon sodir bo‘lganini kuzatish amaliy jihatdan imkonsiz.

God-klaslar va god-funksiyalar — uchinchi belgi. 2000+ qatordan iborat klass biznes mantig‘iga, ko‘rsatishga va ma‘lumotlar bilan ishlashga javobgar bo‘lsa — bu odatdagi spagetti kod. 10 parametr qabul qiladigan va 5 xil ishni bajaradigan funksiya ham shunday.

Testlar orqali diagnostika

Agar 15 mock-ob‘ekt yaratmasdan funksiya uchun unit-test yoza olmasangiz — bu makaron kodi. Agar bitta modulni test qilish butun dastur infratuzilmasini ishga tushirishni talab qilsa — bu makaron kodi. Test qilib bo‘lmaslik — chalkash arxitekturaning ob‘ektiv ko‘rsatkichidir.

Nega kodda ugra paydo bo‘ladi

Arxitekturaviy loyihalashning yo‘qligi — eng keng tarqalgan sabab. Jamoa plansiz kod yozishni boshlab, arxitekturani yo‘l davomida tanlaganda, natija muqarrar ravishda spagettiga aylanadi. Har bir yangi funksiya hozir qulay bo‘lgan joyga qo‘shiladi, mantiqqa ko‘ra joyi bo‘lgan joyga emas.

Evolution rivojlanish — ikkinchi sabab. Loyiha kichik skript sifatida boshlanadi, keyin funksiyalar bilan o‘sadi, keyin dasturga, so‘ngra monolitga aylanadi. Bunda arxitektura qayta ko‘rib chiqilmaydi. 100 qator kod uchun ishlagan narsa 100 000 qator uchun falokatga aylanadi.

SOLID prinsiplarining buzilishi — uchinchi sabab. Ayniqsa yagona mas‘uliyat (S) va bog‘liqliklarning inversiyasi (D) prinsiplarining buzilishi. Klass hamma narsaga javobgar bo‘lsa, bog‘liqliklar qattiq bo‘lsa va modullar mahkam bog‘langan bo‘lsa — makaron kodi paydo bo‘ladi.

Vaqt omili

Muddatlar va hotfix madaniyati — spagetti kodining katalizatorlari. Kecha kerak edi deganda, dasturchilar kodni arxitektura haqida o‘ylamay, birinchi kelgan joyga kiritadilar. O‘nta shunday hotfix — va dastur arxitekturasi buziladi.

Makaron kodining oqibatlari

Asosiy oqibat — kod bazasi ustidan nazoratning yo‘qolishi. Dasturchilar dasturning butunligicha qanday ishlashini tushunishni to‘xtatadilar. Bir joydagi o‘zgarish boshqa, go‘yo bog‘liq bo‘lmagan joyni buzadi. Har bir yamoq ikkita yangi xatolik yaratadi. Jamoa o‘zgarishlardan qo‘rqish holatiga tushadi.

Jamoaning samaradorligi eksponensial ravishda pasayadi. Microsoft Research (2023) tadqiqoti shuni ko‘rsatdiki, spagetti kodida yangi funksiyani qo‘shish vaqti kod bazasi hajmiga nisbatan kvadratik qonun bo‘yicha o‘sadi. Toza arxitektura uchun bu o‘sish chiziqli. Farq 50 000+ qator kodda kritik bo‘ladi.

Xavfsizlik — yana bir qurbon. Makaron kodida boshqarilmagan istisnoni, noto‘g‘ri kirish validatsiyasini yoki ma‘lumot sizib chiqishini o‘tkazib yuborish oson. Chalkash arxitekturali loyihada xavfsizlik auditi amaliy jihatdan imkonsiz — foydalanuvchi kiritgan ma‘lumotlarning ishlatilgan barcha joylarini topish real emas.

Jamoaga ta‘sir

Kadrlar almashinuvi spagetti kodli loyihalarda o‘rtachadan yuqori. Tajribali dasturchilar ugra bilan ishlashni istamay ketadilar. Yangi xodimlar kodni tushuna olmaydilar va birinchi oylarda ketadilar. Loyiha ekspertizasini yo‘qotadi, bu kod sifatini yanada yomonlashtiradi — ayovsiz doira.

Makaron kodini qanday refaktor qilish kerak

Birinchi — qatlamlarni ajratish bilan boshlang. Kodni uch darajaga bo‘ling: presentation (UI, kontrollerlar), business logic (xizmatlar, use cases) va data access (repository, DAO). Hatto qisman ajratish ham darhol strukturani yaxshilaydi va kodni test qilinadigan qiladi.

Ikkinchi — dependency injection joriy qiling. Bog‘liqliklarni to‘g‘ridan-to‘g‘ri yaratishni konstruktor yoki parametrlar orqali uzatish bilan almashtiring. Bu komponentlar o‘rtasidagi qattiq bog‘lanishlarni uzadi va har bir modulni alohida test qilish imkonini beradi.

Uchinchi — god-klaslar va god-funksiyalarni ajrating. Ularni kichik klasslar va yagona mas‘uliyatli metodlarga bo‘ling. Murakkab quyi tizimlarni soddalashtirish uchun Facade patternidan foydalaning. Esingizda bo‘lsin: 20 qatorlik klass 2000 qatorlik klassdan tushunarliroq.

// spaghetti — hamma narsa bitta metodda
function handleRequest(req, res) {
  const db = new Database("mysql://...");
  const user = db.query("SELECT * FROM users WHERE id =" + req.params.id);
  let html = "";
  html += "
" + user.name + "
";
  html += "
Balance: " + user.balance + "
";
  html += "";
  res.send(html);
}

// toza arxitektura — ajratilgan qatlamlar
class UserController {
  constructor(userService) {
    this.userService = userService;
  }

  async getUser(req, res) {
    const user = await this.userService.findById(req.params.id);
    res.json(new UserResponse(user));
  }
}

class UserService {
  constructor(userRepository) {
    this.userRepository = userRepository;
  }

  async findById(id) {
    return await this.userRepository.findById(id);
  }
}

Refaktoring strategiyasi: jarrohlik usuli

Butun kod bazasini birdaniga qayta yozishga urinmang — bu kafolatlangan muvaffaqiyatsizlik. Bitta modulni tanlang, uning uchun joriy xatti-harakatni qayd qiluvchi testlar (characterization tests) yozing va shundan keyingina refaktor qiling. Asta-sekin, modulma-modul, spagettini yechasiz.

Ugraning paydo bo‘lishining profilaktikasi

Arxitekturaviy rejalashtirish — profilaktikaning asosi. Rivojlanishni boshlashdan oldin arxitektura uslubini tasdiqlang: MVC, MVVM, Clean Architecture, VIPER yoki boshqa. Tanlovni asoslash bilan ADR (Architecture Decision Record) yozing. Code reviewda arxitekturaga rioya qilishni talab qiling.

Bog‘liqliklar inversiyasi prinsipi (DIP) — spagetti kodiga qarshi kurashning kuchli vositasi. Yuqori darajadagi modullar past darajadagi modullarga bog‘liq bo‘lmasligi kerak. Ikkalasi abstraksiyalarga bog‘liq bo‘lishi kerak. Dependency Injection — bu prinsipning amaliy amalga oshirilishi.

Testlar — eng yaxshi profilaktika. Agar koddan oldin testlar yozsangiz (TDD), muqarrar ravishda zaif bog‘langan komponentlarni loyihalaysiz. Test qilinadigan kod — yaxshi tuzilgan kod. Test qilib bo‘lmaydigan kod — deyarli har doim spagetti kod.

• Arxitektura koddan oldin: qatlam va bog‘liqlik sxemalarini tasdiqlang
• Dependency Injection asosiy bog‘lash patterni sifatida
• TDD yoki hech bo‘lmaganda yuqori test qamrovi
• Code review nafaqat uslub, balki arxitektura tekshiruvi bilan
• Muntazam refaktoring rivojlanish jarayonining bir qismi sifatida

Spagetti kodiga qarshi kurash vositalari

SonarQube — siklomatik murakkablikni, meros chuqurligini, metod hajmini kuzatadi. JDepend (Java) — paketlar orasidagi bog‘liqliklarni o‘lchaydi. PhpMetrics — PHP loyihalari uchun maintainability indeksini beradi. CI/CDda metriklarni kuzating — ugraning paydo bo‘lishining oldini oling, u bilan keyin kurashmang.