64,464 oxunuşlar

Proqram sistemlərinin layihələndirilməsi zamanı mürəkkəbliyin öhdəsindən necə gəlmək olar

tərəfindən Aleksei23m2024/02/05

IDMore

Çox uzun; Oxumaq

Mürəkkəblik düşməndir! Gəlin bununla necə məşğul olacağımızı öyrənək!

featured image - Proqram sistemlərinin layihələndirilməsi zamanı mürəkkəbliyin öhdəsindən necə gəlmək olar

Bütün bunlar nə ilə bağlıdır?

Mühəndislik karyeramız ərzində hər gün, hər an, məlumat çatışmazlığı səbəbindən qərar verməli və ya təxirə salmalı olduğumuz müxtəlif mürəkkəblik və vəziyyətlərdə çoxlu müxtəlif problemlərlə qarşılaşırıq. Biz hər dəfə yeni xidmətlər quranda, infrastruktur quranda və ya hətta inkişaf proseslərini formalaşdıranda biz müxtəlif çətinliklərin böyük dünyasına toxunuruq.

Bütün problemləri sadalamaq çətin və bəlkə də qeyri-mümkündür. Bu problemlərdən bəziləri ilə yalnız müəyyən bir sahədə işləsəniz qarşılaşacaqsınız. Digər tərəfdən, İT sistemlərinin qurulması üçün həlledici əhəmiyyət kəsb etdiyi üçün hamımızın necə həll edəcəyimizi anlamalı olduğumuz çox şey var. Böyük ehtimalla bütün layihələrdə onlarla qarşılaşacaqsınız.

Bu yazıda proqram proqramları yaratarkən qarşılaşdığım bəzi problemlərlə bağlı təcrübələrimi paylaşacağam.

Cross-Cutting Concern nədir?

Vikipediyaya baxsaq, aşağıdakı tərifi tapa bilərik

Aspekt yönümlü proqram təminatının işlənib hazırlanmasında kəsişən narahatlıqlar proqramın bir neçə modula təsir edən aspektləridir, onların heç birində əhatə olunma ehtimalı yoxdur. Bu narahatlıqlar çox vaxt həm dizaynda, həm də tətbiqdə sistemin qalan hissəsindən təmiz şəkildə ayrıla bilməz və ya səpilmə (kodun təkrarlanması), dolaşıq (sistemlər arasında əhəmiyyətli asılılıqlar) və ya hər ikisi ilə nəticələnə bilər.

Bunun nə olduğunu çox təsvir edir, lakin mən onu bir az genişləndirmək və sadələşdirmək istəyirəm:

Qarşılıqlı narahatlıq bir çox digər hissələrə təsir edən (və ya “keçirən”) sistemin/təşkilatın konsepsiyası və ya komponentidir.

Bu cür narahatlıqların ən yaxşı nümunələri sistem arxitekturası, giriş, təhlükəsizlik, əməliyyatların idarə edilməsi, telemetriya, verilənlər bazası dizaynı və bir çox başqalarıdır. Onların bir çoxu haqqında daha sonra bu məqalədə ətraflı danışacağıq.

Kod səviyyəsində, kəsişən narahatlıqlar tez-tez Aspekt yönümlü Proqramlaşdırma (AOP) kimi üsullardan istifadə etməklə həyata keçirilir, burada bu narahatlıqlar proqram boyunca tətbiq oluna bilən ayrı-ayrı komponentlərə modullaşdırılır. Bu, biznes məntiqini bu narahatlıqlardan təcrid edərək kodu daha oxunaqlı və davamlı edir.

Aspektlərin Təsnifatı

Aspektləri əhatə dairəsi, ölçüsü, funksionallığı, əhəmiyyəti, hədəfi və başqaları kimi müxtəlif xüsusiyyətlərə görə bölmək yolu ilə təsnif etməyin bir çox mümkün yolu var, lakin bu məqalədə mən sadə əhatə dairəsi təsnifatından istifadə edəcəyəm. Bununla mən bu spesifik cəhətin hara yönəldiyini nəzərdə tuturam, istər bütün təşkilat, istər müəyyən bir sistem, istərsə də həmin sistemin konkret elementi.

Beləliklə, mən aspektləri Makro və Mikroya bölmək niyyətindəyəm.

