Yomon dizayn mezonlari
Hayot juda sodda tuzilgan: ko'pincha aqlli bo'lish uchun shunchaki ahmoqona ishlar qilmaslik kerak. Bu dasturiy ta'minot ishlab chiqishga ham tegishli: ko'pgina hollarda biror narsani yaxshi qilish uchun shunchaki noto'g'ri qilmaslik kerak.
Ko'pgina dasturchilar yomon dizaynga ega bo'lgan tizim qismlarini ishda ko'rishgan. Ammo yanada achinarli tomoni shundaki, ko'pchilik sizning bunday tizimning muallifiga aylanganingizda bu ko'rinishni boshdan kechirishadi. Yaxshi niyat bilan kirishgansiz, lekin natija odatda muvaffaqiyatsiz chiqadi.
Ko'pgina ishlab chiquvchilar yomon arxitekturaga intilmaydi, ammo ko'plab tizimlarda uning arxitekturasi dahshatli deb aytadigan bir holat keladi. Nega bu sodir bo'ladi? Arxitektura dizayni boshidanoq yomonmi yoki vaqt o'tishi bilan shunday bo'ladimi?
Bu muammoning ildizi "yomon" dizayn ta'rifining yo'qligidadir.
Menga shunday tuyulmoqda, dizayn sifati va uning "chiriganligi" sabablarini tushunish har qanday dasturchi uchun eng muhim xususiyatlardir. Ko'pgina boshqa holatlar kabi, asosiy narsa - muammoni aniqlash, uni hal qilish esa texnikaning ishi bo'ladi.
“Yomon dizayn” ta'rifi
Agar o'zingizning kodingizni boshqa dasturchi hamkasbimga maqtamoqchi bo'lsangiz, ehtimol sizdan masxara qiladi: “Kim bunday qiladi?”, 'Nega aynan shunday?” va “Men buni boshqacha qilardim”. Bunday narsa ko'p uchraydi.
Hamma odamlar har xil, lekin siz kodni baribir hamkasblaringiz - dasturchilar uchun yozasiz, shuning uchun har bir funktsiyani ishlab chiqish jarayonida har doim sizning kodingizni boshqa odamlar ko'rib chiqadigan review fazasi kerak.
Lekin ko'pgina narsalarni turli xil usullarda qilish mumkin bo'lsa-da, barcha dasturchilar rozi bo'lishi mumkin bo'lgan mezonlar to'plami mavjud. Har qanday kod bo'lagi, o'z talablariga javob beradigan, lekin baribir bir (yoki bir nechta) xususiyatlarga ega bo'lgan, yomon dizayn bilan ajralib turadi.
Yomon dizayn:
- O'zgartirish qiyin, chunki har qanday o'zgartirish tizimning juda ko'p boshqa qismlariga ta'sir qiladi. (Qattiqlik, Rigidity).
- O'zgartirishlar kiritilganda, tizimning boshqa qismlari kutilmaganda buziladi. (Mo'rtlik, Fragility).
- Kodni boshqa dasturda qayta ishlatish qiyin, chunki uni joriy dasturdan ajratib olish juda qiyin. (Qimirlamaslik, Immobility).
Va eng kulgilisi shundaki, deyarli hech qanday tizim qismi topib bo'lmaydi, ularning hech biri bu xususiyatlarga ega emas (ya'ni moslashuvchan, ishonchli va qayta ishlatiladigan), talablarga javob beradi va shu bilan birga dizayni yomon.
Shunday qilib, biz bu uchta xususiyatni dizaynning "yomon" yoki "yaxshi" ekanligini aniq belgilash uchun ishlatishimiz mumkin.
“Yomon dizayn” sabablari
Dizaynni qattiq, mo'rt va qimirlamas nima qiladi? Modullarning qattiq o'zaro bog'liqligi.
Dizayn qattiq (rigid) bo'ladi, agar uni osongina o'zgartirib bo'lmasa. Bu qattiqlik, bir tizimga bog'langan kod bo'lagi o'zgartirilganda, bog'liq modullarda kechadigan kaskadli o'zgarishlar bilan bog'liq. Bu har doim bitta odam kod ustida ishlaganda sodir bo'ladi.
Bu darhol butun tijorat ishlanmalarini murakkablashtiradi: agar kaskadli o'zgarishlar soni loyiha muhandisi yoki ishlab chiquvchi tomonidan bashorat qilinmasa, bunday o'zgarishlarning ta'sirini baholashning imkoni yo'q. Shuning uchun bunday o'zgarishlarni uzoq muddatga qoldirishga harakat qilinadi.
Va bu o'z navbatida o'zgarish narxini oldindan aytib bo'lmaydigan qiladi. Bunday noaniqlik bilan duch kelgan menejerlar o'zgarishlarni kiritishga istaksiz kirishadilar va shu bilan dizayn rasmiy ravishda qattiq bo'ladi.
Bir paytda sizning loyihangiz "hodisa gorizonti" dan o'tadi va qattiq arxitekturaning "qora tuynugiga" tushib ketishga mahkum bo'ladi.
Mo'rtlik (fragility) — bu tizimning bir o'zgarishdan keyin ko'plab joylarda sinishga moyilligi. Odatda yangi muammolar o'zgarish joyi bilan kontseptual bog'liq bo'lmagan joylarda sodir bo'ladi. Bunday mo'rtlik tizim dizayni va qo'llab-quvvatlashga bo'lgan ishonchni jiddiy ravishda buzadi.
Bu ko'pincha xususiy metodlar yo'qligida sodir bo'lgan edi. Barcha metodlarni ochiq qilsangiz, mo'rt arxitekturaga duch kelasiz. Inkapsulyatsiya bu muammo bilan mikro darajada kurashadi. Ammo makro darajada sizga modulli arxitektura kerak bo'ladi.
Agar loyihaning arxitekturasi mo'rt bo'lsa, dasturchilar mahsulot sifatini kafolatlay olmaydilar.
Dasturning bir qismida oddiy o'zgarishlar boshqa bog'liq bo'lmagan qismlarda xatoliklarni keltirib chiqaradi. Bu xatolarni tuzatish yanada ko'proq muammolarni keltirib chiqaradi va qo'llab-quvvatlash jarayoni o'z dumini quvib borayotgan mashhur itga aylanadi.
Dizayn qimirlamas (immobile) bo'ladi, tizimning kerakli qismlari boshqa keraksiz tafsilotlarga qattiq bog'liq. Juda ko'p o'z kodlari, o'zining noyob yondashuvlari va qarorlari.
JUL loggerini eslaysizmi, uning ishlab chiqaruvchilari asosli sabablar bo'lmaksiz o'z loglash darajalarini o'ylab topgan edi? Bu aynan shunday holat.
Loyiha muhandisiga mavjud dizaynni qayta ishlatish qanchalik oson ekanligini tasavvur qilish uchun uni yangi dasturda ishlatish qanchalik oson bo'lishini o'ylab ko'rish kifoya.
Agar dizayn qattiq bog'liq bo'lsa, ushbu loyiha muhandisi tizimning kerakli qismlarini keraksiz tafsilotlardan ajratish uchun qancha ish talab qilinishini ko'rganda dahshatga tushadi. Ko'pgina hollarda bunday dizaynni qayta ishlatish mumkin emas, chunki uni ajratish narxi uni noldan ishlab chiqish narxidan oshadi.
Dolzarbligi
Hammasi o'zgaradi, ammo hammasi o'sha-o'sha bo'lib qoladi. (Xitoy maqoli)
Yuqorida juda yaxshi savollar ko'tarilgan edi. Mo'rt va qattiq tizimlar qanchalik xavfli? Buni boshqarish jarayoni qandaydir loyihani oldindan aytib bo'lmaydigan va boshqarib bo'lmaydigan qiladi. Va narx - juda yuqori.
Menejer ba'zi funktsiyalarni qo'shishga ruxsat berishi yoki bermasligi qanday aniqlanadi, agar u aslida bunga qancha vaqt ketishini bilmasa? Vazifalarga qanday ustuvorlik berish, agar ularning bajarilishi vaqtini va murakkabligini aniq baholab bo'lmasa?
Texnik qarzni to'lash uchun ishlab chiquvchilarga qanday to'lash kerak, agar uni to'lashda qanchalik zarbalanishimizni biz oldindan bilmasak va to'lanmaguncha tushunmasak?
Kodni qayta ishlatish yoki test qilish muammolari ham dolzarb. Unit-test'lar nafaqat test qilinayotgan modul haqidagi ba'zi taxminlarni tekshirish uchun xizmat qiladi, balki uning bog'liqlik darajasini aniqlash va qayta foydalanish ko'rsatkichlari sifatida xizmat qiladi.
Bob Martindan bu holatga oid iqtibos: “Kodlarınızı qayta ishlatishga qo'yish uchun zarur bo'lgan ish hajmi uni noldan ishlab chiqish narxidan kam bo'lishi kerak”. Aks holda, hech kim bu ish bilan shug'ullanmaydi.
Prinsip va dizayn chizmalarini qo'llash bitta maqsadga xizmat qiladi - dizaynni yaxshi qilish. Agar ularning qo‘llanilishi sizga hech qanday foyda keltirmasa (yoki aksincha, “yaxshi dizayn” printsiplariga ziddir bo‘lsa), demak, sizning konservatoriyangizda qandaydir narsa noto‘g‘ri va ehtimol, instrument noto‘g‘ri ishlatilmoqda.
GO TO FULL VERSION