MVP-dən prodakşna: startaplara ən baha başa gələn 5 arxitektura qərarı

Minimal işlək məhsulun (MVP) əsas məqsədi hipotezi yoxlamaqdır. Tapşırıq sürətlə qurmaq, tez yerləşdirmək və bazarı sınaqdan keçirməkdir. Lakin MVP-ni işə salmaq üçün tələb olunan sürət çox vaxt ciddi texniki borc yaradır.

Orta hesabla bir tərtibatçı həftədə 17 saatdan çox vaxtını texniki xidmət və dəstək problemlərinin həllinə sərf edir — Stripe Developer Coefficient, 2018.

Məqbul texniki borcla struktur qüsurları arasında fərq var. Bəzi arxitektura qərarları MVP mərhələsində əhəmiyyətsiz görünür, lakin məhsul böyüdükcə darboğaza çevrilir.

Tələ: «Miqyaslananda düzəldərik»

«Miqyaslananda düzəldərik» ifadəsi proqram təminatının tərtibatında ən baha başa gələn fərziyyədir. İstifadəçi sayı 100-dən 10,000-ə çatdıqda struktur arxitekturasını düzəltmək sadə refaktorinq tapşırığı deyil. Bu, canlı sistemi işlək vəziyyətdə saxlayaraq təməli yenidən qurmaq üçün yeni funksiyaların tərtibatını tamamilə dayandırmağı tələb edir.

Qərar 1: verilənlər bazası sxeminin layihələndirilməsi

MVP tərtibatında çox vaxt gələcək müraciət şablonları nəzərə alınmadan sxemsiz NoSQL verilənlər bazalarından istifadə edilir və ya həddindən artıq normallaşdırılmış relyasiyalı verilənlər bazaları qurulur.

Bədəli: Məlumat həcmi artdıqca optimallaşdırılmamış cədvəllər üzrə mürəkkəb sorğular ciddi gecikmələrə səbəb olur. Əgər relyasiyalı sxem əvvəlcədən yanlış layihələndirilibsə, milyonlarla sətri dayanma olmadan yeni sxemə köçürmək son dərəcə mürəkkəbdir və xəta ehtimalı yüksəkdir.

Həlli: Verilənlər bazasını məlumatların təkcə necə saxlanacağına görə deyil, həm də necə sorğulanacağına görə seçin. Əgər məlumatlarınız sıx əlaqəlidirsə, standart olaraq PostgreSQL seçin. Verilənlər bazası miqrasiyalarını ilk gündən ciddi şəkildə sənədləşdirin.

Qərar 2: autentifikasiya arxitekturası

Təsisçilər çox vaxt SSO, MFA və ya OAuth-u sonradan əlavə edəcəklərini düşünərək sıfırdan yazılmış sadə e-poçt/şifrə autentifikasiyasına üstünlük verirlər.

Bu imkanları sonradan əlavə etmək real istifadəçiləri olan canlı sistemdə istifadəçi qeydlərini, sessiya tokenlərini və onları yoxlayan hər bir marşrutu yenidən işləmək deməkdir.

Həlli: Heç vaxt autentifikasiyanı sıfırdan özünüz yazmayın. İdentifikasiya idarəetməsini dərhal özünü doğrultmuş provayderlərə (Auth0, Firebase Auth, AWS Cognito) həvalə edin. Bu, token arxitekturanızı standartlaşdırır və sonradan korporativ SAML əlavə etməyi sadə işə çevirir.

Qərar 3: vəziyyətin idarə olunması və məlumatların sinxronizasiyası

MVP-lərdə çox vaxt sadə, lokal vəziyyət dəyişənlərindən istifadə olunur. Tətbiq böyüyüb oflayn imkanlar, real vaxt funksiyaları və ya mürəkkəb idarəetmə panelləri əlavə olunduqca sadə vəziyyət idarəetməsi sıradan çıxır.

Həlli: İlk üç ekran üçün bir qədər artıq mürəkkəb görünsə belə, strukturlaşdırılmış vəziyyət idarəetmə şablonu (Redux, Riverpod, BLoC) tətbiq edin. Ciddi məlumat axını komponent ağacı genişləndikcə spagetti kodun yaranmasının qarşısını alır.

Qərar 4: API müqavilələrinin layihələndirilməsi

MVP-lərdə frontend və backend çox vaxt bir-birinə sıx bağlı olur: API son nöqtələri yalnız konkret UI ekranlarına xidmət etmək üçün qurulur.

Bədəli: Biznesə veb tətbiqlə yanaşı mobil tətbiq və ya üçüncü tərəf tərəfdaşla inteqrasiya lazım olduqda mövcud API-lər yararsız çıxır. Uyğunluğu pozan dəyişikliklər mövcud müştəri tətbiqlərini sıradan çıxaracaq.

Həlli: Əvvəldən RESTful standartlarına və ya GraphQL-ə ciddi riayət edin. İlk buraxılışdan etibarən API-lərinizi versiyalaşdırın (məsələn, /api/v1/users). API-ni konkret ekranlar üçün məlumat paketləri deyil, resurslar təqdim edəcək şəkildə layihələndirin.

Qərar 5: yerləşdirmə konveyeri

Startaplar çox vaxt MVP-ləri əllə yerləşdirir — kodu çəkmək üçün serverə SSH vasitəsilə daxil olurlar. Bu, bir nəfərlik komanda üçün işləyir. Komanda üç tərtibatçıya çatdıqda əllə yerləşdirmə kodun üzərinə yazılmasına və prodakşnda dayanmalara gətirib çıxarır.

Həlli: Funksional kodu yazmazdan əvvəl baza CI/CD konveyeri (GitHub Actions) qurun. Avtomatlaşdırılmış testləri işə salan və aralıq test serverinə yerləşdirən sadə skript yerləşdirmə prosesinin təkrarlana bilən, avtomatlaşdırılmış və təhlükəsiz olmasını təmin edir.

Sistemi həddindən artıq mürəkkəbləşdirmədən necə qərar verməli

Bu beş tələdən yayınmaq MVP üçün korporativ mikrosxidmət arxitekturası qurmaq demək deyil. İdarə olunan verilənlər bazasından istifadə edin, üçüncü tərəf autentifikasiya provayderini inteqrasiya edin, API müqavilələrini aydın müəyyənləşdirin, vəziyyətin idarə olunmasını standartlaşdırın və yerləşdirməni avtomatlaşdırın. Bu beş qərar sonradan atmalı olacağınız prototip deyil, miqyaslandıra biləcəyiniz təməl yaradır.