Frankenshteyn dasturlashda — bu nima, sabablari va profilaktikasi

Dasturlashda Frankenshteyn nima

Frankenshteyn (Frankenstein code, Frankenstein pattern) — bu dasturiy tizim birgalikda ishlash uchun mo'ljallanmagan qismlardan yig'iladigan antipattern. Frankenshteyn maxluqi kabi, bunday kod ishlashi mumkin, lekin u xunuk, oldindan aytib bo'lmaydigan va eng kichik o'zgarishlarda ham xavfli.

Atama adabiyotdan kelgan: Meri Shellining “Frankenshteyn yoki Zamonaviy Prometey” (1818) romanida olim turli vafot etgan odamlarning tanalari bo'laklaridan tirik mavjudot yaratgan. Dasturlashda o'xshashlik aniq — ishlab chiquvchilar turli freymvorklar, kutubxonalar, tillar bo'laklarini olib, ularni “tirik ip bilan” yopishtirib, ishlaydigan, ammo dahshatli natija oladi.

Frankenshteynni spagetti koddan farqi — muammoning miqyosi va tabiatida. Spagetti-kod — bu bitta texnologik stek ichidagi chalkash tuzilma. Frankenshteyn — bu arxitektura darajasidagi eklektika: turli texnologiyalar, mos kelmaydigan paradigmalar, bitta tizim ichidagi ziddiyatli yondashuvlar.

Frankenshteyn vs mikrosxizmatlar

Mikrosxizmatli arxitektura turli sxizmatlar uchun turli texnologiyalardan foydalanishga imkon beradi, lekin aniq chegaralar va standartlashtirilgan o'zaro ta'sir protokollari sharti bilan. Frankenshteyn — bu chegaralarsiz tartibsiz aralashma: bitta kontrollerda REST va GraphQL, bitta modulda ikkita ORM, bitta obyekt uchun SQL va NoSQL.

Nima uchun Frankenshteyn sindromi paydo bo'ladi

Texnik rahbar yoki arxitektorning yo'qligi — asosiy sabab. Loyihada arxitektura yaxlitligi uchun javobgar bo'lgan odam bo'lmasa, har bir ishlab chiquvchi “o'ziga mos” vositalarni tanlaydi. Biri Springni, ikkinchisi Guiceni, uchinchisi o'z yozgan DI ni yoqtiradi. Natija — arxitektura vinaigreti.

Loyihalarning birlashuvi — ikkinchi keng tarqalgan sabab. Ikki jamoa o'z modullarini mustaqil, turli steklardan foydalanib ishlab chiqqan. Modullarni bitta ilovaga birlashtirish kerak bo'lganda, ular shunchaki adapterlar va oraliq qatlamlar bilan “yopishtiriladi”. Frankenshteyn hosil bo'ladi.

Korporativ xaridlar — uchinchi stsenariy. A kompaniyasi B kompaniyasini sotib oldi va uning mahsulotini o'zinikiga integratsiya qilishni xohlaydi. Qayta yozish o'rniga — API, umumiy ma'lumotlar bazalari va “qo'ltiq tayoqchalar” orqali yopishtirish. Bir yildan keyin tizim hech kim tushunmaydigan maxluqqa aylanadi.

“Ijodkorlik” omili

Tajribali ishlab chiquvchilar yangi texnologiyalarni prodakshnda sinab ko'rmoqchi bo'lib, ko'pincha Frankenshteyn manbasiga aylanadi. Eksperimentlarni izolyatsiya qilingan modul bilan cheklash o'rniga, ular eksperimental kodni tizimning muhim qismiga kiritadi.

Haqiqiy loyihalarda Frankenshteyn misollari

Klassik misol — bitta ilovada bir nechta ORM ishlatish. Modullarning bir qismi Hibernate, bir qismi MyBatis, bir qismi esa to'g'ridan-to'g'ri JDBC so'rovlaridan foydalanadi. Tranzaksiyalar boshqarib bo'lmaydigan, kesh muvofiqsiz bo'ladi, yangi ishlab chiquvchi esa yangi ficha uchun qaysi yondashuvni tanlashni bilmaydi.

Ikkinchi misol — arxitektura uslublarini aralashtirish. REST API kontrollerida SOAP-sxizmatlar chaqiruvlari, to'g'ridan-to'g'ri SQL-so'rovlar, fayl tizimiga murojaat va HTML generatsiyasi uchraydi. Bunday ilovani test qilish, kengaytirish yoki hujjatlashtirish mumkin emas.

