Samaradorlik
Tajribalik dasturchilar yaxshi arxitekturani yomonidan oson ajrata olishadi, lekin agar ulardan uni bir necha so'z bilan tasvirlashni so'rasangiz, ular buni qilishda qiynalishlari mumkin. Yaxshi arxitektura uchun yagona mezon yo'q va birdan-bir belgilanish ham yo'q.
Lekin, o'ylab ko'rilsa, yaxshi arxitektura bilan mos keluvchi bir qancha mezonlar yozish mumkin. Yaxshi arxitektura - bu avvalo mantiqli arxitektura bo'lib, dastur ishlab chiqishni va uni saqlashni oddiy va samarali qiladi.
Dasturda yaxshi arxitektura bo'lsa, qanday yaratilganini va kodni qayerda yozishni tushunish har doim oson bo'ladi. Yaxshi arxitektura bilan dastur o'zgartirilishi, sinab ko'rilishi, buzilishdan himoyalanishi va rivojlanishi osonroq. Aqliy odamlar yaxshi arxitektura mezonlarini quyidagicha tuzishdi:
- Samaradorlik;
- Moslashuvchanlik;
- Kengaytirish imkoniyati;
- Masshtablanish;
- Test qilish imkoniyati;
- Kodni saqlash qulayligi.
Tizimning samaradorligi. Dastur, albatta, belgilangan vazifalarni hal qilishi va o'z funksiyalarini yaxshi bajarishi kerak, hatto turli sharoitlarda ham. Har qanday dastur o'z vazifasini bajaradi (agar u yozilgan bo'lsa), deb o'ylashadi, lekin ko'pincha bu umuman shunday emas.
Sen doimiy ravishda o'z vazifalarini bajarmaydigan dasturlarni uchratib turasan.
- Libre Office Microsoft Office'ga to'liq o'rinbosar (aslida emas);
- Edge brauzeri barcha web-standartlarni qo'llab-quvvatlaydi (aslida emas);
- Bank foydalanuvchilarning shaxsiy ma'lumotlari xavfsizligini ta'minlaydi (aslida emas).
Va bu hali biz unumdorlik, ishonchlilik, xatolarni o'z vaqtida tuzatish yoki ma'lum bo'lgan zaifliklar haqida ma'lumotlar e'lon qilish haqida gapirmagan holda.
Hech kim mukammal emasligini hammamiz tushunamiz, lekin dastur o'z oldiga qo'yilgan asosiy vazifalarni hal qilishi kerak. Shuning uchun samaradorliksiz hech yerni bormaysan.
Moslashuvchanlik
Xuddi samaradorlikdan ham ko'ra muhimroq narsa bor, bu - moslashuvchanlik. Har qanday dastur ilovasi vaqt o'tishi bilan o'zgarishi kerak, chunki talablar o'zgaradi, yangilari qo'shiladi. Qanchalik tez va oson mavjud funksionallikka o'zgartirish kiritish mumkin bo'lsa, qanchalik kam muammolar va xatolarni keltirib chiqarsa, tizim arxitekturasi shunchalik moslashuvchan bo'ladi.
Ko'pincha yangi dasturchilar/ arxitektorlar hozirgi vazifalar uchun mukammal arxitekturaga ehtiyoj bor deb o'ylashadi. Yo'q. Sen, senga bir yil ichida aytilgan vazifalar uchun mukammal arxitekturaga ehtiyojing bor. Sen, kelajakdagi vazifalarni bilmagan holda, ularning mavjud bo'lishini bilishing kerak.
Ularni taxmin qilishga urinish ma'nosizdir, chunki har doim kutilmagan narsa bo'ladi. Lekin sen bunday vazifalar paydo bo'lishini hisobga olishing kerak. Shuning uchun ishlab chiqish jarayonida natijani qanday o'zgartirish kerakligini baholashga harakat qiling.
O'zingdan so'rang: "Agar hozirgi arxitektura qarori noto'g'ri bo'lsa, nima bo'ladi?", "Bu holda qancha kod o'zgarishlarga uchraydi?". Tizimning bir qismini o'zgartirish, uning boshqa qismlariga ta'sir qilmasligi kerak.
Mumkin qadar arxitektura qarorlari "to'kilsin" va arxitektura xatolarining oqibatlari oqilona darajada cheklanadi. "Yaxshi arxitektura asosiy qarorlarni qabul qilishni kamaytirish imkonini beradi" (Bob Martin) va xatolar "narxini" minimallashtiradi.
Shunday yondashuvlardan biri ilovani mikroservislarga bo'lish: allaqachon mavjud bo'lgan mantiqni osonlik bilan alohida qismlarga ajratish mumkin. Lekin eng katta muammo — kelajakdagi o'zgarishlarni amalga oshirish uchun o'nlab xizmatlarga bir vaqtning o'zida o'zgartirish kiritish.
Masshtablanish
Masshtablanish — bu loyihaga yangi odamlarni qo'shish orqali ishlab chiqish muddatini kamaytirish imkoniyati. Arxitektura ishlab chiqish jarayonini parallel ravishda amalga oshirishga, shunday qilib ko'p odamlar bir vaqtning o'zida dastur ustida ishlashga imkon berishi kerak.
Bu qoidaga o'z-o'zicha rioya etiladigan ko'rinadi, lekin amalda hammasi teskari bo'ladi. Hatto "Mifologik odam-oy" kitobi juda mashhur, unda yangi odamlarni loyihaga qo'shganda uning ishlab chiqish muddati nima uchun ortishi tushuntiriladi.
Kengaytirish imkoniyati
Kengaytirish imkoniyati - bu tizimga yangi funksiyalar va obyektlar qo'shish imkoniyati, tizimning asosiy tarkibini buzmagan holda. Boshlang'ich bosqichda tizimga faqat asosiy va eng zaruriy funksional kiritish maqsadga muvofiqdir.
Bu, YAGNI — you ain’t gonna need it, "senga bu kerak bo'lmaydi" deb ataladigan printsipdir. Shu bilan birga, arxitektura qo'shimcha funksionallikni zarurat bo'yicha osongina qo'shishga imkon berishi kerak. Shuningdek, eng katta ehtimol bilan o'zgarishlarni kiritish minimal kuch talab qilishi kerak.
Tizim arxitekturasi moslashuvchanlik va kengaytirish imkoniyatiga ega bo'lishi kerakligi talabi shunchalik muhimki, hatto u alohida printsip sifatida belgilangan - "Ochiq/Yopiq printsip". Open-Closed Principle — SOLID ning ikkinchi printsipi: dasturiy obyektlar (klasslar, modullar, funksiyalar) kengaytirish uchun ochiq, lekin modifikatsiya uchun yopiq bo'lishi kerak.
Boshqa so'zlar bilan aytganda: tizimning xatti-harakatlarini o'zgartirish va kengaytirish imkoniyati mavjud qismlarini qayta yozmasdan amalga oshirilishi kerak.
Bu shuni anglatadiki, ilovani uni tuzayotganingizda xatti-harakatlarini o'zgartirish va yangi funksionallikni qo'shishni yangi kod yozish orqali amalga oshirilishi lozim, va shu bilan birga allaqachon mavjud bo'lgan kodni o'zgartirish shart bo'lmasligi kerak.
Shunday qilinganda yangi talablarning kelib chiqishi mavjud mantiqni o'zgartirishga olib kelmaydi, balki eng avvalo uning kengaytirilishi orqali amalga oshirilishi mumkin bo'ladi. Aynan shu printsip "plugin arxitekturasi"ning asosi hisoblanadi (Plugin Architecture). Bu qanday texnikalar yordamida amalga oshirilishi mumkinligi haqida keyinroq aytiladi.
Siz servletlar va filtrlarni eslaysizmi? Filtrlar nima uchun kerak edi, yana alohida interfeyslar bilan, agar asosan barcha shu mantiq servletlar yordamida amalga oshirilishi mumkin bo'lsa?
Bu filtrlar (xizmat ko'rsatish servletlari) kontseptsiyasining ixtirosi, turli xil xizmat funksiyalarini alohida qatlamga chiqarishga imkon berdi. Va kelajakda filtrlar xatti-harakatlarini o'zgartirishda servetlarni o'zgartirish shart emas edi.
Filtrlar ixtiro qilinguncha, barcha xizmat ko'rsatish mantigi, masalan so'rovlarni yo'naltirish uchun, o'zlari servletlarda joylashtirilgan edi. Va ko'pincha mantiqdagi kichik bir o'zgarish, barcha servletlar orqali o'tib, ularning barchasida turli o'zgarishlar kiritishni talab qilardi.
Test qilish imkoniyati
Agar sen Java Backend Developer bo'lsang, sening server ilovalaring ko'pincha REST API shaklida tashqi tomonlarga metodlar to'plamini taqdim etadi. Va barcha metodlaring sen o'ylaganday ishlayotganligiga ishonch hosil qilish uchun ularni testlar bilan qamrab olishing kerak.
Xususiy APIni testlar bilan qamrab olish - bu yaxshi uslub. Bu sening API haqiqatan nimani ko'zlanganini amalga oshirayotganiga ishonch hosil qiladi. Va yana, bu yanada muhimroq: sen server mantiqiga o'zgartirish kiritish va tasodifan hech narsani buzmaganligingni osonlik bilan tekshirish imkoniyatiga ega bo'lasan.
Testlarni yozishni boshlaganingdan so'ng, sen kodning aksariyat qismini umuman test qilish mumkin emasligini tushunasan: private metodlar, kuchli bog'liqlik, statik klasslar va o'zgaruvchilar.
“Kod ishlayotgan bo'lsa, testlar nima uchun kerak?”, — deb so'raydi yangi o'rganuvchi.
“Testlash mumkin bo'lmasa, ishlayotgan kod nima uchun kerak?”, — deb so'raydi professionallar.
Oson test qilish mumkin bo'lgan kod, kamroq xatolarni o'z ichiga oladi va ishonchli ishlaydi. Lekin testlar kod sifatini yaxshilaydi ham. Dasturchilarning deyarli barchasi vaqti kelib "yaxshi test qilish imkoniyati" talabi yaxshi dizaynga yo'naltiruvchi kuch ekanini tushunishadi.
“Mukammal arxitektura” kitobidan bir iqtibos keltiraman: "Klassning 'testlash mumkinligi' printsipini klass dizaynining 'lagnmusu qog'ozi' sifatida foydalaning. Hatto birgina test kodining biror qatorini yozmagan holda, bu savolga javob berish 90% hollarda dizaynning 'yaxshi' yoki 'yomon'ligini tushunishga yordam beradi".
Testlar asosida dastur ishlab chiqishning butun bir metodologiyasi mavjud bo'lib, u testlar orqali ishlab chiqish (Test-Driven Development, TDD) deb ataladi. Bu esa albatta boshqa bir chetlikdir: kod yozishni boshlashdan avval kod yoz.
Kodni saqlash qulayligi
Dastur ustida odatda ko'plab odamlar ishlaydi - ba'zilari ketadi, yangi keladi. IT-kompaniyada dasturchining o'rtacha ishlash muddati bir yarim yil. Shunday qilib, besh yillik loyihaga kelsangiz, faqat 20% hamkasblaringiz dastur ustida boshidanoq ishlagan bo'ladi.
Boshqalar tomonidan yozilgan dastur ustida ishlash va uni rivojlantirish juda qiyin. Hatto dastur allaqachon yozilgan bo'lsa ham, uni saqlashni davom ettirish kerak: xatolarni tuzatish va kichik o'zgartirishlar kiritish. Va ko'pincha bu ishni dastur yozilishida ishtirok etmagan odamlar bajarishi kerak bo'ladi.
Shuning uchun yaxshi arxitektura tizim yangi odamlar uchun nisbatan o'rganishga qulay bo'lishi kerak. Loyiha quyidagi talablarga javob berishi kerak:
- Yaxshi tuzilgan bo'lishi kerak.
- Takrorlanishlarni o'z ichiga olmaydi.
- Yaxshi kodlangan kodga ega bo'lishi kerak.
- Hujjat bo'lishi maqsadga muvofiq.
- Standart va odatiy dasturchilar uchun yechimlarni qo'llash!
Loyiha ustida ishlayotgan dasturni 5 ballik tizim bo'yicha baholashing mumkin. Faqatgina har bir talab uchun ikki ball oling. Va agar 5 va ko'proq ball olsang, sen - omadli ekansan.
Dasturchilarda kam ajablanish printsipi ham bor: tizim qanchalik ekzotik bo'lsa, uni boshqalarga tushunish shunchalik qiyin bo'ladi. Bu odatda foydalanuvchi interfeysi haqida qo'llaniladi, lekin kod yozish uchun ham qo'llanilishi mumkin.
GO TO FULL VERSION