Makro aspekt dedikdə, əsasən bütün sistem üçün izlədiyimiz mülahizələri nəzərdə tuturam, məsələn, seçilmiş sistem arxitekturası və onun dizaynı (monolit, mikroservislər, xidmət yönümlü arxitektura), texnologiya yığını, təşkilat strukturu və s. Makro aspektlər əsasən strateji və yüksək səviyyə ilə bağlıdır. qərarlar.

Bu arada, Mikro aspekt kod səviyyəsinə və inkişafına daha yaxındır. Məsələn, verilənlər bazası, qovluqların və siniflərin layihə strukturu və ya hətta xüsusi obyekt dizayn nümunələri ilə qarşılıqlı əlaqə üçün hansı çərçivədən istifadə olunur.

Bu təsnifat ideal olmasa da, mümkün problemlər və onlara tətbiq etdiyimiz həllərin əhəmiyyəti və təsiri haqqında anlayışı strukturlaşdırmağa kömək edir.

Bu yazıda mənim əsas diqqətim makro aspektlərə yönəldiləcək.

Makro Aspektlər

Təşkilat strukturu

Proqram arxitekturasını yeni öyrənməyə başlayanda Conway qanunu və onun təşkilati struktura təsiri haqqında çoxlu maraqlı məqalələr oxudum. Xüsusilə bu . Deməli, bu qanunda belə deyilir

Sistemi dizayn edən hər hansı bir təşkilat (geniş şəkildə müəyyən edilir) strukturu təşkilatın kommunikasiya strukturunun surəti olan dizayn hazırlayacaqdır.

Mən həmişə inanmışam ki, bu konsepsiya həqiqətən çox universaldır və Qızıl Qaydanı təmsil edir.

Daha sonra modelləşdirmə sistemləri üçün Eric Evansın Domain-Driven Design (DDD) yanaşmasını öyrənməyə başladım. Erik Evans Məhdud Kontekst identifikasiyasının vacibliyini vurğulayır. Bu konsepsiya mürəkkəb domen modelini hər birinin öz məhdud bilik dəsti olan daha kiçik, daha idarə oluna bilən bölmələrə bölməyi nəzərdə tutur. Bu yanaşma effektiv komanda ünsiyyətinə kömək edir, çünki o, bütün sahə üzrə geniş biliyə ehtiyacı azaldır və kontekstdə keçidi minimuma endirir, beləliklə, söhbətləri daha səmərəli edir. Kontekstlərin dəyişdirilməsi indiyə qədər ən pis və ən çox resurs istehlak edən şeydir. Hətta kompüterlər də bununla mübarizə aparır. Kontekstdə keçidin tam olmamasına nail olmaq çətin olsa da, mən hesab edirəm ki, biz buna çalışmalıyıq.

Conway Qanununa qayıdaraq, onunla bağlı bir neçə problem tapdım.

Sistem dizaynının təşkilati strukturu əks etdirdiyini göstərən Konvey Qanunu ilə qarşılaşdığım ilk məsələ mürəkkəb və əhatəli Məhdud Kontekstlərin formalaşdırılması potensialıdır. Bu mürəkkəblik təşkilati strukturun domen sərhədləri ilə uyğunlaşmadığı zaman yaranır və bu, bir-birindən çox asılı olan və məlumatla yüklənmiş Məhdud Məzmunlara gətirib çıxarır. Bu, inkişaf komandası üçün tez-tez kontekst dəyişikliyinə səbəb olur.

Başqa bir məsələ , təşkilati terminologiyanın kod səviyyəsinə sızmasıdır. Təşkilati strukturlar dəyişdikdə, dəyərli resursları istehlak edərək kod bazasında dəyişiklikləri tələb edir.

Beləliklə, Tərs Conway Manevrinə riayət etmək istədiyiniz proqram arxitekturasını təşviq edən sistem və təşkilat yaratmağa kömək edir. Bununla belə, qeyd etmək lazımdır ki, bu yanaşma artıq formalaşmış arxitektura və strukturlarda çox yaxşı işləməyəcək, çünki bu mərhələdəki dəyişikliklər uzun müddətdir, lakin hər hansı bir dəyişikliyi tez təqdim etdikləri üçün startaplarda müstəsna performans göstərir.

Böyük palçıq topu