Uchinchi misol — texnologik stek: backend uchun Python, mikrosxizmat uchun Node.js, ish stoli kliyenti uchun C#, Android-ilovasi uchun Java ishlatiladi, va barcha biznes-mantiq ular o'rtasida javobgarlikni aniq bo'lishsiz tarqalgan.

// frankenshteyn — aralash uslublar va texnologiyalar
// callbacks, Promises va async/await birgalikda

// callbacks
db.query("SELECT * FROM users", function(err, rows) {
  if (err) handleError(err);
  // callback ichida Promise
  fetch("/api/data").then(function(data) {
    // then ichida async/await
    (async () => {
      const result = await processData(data);
      sendResponse(result);
    })();
  });
});

// toza kod — yagona async/await uslubi
async function getUserData(userId) {
  const user = await db.query("SELECT * FROM users WHERE id = ?", [userId]);
  const data = await fetch("/api/data/" + userId);
  return await processData(user, data);
}

Ma'lumotlar darajasidagi Frankenshteyn

Bitta ma'lumotlar bazasi bir vaqtning o'zida SQL-relyatsion (normalizatsiya bilan) va NoSQL-hujjatga yo'naltirilgan (JSON-ustunlar bilan) sifatida ishlatiladi. So'rovlarning bir qismi ORM orqali, bir qismi saqlangan protseduralar orqali, bir qismi koddan to'g'ridan-to'g'ri SQL orqali amalga oshiriladi. MB sxemasi hujjatlashtirilmagan, migratsiyalar ziddiyatli.

Frankenshteyn kodining oqibatlari

Onbordingning murakkabligi — birinchi oqibat. Yangi ishlab chiquvchi tizim qanday ishlashini tushunish uchun 5 til, 3 freymvork, 2 arxitektura uslubini bilishi kerak. Onbording haftalardan oylargacha cho'ziladi. LinkedIn (2023) ma'lumotlariga ko'ra, texnologik eklektikaga ega loyihalar yangi xodimlarni 2 baravar tez-tez yo'qotadi.

Xatti-harakatning oldindan aytib bo'lmaydiganligi — ikkinchi oqibat. Python-mikrosxizmatdagi o'zgarish kutilmaganda Java-modulini buzishi mumkin, chunki ular aniq kontraktlarsiz umumiy MBdan foydalanadi. Bunday muammolarni tuzatish stekdagi barcha texnologiyalarni bir vaqtning o'zida bilishni talab qiladi.

Xavfsizlik — uchinchi oqibat. Stekdagi har bir texnologiya o'z xavfsizlik konfiguratsiyasini, o'z patchlarini, o'z monitoringini talab qiladi. 5–6 xil turdagi texnologiya uchun xavfsizlikni maqbul darajada saqlash deyarli mumkin emas. Ulardan biri muqarrar ravishda zaif bo'lib chiqadi.

Frankenshteyn texnik qarzi

SonarQube texnik qarzni o'lchashi mumkin, lekin “arxitektura qarzi”ni — komponentlarning mos kelmasligini o'lchay olmaydi. Bu qarz linter ogohlantirishlarida emas, balki turli texnologiyalarda yozilgan uch xil modulni o'zgartirmasdan yangi funksiya qo'shish mumkin emasligida namoyon bo'ladi.

Maxluq yaratishdan qanday qochish kerak

Birinchi va asosiy qadam — texnologik stek yaxlitligi uchun javobgar arxitektor yoki tech lead tayinlash. Bu odam arxitektura taqrizisiz yangi texnologiyalarni joriy etishga veto huquqiga ega. Demokratiya emas, asosiy texnologiyalar bo'yicha mas'uliyatli yakka qaror.

Ikkinchi — Architecture Decision Record (ADR) jarayonini joriy etish. Har qanday muhim arxitektura qarori (MB, freymvork, protokol tanlash) qisqa matn ko'rinishida hujjatlashtiriladi: kontekst, ko'rib chiqilgan alternativalar, qabul qilingan qaror, oqibatlar. ADRlar repozitoriyada saqlanadi va butun jamoaga ochiq.

Uchinchi — “bitta vazifa — bitta vosita” tamoyilini o'rnatish. HTTP-so'rovlar uchun — bitta klient. ORM uchun — bitta kutubxona. Loglash uchun — bitta freymvork. Istisnolar faqat asoslantirilgan ADR orqali ruxsat etiladi. Loyihada allaqachon Axios bo'lsa — fetch qo'shmang, SLF4J bo'lsa — System.out orqali yozmang.

