28/03/2023
Project တွေ development လုပ်ရင်ပဲဖြစ်ဖြစ်၊ နည်းပညာအသစ်တစ်ခုကို စလေ့လာမှာ၊ သုံးမှာပဲဖြစ်ဖြစ် အဓိက အကျဆုံး သော့ချက်တစ်ခုက ပြဿနာ (သို့) Business ဘက်ကနေ ရှုမြင်ပြီး အဲ့ဒီ ပြဿနာကို အစိတ်စိတ်အမွှာမွှာ ခွဲခြားမြင်တတ်ဖို့ပါပဲ၊ ဒီကိစ္စတွေကတော့ ဒီ function တွေလုပ်ရမှာ၊ ဒီဟာတွေကတော့ နောက် function တစ်ခုထပ်ခွဲရလိမ့်မယ်ဆိုပြီးတော့ပေါ့ဗျာ …
ဥပမာ ကျနော်က ကိုယ်မလုပ်ဖူးသေးတဲ့ frontend နည်းပညာတစ်ခုကို စလေ့လာတော့မယ်ထားပါတော့၊ ဒါဆိုရင် developer တစ်ယောက်အနေနဲ့ app တစ်ခုကို ကောင်းကောင်းထိန်းချုပ်ဖို့ လုပ်ရမဲ့ root category တွေ ပြဿနာတွေကို ခွဲပြီးသတ်မှတ်ရပါတော့မယ်၊ အဲ့လို ပြဿနာကို ခွဲခြမ်းစိတ်ဖျာပြီး မလေ့လာဘူးဆိုရင် google က တွေ့သမျှ Blog တွေ၊ Youtube က Tutorial တွေ တစ်ခုပြီး တစ်ခုလုပ်ပြီး ဘာတစ်ခုမှ ကိုယ့်အိတ်ထဲရောက်မလာပဲ ရွာလည်နေပါလိမ့်မယ်၊
ပြီးတော့ ငါရေးတာတွေက ဟုတ်ရောဟုတ်ရဲ့လားဆိုတဲ့အတွေးတွေ တွေးမိနေပါလိမ့်မယ်၊ ပြဿနာတွေကို ပိုင်ပိုင်နိုင်နိုင် မခွဲခြမ်းနိုင်သရွေ့ project တွေ ဘယ်နှစ်ခုပဲ copy paste လုပ်ပြီး ပြီးသွားပြီးသွား ၊ ငါရေးတာတွေ ဟုတ်ရောဟုတ်ရဲ့လားဆိုတဲ့မေးခွန်းကနောက်ကလိုက်နေအုံးမှာပါ၊
ဟုတ်ပြီ အဲ့တော့ ကျနော်တို့ စလေ့လာမယ်ဆို ဘယ်လိုခွဲမလဲ - အကြမ်းဖျဥ်းခွဲရမယ်ဆိုရင်
Api တွေကို fetch လုပ်ဖို့အတွက် Api call management ရှိမယ်ဗျာ
အဲ့ဒီ api ကနေထွက်လာမဲ့ response တွေအပြင် error တွေကို Handling လုပ်တဲ့အပိုင်း ရှိမယ်ဗျာ(ထပ်ခွဲရင် ဘယ် error က project တစ်ခုလုံးနဲ့ သက်ဆိုင်တာလဲ၊ ဘယ် error က api တစ်ခုချင်းစီနဲ့ သက်ဆိုင်တာလဲဆိုပြီးထပ်ရှိတာပေါ့၊ အသေးစိတ်ခွဲနိုင်လေ၊ ပြန်ခြုံ့ပြီး စဥ်းစားနိုင်လေ ပိုစနစ်ကျတဲ့ project structure တစ်ခုထွက်လေပါပဲ)
ပြီးသွားရင် route management တွေရှိမယ်ဗျာ
ပြီးသွားရင် state management တွေဘယ်လိုလုပ်လဲဆိုတာတွေရှိမယ်ပေါ့ဗျာ၊ … ဒါတွေက ခေတ်သစ် frontend development မှာ အမြဲလို ပါလေ့ရှိတဲ့အရာတွေပါပဲ၊ etc …. ဒီလိုမျိုး အပိုင်းလိုက် အကန့်လိုက်ခွဲပြီး tutorial တွေလိုက်ကြည့် သူများခွက်ထဲကဟာတွေကို ကိုယ်စနစ်တကျ ပုံစံချထားတဲ့ ခွက်ထဲထည့်နိုင်ပါမှ ကိုယ်ရေးတဲ့ code တွေအပေါ် ကိုယ့်ဖာကိုယ်ယုံကြည်မှုရှိပြီး မဝေဝါးတော့မှာပါ၊
စလေ့လာတဲ့အချိန်ကနေ လေ့ကျင့်လာတဲ့ ပြဿနာတွေကို ခွဲခြမ်းစိတ်ဖြာတတ်တဲ့အလေ့အကျင့်က project တွေရေးတဲ့အခါမှာလည်း modularize structure တွေဖြစ်အောင် တည်ဆောက်တတ်သွားပါလိမ့်မယ်၊
ဒီကိစ္စတွေကတော့ လုပ်ရမဲ့ project ရဲ့ feature module တွေဖြစ်တယ်၊
ဒီဟာတွေကတော့ App နဲ့သက်ဆိုင်တဲ့ core module တွေဖြစ်တယ်၊
ဒီဟာတွေကတော့ config နဲ့ဆိုင်တဲ့ အပိုင်းတွေဖြစ်တယ်၊
ဒီဟာတွေကတော့ data နဲ့ function တွေနဲ့ ချိတ်ဆက်မဲ့ model တွေဖြစ်တယ်၊
ဒီဟာတွေကတော့ api ခေါ်ဖို့သက်ဆိုင်တာတွေ၊ api error handle လုပ်ဖို့သက်ဆိုင်တာတွေဆိုပြီးတော့ ဖြစ်ပါတယ်၊
Project development လုပ်တဲ့အခါမှာ ကျနော်တို့တွေ ခနခနလုပ်လေ့ရှိတာက ပြဿနာဘက်ကနေရှင်းဖို့မကြိုးစားပဲ code ဘက်ကနေပဲ မြင်ပြီး ၊ code ကနေပဲရှင်းနေတာပါ၊
ဥပမာ - ဟိုးအရင်က Java နဲ့ရေးရင် တစ်နေရာက ဒေတာအပြောင်းအလဲကို တစ်နေရာကချက်ချင်း update သိဖို့ override တွေ implement တွေ တသီကြီးရေးရပါတယ်၊ အဲ့ဒီကနေမှ android native ဖက်မှာ ပြဿနာဘက်ကနေမြင်လိုက်တဲ့အခါမှာ၊ View Model ဆိုတဲ့ Pattern ဖြစ်လာပါတယ်၊ Dart တို့ Flutter တို့လို Modernize ဖြစ်တဲ့ language တွေမှာတော့ Stream ဆိုပြီး ဖြစ်လာတယ်ပေါ့ဗျာ၊ code only အမြင်ဘက်ကနေ လိုအပ်ချက်ပြသနာကိုလိုက်ပြီး တဖြည်းဖြည်းနဲ့ ဘာ package တွေ, pattern တွေက ကိုယ်နဲ့သင့်တော်လဲဆိုတာ လည်းရှာတတ်လာတာပေါ့ဗျာ၊
နောက်ထပ်ဥပမာတစ်ခုက android native မှာ screen တစ်ခုနဲ့ တစ်ခုကြား pass လုပ်ဖို့၊ Intent တွေ Bundle တွေကနေ စပြီး သုံးခဲ့ရတယ်ပေါ့၊ flutter ဘက်ရောက်တဲ့အချိန်မှာလည်း route ကနေ ဘယ်လိုပုံစံ argument တွေထည့်ပေးမလဲဆိုတဲ့ ကိစ္စက လိုက်ရှုပ်တုန်းပေါ့၊
တကယ်တော့ ဒီပြဿနာရဲ့ key point က တစ်ဖက်ကပေးချင်တဲ့ data ကို တစ်နေရာမှာ ခနသိမ်းထားပြီး တစ်နေရာကနေယူလိုက်ရင်ရပြီမဟုတ်လား၊ဒီလို data မျိုးက stream နဲ့ watch လုပ်စရာလဲမလိုဘူးလေ၊ အဲ့ဒီတော့ ကျနော်တို့က လည်ရင်လည်သလို တခြား temporary storage ထဲမှာ သိမ်းထားလို့လည်းရတာပဲလေ၊ screen တစ်ခုနဲ့တစ်ခုကူးရင် ဒီလို data pass လုပ်ပါလို့ documentation ထဲမပါပေမဲ့ ကျနော်တို့က ပြဿနာကိုရှုမြင်တတ်ရင် ကျနော်တို့အတွက် အဆင်ပြေမဲ့နည်းလမ်းမျိုးနဲ့သုံးနိုင်ဖို့အရေးကြီးတာပါပဲ၊ coding ဘက်က အခြေခံသဘောတရားတွေကို အပေါ်စီးကေနနားလည်ဖို့လိုသလို ပြသနာက ဘာလုပ်ချင်တာလဲ ဖြေရှင်းဖို့ ဘာတွေလိုအပ်တာလဲဆိုတဲ့အချက်တွေပါသိထားရင် ကိုယ်ရေးတဲ့ project လည်း timeline save ဖြစ်ပြီး၊ ကိုယ့်ရဲ့ development environment လည်း ပိုကောင်းမွန်လာမှာပဲဖြစ်ပါတယ်။