Bu naxış və ya “anti-naxış” heç bir arxitektura olmadan bir sistem qurmağa imkan verir. Qaçılmaz artan mürəkkəbliyi idarə etmək üçün heç bir qaydalar, sərhədlər və strategiya yoxdur. Mürəkkəblik proqram sistemlərinin qurulması səyahətində ən qorxulu düşməndir.

Belə bir sistemin qurulmasının qarşısını almaq üçün xüsusi qaydalara və məhdudiyyətlərə əməl etməliyik.

Sistem arxitekturası

Proqram Arxitekturasının saysız-hesabsız tərifləri var. Onların bir çoxunu bəyənirəm, çünki onlar müxtəlif aspektləri əhatə edir. Ancaq memarlıq haqqında düşünə bilmək üçün təbii olaraq onlardan bəzilərini beynimizdə formalaşdırmalıyıq. Və qeyd etmək lazımdır ki, bu tərif inkişaf edə bilər. Beləliklə, ən azı indiyə qədər özüm üçün aşağıdakı təsvirim var.

Proqram arxitekturası hər gün verdiyiniz və qurulmuş sistemə təsir edən qərarlar və seçimlər haqqındadır.

Qərarları qəbul etmək üçün “çanta”nızda yaranan problemlərin həlli üçün prinsiplər və nümunələr olmalıdır, həmçinin qeyd etmək lazımdır ki, tələbləri başa düşmək biznesin ehtiyac duyduğu şeyi qurmaq üçün açardır. Ancaq bəzən tələblər şəffaf deyil və ya hətta müəyyən edilmir, bu halda daha çox aydınlıq əldə etmək üçün gözləmək və ya təcrübənizə güvənmək və intuisiyanıza etibar etmək daha yaxşıdır. Ancaq hər halda, güvənmək üçün prinsipləriniz və nümunələriniz yoxdursa, düzgün qərarlar qəbul edə bilməzsiniz. Proqram Arxitektura Üslubunun tərifinə gəldiyim yer budur.

Proqram Arxitektura Üslubu proqram təminatının necə qurulacağını təyin edən prinsiplər və nümunələr toplusudur.

Planlaşdırılan memarlığın müxtəlif tərəflərinə yönəlmiş çoxlu müxtəlif memarlıq üslubları var və onlardan bir neçəsinin eyni vaxtda tətbiqi normal bir vəziyyətdir.

Məsələn, məsələn:

Monolit memarlıq
Domen əsaslı dizayn
Komponent əsaslı
Mikroservislər
Boru və filtrlər
Hadisəyə əsaslanan
Mikrokernel
Xidmət yönümlü

və s...

Əlbəttə ki, onların üstünlükləri və mənfi cəhətləri var, amma mənim öyrəndiyim ən vacib şey, memarlığın aktual problemlərdən asılı olaraq tədricən inkişaf etməsidir. Monolit arxitekturadan başlamaq əməliyyat mürəkkəbliyini azaltmaq üçün əla seçimdir, çox güman ki, bu arxitektura məhsulun qurulmasının Product-market Fit (PMI) mərhələsinə çatdıqdan sonra da ehtiyaclarınıza uyğun olacaq. Geniş miqyasda, müstəqil yerləşdirmə, heterojen texnoloji yığın mühiti və daha az əlaqəli arxitekturaya nail olmaq üçün hadisələrə əsaslanan yanaşmaya və mikroservislərə doğru hərəkət etməyi düşünə bilərsiniz (və bu vaxt hadisələrə əsaslanan və pub-sub yanaşmalarının təbiətinə görə daha az şəffafdır. bunlar qəbul edilir). Sadəlik və səmərəlilik yaxındır və bir-birinə böyük təsir göstərir. Adətən, mürəkkəb arxitekturalar yeni funksiyaların inkişaf sürətinə təsir edir, mövcud olanları dəstəkləyir və qoruyur və sistemin təbii təkamülünə meydan oxuyur.

Bununla belə, mürəkkəb sistemlər çox vaxt mürəkkəb və hərtərəfli arxitektura tələb edir ki, bu da qaçılmazdır.

Düzünü desəm, bu çox geniş mövzudur və təbii təkamül üçün sistemlərin necə qurulması və qurulması ilə bağlı çox gözəl ideyalar var. Təcrübəmə əsaslanaraq, aşağıdakı yanaşmanı işlədim:

Demək olar ki, həmişə monolit memarlıq üslubu ilə başlayır, çünki o, paylanmış sistemlərin təbiəti ilə əlaqədar yaranan problemlərin əksəriyyətini aradan qaldırır. Aydın sərhədləri olan tikinti komponentlərinə diqqət yetirmək üçün modul monolitə riayət etmək də məntiqlidir. Komponent əsaslı yanaşmanın tətbiqi hadisələrdən istifadə etməklə onların bir-biri ilə ünsiyyət qurmasına kömək edə bilər, lakin birbaşa zənglərin olması (aka RPC) başlanğıcda işləri asanlaşdırır. Bununla belə, komponentlər arasında asılılıqları izləmək vacibdir, çünki A komponenti B komponenti haqqında çox şey bilirsə, bəlkə də, onları birinə birləşdirməyin mənası var.
İnkişafınızı və sisteminizi miqyaslandırmağınız lazım olan vəziyyətə yaxınlaşdığınız zaman, müstəqil olaraq yerləşdirilməli və ya hətta xüsusi tələblərlə miqyası artırılmalı olan komponentləri tədricən çıxarmaq üçün Stangler nümunəsinə əməl etməyi düşünə bilərsiniz.
İndi, əgər sizin gələcəyə dair aydın təsəvvürünüz varsa, bu bir az inanılmaz şansdırsa, istədiyiniz arxitekturaya qərar verə bilərsiniz. Bu anda siz Orkestrasiya və Xoreoqrafiya yanaşmalarını tətbiq etməklə, müstəqil miqyaslı yazma və oxuma əməliyyatları üçün CQRS nümunəsini daxil etməklə və ya hətta ehtiyaclarınıza uyğun gələrsə, monolit arxitekturaya sadiq qalmağa qərar verərək mikroservis arxitekturasına keçməyə qərar verə bilərsiniz.

DAU (Gündəlik Aktiv İstifadəçilər), MAU (Aylıq Aktiv İstifadəçilər), RPC (Saniyədə Sorğu) və TPC (Saniyədə Əməliyyat) kimi rəqəmləri və ölçüləri başa düşmək də çox vacibdir, çünki bu, arxitektura üçün seçim etməkdə sizə kömək edə bilər. 100 aktiv istifadəçi və 100 milyon aktiv istifadəçi fərqlidir.

Son qeyd olaraq deyərdim ki, memarlığın məhsulun uğuruna əhəmiyyətli təsiri var. Ölçəkləmə zamanı məhsullar üçün zəif dizayn edilmiş arxitektura tələb olunur ki, bu da çox güman ki, uğursuzluğa gətirib çıxarır, çünki müştərilər siz sistemi miqyaslandırarkən gözləməyəcək, onlar rəqib seçəcəklər, ona görə də biz potensial miqyasda öndə olmalıyıq. Etiraf etsəm də, bəzən bu, yalın bir yanaşma ola bilməz, ideya miqyaslana bilən, lakin artıq miqyaslı olmayan bir sistemə sahib olmaqdır. Digər tərəfdən, heç bir müştərisi olmayan və ya onların çoxunu əldə etməyi planlaşdırmayan çox mürəkkəb və artıq miqyaslı bir sistemə sahib olmaq, işinizdə heç bir əvəzə pul bahasına başa gələcək.

Texnologiya yığını seçimi

Texnologiya yığınının seçilməsi həm də makro səviyyəli bir qərardır, çünki bu, işə qəbula, sistemin təbii təkamül perspektivlərinə, miqyaslılığa və sistemin performansına təsir göstərir.

Bu, texnologiya yığını seçərkən əsas mülahizələrin siyahısıdır:

Layihə tələbləri və mürəkkəbliyi. Məsələn, Blazor çərçivəsi ilə sadə bir veb tətbiqi tərtib edilə bilər, əgər tərtibatçılarınız onunla təcrübəyə malikdirlərsə, lakin WebAssembly-in yetkin olmaması səbəbindən uzunmüddətli uğur üçün React və Typescript-i seçmək daha yaxşı qərar ola bilər.
Ölçeklenebilirlik və Performans Ehtiyacları. Böyük miqdarda trafik alacağınızı düşünürsünüzsə, Django üzərindən ASP.NET Core-a üstünlük vermək onun paralel sorğuların idarə edilməsində üstün performansına görə müdrik seçim ola bilər. Bununla belə, bu qərar gözlədiyiniz trafikin miqyasından asılıdır. Potensial olaraq milyardlarla sorğunu aşağı gecikmə ilə idarə etmək lazımdırsa, Zibil Kolleksiyasının olması çətin ola bilər.
İşə götürmə, inkişaf vaxtı və qiymət. Əksər hallarda diqqət etməli olduğumuz amillər bunlardır. Bazara çıxma vaxtı, Baxım xərcləri və İşə qəbulun sabitliyi biznes ehtiyaclarınızı maneəsiz idarə edir.
Komanda Ekspertizası və Resursları. İnkişaf komandanızın bacarıq dəsti kritik amildir. Yeni bir yığın öyrənməyə sərmayə qoymaq üçün güclü səbəb olmadıqda, komandanızın artıq tanış olduğu texnologiyalardan istifadə etmək ümumiyyətlə daha effektivdir.
Yetkinlik. Güclü icma və zəngin kitabxana və alətlər ekosistemi inkişaf prosesini xeyli asanlaşdıra bilər. Populyar texnologiyalar çox vaxt daha yaxşı icma dəstəyinə malikdir və bu, problemlərin həlli və resursların tapılması üçün əvəzolunmaz ola bilər. Beləliklə, siz resurslara qənaət edə və əsas diqqətinizi məhsula yönəldə bilərsiniz.
Uzunmüddətli Baxım və Dəstək. Texnologiyanın uzunmüddətli həyat qabiliyyətini nəzərdən keçirin. Geniş şəkildə qəbul edilən və dəstəklənən texnologiyaların köhnəlmə ehtimalı azdır və ümumiyyətlə müntəzəm yeniləmələr və təkmilləşdirmələr alır.

Çoxsaylı texnologiya yığınlarının olması biznesin böyüməsinə necə təsir edə bilər?

Bir nöqteyi-nəzərdən, daha bir yığının təqdim edilməsi işə qəbulunuzu genişləndirə bilər, lakin digər tərəfdən, hər iki yığını dəstəkləməlisiniz, çünki bu, əlavə texniki xidmət xərcləri gətirir. Beləliklə, daha əvvəl dediyim kimi, mənim fikrimcə, yalnız əlavə ehtiyac daha çox texnologiya yığınının daxil edilməsi üçün bir arqument olmalıdır.

Bəs konkret problem üçün ən yaxşı aləti seçmək prinsipi nədir?

Bəzən yuxarıda qeyd olunan eyni mülahizələrə əsaslanaraq müəyyən bir problemi həll etmək üçün yeni alətlər gətirməkdən başqa seçiminiz olmur, belə hallarda ən yaxşı həll yolunu seçmək məna kəsb edir.

Müəyyən bir texnologiya ilə yüksək əlaqə olmadan sistemlərin yaradılması çətin ola bilər. Bununla belə, sistemin texnologiya ilə sıx bağlı olmadığı bir vəziyyətə can atmaq faydalıdır və sabah müəyyən bir çərçivə və ya alət həssas olarsa və ya hətta köhnəlsə, ölməyəcək.

Başqa bir vacib məsələ açıq mənbə və xüsusi proqram təminatından asılılıqlarla bağlıdır. Mülkiyyət proqram təminatı sizə daha az çeviklik və fərdiləşdirmə imkanı verir. Yenə də ən təhlükəli amil, satıcının məhsullarından, qiymətlərindən, şərtlərindən və yol xəritəsindən asılı olduğunuz satıcı kilididir. Satıcı istiqaməti dəyişərsə, qiymətləri artırarsa və ya məhsulu dayandırarsa, bu riskli ola bilər. Açıq mənbəli proqram təminatı bu riski azaldır, çünki tək qurum ona nəzarət etmir. Bütün səviyyələrdə bir uğursuzluq nöqtəsinin aradan qaldırılması inkişaf üçün etibarlı sistemlərin qurulmasının açarıdır.

Tək uğursuzluq nöqtəsi (SPOF)