• Arxitektor yangi texnologiyalarga veto huquqi bilan
• Architecture Decision Records har bir muhim tanlov uchun
• Yagona stek har bir vazifa uchun — bitta HTTP-klient, bitta ORM
• RFC butun jamoa muhokamasi bilan yirik o'zgarishlar uchun
• Texnologik radar nima joriy etish mumkinligini kuzatish uchun

Eksperimental texnologiyalar siyosati

Eksperimentlar ruxsat etiladi, lekin izolyatsiya qilingan muhitda. Qolgan tizimga ta'sir qilmasdan yangi texnologiyaga qayta yozish mumkin bo'lgan modul yoki sxizmat ajrating. Eksperiment muvaffaqiyatli bo'lsa — ADR orqali standartlashtiring. Yo'q bo'lsa — oqibatlarsiz o'chiring.

Mavjud Frankenshteynni qanday refaktoring qilish kerak

Inventarizatsiya — birinchi qadam. Texnologik stekning to'liq xaritasini tuzing: qaysi freymvorklar, kutubxonalar, tillar, protokollar ishlatiladi, qaysi modullarda va qaysi vazifalar uchun. Muammo miqyosini ko'rasiz: vositalarning takrorlanishi, ziddiyatli texnologiyalar, ishlatilmaydigan bog'liqliklar.

Standartlashtirish — ikkinchi qadam. Har bir vazifa uchun bitta vosita tanlang. Masalan: ORM uchun faqat Hibernate, loglash uchun faqat SLF4J + Logback, API uchun faqat REST. Standartni ADRda hujjatlashtiring. Eklektika eng ko'p muammo keltiradigan modullardan almashtirishni boshlang.

Parallel Run strategiyasi — uchinchi qadam. Eski va yangi vositalar yangisi ishonchliligini isbotlaguncha parallel ishlaydi. Masalan, eski va yangi HTTP-kliyent bir vaqtda ishlaydi, lekin yangisi faqat so'rovlarning bir qismi uchun. Barqarorlashuv davridan keyin eskisi o'chiriladi.

// frankenshteyn — bitta loyihada uchta HTTP yondashuvi
// A modul: OkHttp
OkHttpClient client = new OkHttpClient().newCall(request);

// B modul: RestTemplate (Spring)
restTemplate.getForObject(url, String.class);

// C modul: java.net.HttpURLConnection
HttpURLConnection conn = (HttpURLConnection) new URL(url).openConnection();

// yagona yondashuv: sinxron uchun RestTemplate, reaktiv uchun WebClient
@Autowired
private RestTemplate restTemplate;

public String callApi(String url) {
    return restTemplate.getForObject(url, String.class);
}

Profilaktikada texnik rahbarning roli

Texnik rahbar — Frankenshteynga qarshi kurashning asosiy vositasi. Menejer emas, fil suyagidan minora ustidagi arxitektor emas, balki kod yozadigan, PRlarni review qiladigan va arxitektura qarorlarini qabul qiladigan amaliyotchi ishlab chiquvchi. Bunday odamsiz loyiha muqarrar ravishda texnologik eklektikaga tushib qoladi.

RFC (Request for Comments) — Open Source jamoalaridan olingan jarayon. Har qanday muhim texnologiyani joriy etishdan oldin muallif RFC yozadi: muammo, taklif qilingan yechim, alternativalar, joriy etish rejasi. Jamoa muhokama qiladi, ovoz beradi, qabul qiladi yoki rad etadi. RFC shaffoflikni ta'minlaydi va “yashirin” arxitektura qarorlarining oldini oladi.

Texnologik radar (ThoughtWorks'ning Technology Radar) — texnologiyalarni turkumlash vositasi: Adopt, Trial, Assess, Hold. Jamoa muntazam radarni qayta ko'rib chiqadi va statuslarni yangilaydi. Bu “moda”ni “foydali”dan ajratishga va tasdiqlanmagan texnologiyalarni muhim kodga joriy etishdan qochishga yordam beradi.

Muvofiqlik tamoyili

Eng muhim arxitektura sifati — muvofiqlik (consistency). Butun loyihada ishlatiladigan eng yaxshi bo'lmagan vosita, faqat bitta modulda ishlatiladigan eng yaxshi vositadan yaxshiroq. Muvofiqlik kognitiv yukni kamaytiradi, onbordingni soddalashtiradi va kodni oldindan aytib bo'ladigan qiladi.