Flutter Dev Talk

#ARCH-2 Over-engineering, YAGNI & KISS tushunchalari

Arxitekturaning maqsadi ko'p layer qo'shish emas balki o'zgarishlarni cost'ni boshqarish dedik.

Buyerda ikkita extrimum bor:


Under-engineering                 Over-engineering

hamma logic                         har narsaga
bitta joyda                         abstraction
     │                                  │
     └─────────── BALANCE ──────────────┘
             kerakli darajada
               architecture

Maqsad hozirgi requirementlarga mos sodda yechim qilish va shu bilan birgalikda keyingi o'zgarishlarga ham yo'l ochib qo'yish kerak.

2.1: YAGNI - You Aren't Gonna Need It.


Requirement:
Hozir bizda faqat Paynet bilan to'lov qilinadi.

Lekin biz buning keyinchalik qo'shilishi mumkin deb quyidagicha yozishimiz mumkin :


abstract interface class PaymentStrategy {
  Future<void> pay();
}

class PaynetStrategy implements PaymentStrategy {}
class ClickStrategy implements PaymentStrategy {}
class PaymeStrategy implements PaymentStrategy {}

Biz hali bilmagan flowlar uchun taxminan ko'd yozdik.

YAGNI esa shunday deydi:
Hozir kerak bo‘lmagan capability’ni faqat kelajakda balki kerak bo‘lishi mumkinligi uchun yaratma.

2.2: KISS - Keep It Simple.
Tepadagi requirement bo'yicha davom etsak:


class PaymentStrategy {
   final PaymentApi api;

   PaymentStrategy(this.api);

   Future<void> create() {
 /// Payment amalga oshirilmoqda 
    }

   Future<void> confirm() {
 /// Payment amalga oshirilmoqda 
    }

   Future<void> payment() {
 /// Payment amalga oshirilmoqda 
    }
}

va bu yerda

Bu yerda usecase yoki repository ishlatmaslik bu ko'dni yomon qilmaydi. Lekin keyinchalik buyerga boshqa to'lov providerlari qo'shilsa va ular har xil flowlarga ega bo'lsa ko'd if/else dan iborat bo'lib qoladi.


if (type == paynet) {
  // create
  // confirm
  // payment
} else if (type == click) {
  // amount check
  // confirm
  // payment
} else if (type == payme) {
  // confirm
  // create
  // extra validation
  // payment
}

Endi bu yerda KISS-ku hammasini bir joyda saqlashimiz kerak deyish xato. Real complexity paydo bo'lganda abstractionni ishlatishga sabab paydo bo'ladi.


abstract interface class PaymentFlow {
  Future<void> execute(PaymentRequest request);
}

class PaynetFlow implements PaymentFlow { ... }

class ClickFlow implements PaymentFlow { ... }

class PaymeFlow implements PaymentFlow { ... }

Bu abstraction kelajakdgi taxminlarga emas balki mavjud ko'dni boshqarish uchun yozildi.

2.3: Preparatory refacoring
2.2-qismdagi refactoringni birdaniga amalga oshirish risk xisoblanadi. Shuning uchun avval mavud flowni refacoring qilamiz va uni testlaymiz. Test yiqilsa demak refactoringda xatolik bo'ladi. Testlardan o'tgach qo'shimcha qismlarni ham qo'shamiz va testlaymiz, agar test yiqilsa qo'shimcha kiritilgan qismdan xatolikni izlaymiz.
Refactor qilish uchun qonunyat shunday desak bo'ladi(lekin qat'iy emas):


1-qadam → implement qiling

2-qadam → similarity'ni kuzating

3-qadam → pattern aniq bo‘lsa abstraction haqida o‘ylang

Xulosa:

Aniq responsibilityga ega bo'lmagan layerlarni ko'paytirish - over-engineeringga, ularni bir joyga jamlash esa under-engineering hisoblanadi. Senior vazifasi shu ikki tomonni balanslash.


Architecture decision = current complexity + change probability + cost of failure

@flutterDevTalk

👍1🔥1

125 viewsedited 05:22