Declarative approach နဲ့သွားတာကလူနားလည်တယ်ဆိုပေမဲ့ တချို့နေရာတွေမှာ DIY မဖြစ်တာတွေရှိတယ်။ ဆိုပါစို့ကိုယ်က Full fledged Framework လိုမဟုတ်ဘဲနဲ့ Utility လေးတွေပေးထားတဲ့ကောင်တွေသုံးတာမျိုးဆိုပိုသိသာတယ်။ ဥပမာကိုယ်က Laravel သုံးတယ်ဆိုရင် Laravel ကပေးထားတဲ့ API design အတိုင်းသွားရမှာ၊ ဘာလို့ဆိုသူက "ဒီလိုရေးမှဒီလိုဖြစ်မယ်" ဆိုတဲ့ပုံစံမျိုးနဲ့သွားကြရလို့။ သဘောတရားက တစ်နေရာရာမှာ Rely လုပ်နေတာမျိုးကိုပြောချင်တာ။
Backend မှာအဓိကပြဿနာတက်တာက Code ကလှသင့်သလောက်မလှတာမျိုး။ Middleware တွေရေးတဲ့နေရာတွေမှာအဓိကဖြစ်တာ။ Middleware တွေက Low level အနေနဲ့သွားရင် Validation လိူကိစ္စတွေက Declarative ဆန်ဆန်သွားလို့ရတယ်။ ဒါပေမဲ့ အဲ့လိုလုပ်လို့ရမဲ့ Facade တွေပါမလာဘူး။
Request မလာခင်မှာ Middleware Stack သွားစီမှရမှာ။ အဲလိုမျိုးတွေက Declarative မဖြစ်ဘူး။ ဒါကြီးကဘာကြီးလဲပေါ့။ ဒီလိုကောင်မျိုးကို Cover ဖြစ်ဖို့ Naming Convention လိုကောင်တွေနဲ့ Cover ကြပေမဲ့ အမြဲတမ်း Nonsense ဖြစ်တယ်။
ဒီလိုကောင်တွေကိုကိုယ့်ဘာသာကိုယ်ရအောင် cover ထားသင့်တယ်။ ဒီ့အတွက် DRY ကိုတော့လိုက်နာနိုင်မှာမဟုတ်ဘူး။ နည်းနည်းတော့ Duplicated ဖြစ်တာပေါ့။ ဒါက Trade off သက်သက်ပါ။ ဟိုဘက်မှာ Human Readable ဖြစ်သွားမယ်။ DX ပိုကောင်းမယ်။
အစကတည်းက Code တွေကလူနားလည်တာမျိုးပဲဖြစ်ရမှာ။ Machine နားလည်ဖို့ဆိုပြီးတွေးတာမျိုးကမှားတယ်။ Machine နားလည်စေချင်ရင် Switch နဲ့သွားပေါ့။ ဒီ့ထက်ကောင်းတာမရှိဘူး။Programming Principal တွေကိုလိုက်နာတယ်ဆိုတဲ့နေရာမှာ Domain Knowledge လည်းရှိဖို့လိုသေးတယ်။ ဒါကြီးကိုပဲအမြဲသုံးနေရမယ်ဆိုတာမျိုးမဟုတ်ဘူး။ ဒါပဲသုံးရမယ်တာမျိုးတွေးရင် သွားပြီပဲ။
Top comments (0)