Tək uğursuzluq nöqtəsi (SPOF) sistemin hər hansı bir hissəsinə aiddir, əgər uğursuz olarsa, bütün sistemin fəaliyyətini dayandıracaqdır. Bütün səviyyələrdə SPOF-ların aradan qaldırılması yüksək əlçatanlıq tələb edən istənilən sistem üçün çox vacibdir. Bilik, kadr, sistem komponentləri, bulud provayderləri və internet kabelləri daxil olmaqla hər şey uğursuz ola bilər.

Tək uğursuzluq nöqtələrini aradan qaldırmaq üçün tətbiq edə biləcəyimiz bir neçə əsas texnika var:

Artıqlıq. Kritik komponentlər üçün artıqlığı həyata keçirin. Bu, əsas komponent uğursuz olarsa, ehtiyat nüsxə komponentlərinin olması deməkdir. Artıqlıq sistemin müxtəlif təbəqələrində, o cümlədən aparat (serverlər, disklər), şəbəkə (linklər, açarlar) və proqram təminatı (verilənlər bazaları, proqram serverləri) üzrə tətbiq oluna bilər. Hər şeyi bir Bulud Provayderində yerləşdirirsinizsə və hətta orada ehtiyat nüsxələriniz varsa, fəlakət zamanı itirilmiş xərclərinizi azaltmaq üçün digərində müntəzəm əlavə ehtiyat nüsxəsini yaratmağı düşünün.
Məlumat Mərkəzləri. Sisteminizi məlumat mərkəzləri və ya bulud bölgələri kimi bir çox fiziki məkanda paylayın. Bu yanaşma sisteminizi elektrik kəsilməsi və ya təbii fəlakətlər kimi məkana xas nasazlıqlardan qoruyur.
Failover. Bütün komponentləriniz (DNS, CDN, Yük balanslaşdırıcıları, Kubernetes, API Şlüzləri və Verilənlər Bazaları) üçün əvəzetmə yanaşmasını tətbiq edin. Problemlər gözlənilmədən yarana bildiyindən, istənilən komponenti tez bir zamanda onun klonu ilə əvəz etmək üçün ehtiyat planın olması çox vacibdir.
Yüksək əlçatanlıq xidmətləri. Aşağıdakı prinsiplərə riayət etməklə xidmətlərinizin başlanğıcdan üfüqi şəkildə miqyaslana bilən və yüksək səviyyədə əlçatan olması üçün qurulduğundan əmin olun:
- Xidmətin vətəndaşlığı olmadan təcrübə edin və istifadəçi seanslarını yaddaşdaxili keşlərdə saxlamaqdan çəkinin. Bunun əvəzinə Redis kimi paylanmış keş sistemindən istifadə edin.
- Məntiqi inkişaf etdirərkən mesaj istehlakının xronoloji ardıcıllığına etibar etməkdən çəkinin.
- API istehlakçılarını pozmamaq üçün dəyişiklikləri minimuma endirin. Mümkünsə, geriyə uyğun dəyişiklikləri seçin. Həmçinin, dəyəri nəzərə alın, çünki bəzən fasiləsiz dəyişikliyin həyata keçirilməsi daha sərfəli ola bilər.
- Miqrasiya icrasını yerləşdirmə boru kəmərinə daxil edin.
- Paralel sorğuların idarə edilməsi üçün strategiya qurun.
- Etibarlılığı və müşahidə qabiliyyətini artırmaq üçün xidmət kəşfini, monitorinqini və qeydini həyata keçirin.
- Şəbəkə uğursuzluqlarının qaçılmaz olduğunu etiraf edərək, qeyri-müəyyən olmaq üçün biznes məntiqini inkişaf etdirin.
Asılılığın nəzərdən keçirilməsi. Xarici asılılıqları mütəmadi olaraq nəzərdən keçirin və minimuma endirin. Hər bir xarici asılılıq potensial SPOF-ları təqdim edə bilər, ona görə də bu riskləri anlamaq və azaltmaq vacibdir.
Daimi bilik mübadiləsi. Təşkilatınız daxilində biliyin yayılmasının vacibliyini heç vaxt unutmayın. İnsanlar gözlənilməz ola bilər və tək bir şəxsə güvənmək risklidir. Komanda üzvlərini sənədlər vasitəsilə biliklərini rəqəmsallaşdırmağa təşviq edin. Bununla belə, həddindən artıq sənədləşdirməyə diqqət yetirin. Bu prosesi asanlaşdırmaq üçün müxtəlif AI vasitələrindən istifadə edin.