Karate Vs Software Engineering
Karate မှာ kihon, kata နဲ့ kumite ဆိုတာရှိတယ်။
Kihon ဆိုတာသည် basic ဖြစ်တယ် မတ်တပ်ရပ်တဲ့ပုံစံ ထိုင်တဲ့ပုံစံ ထိုးပုံထိုးနည်း ကန်ပုံကန်နည်း ဒါတွေကို လေ့လာရတယ်။ နောက်တစ်ခါ kata ဆိုတာကတော့ ကာရာတေးရဲ့ အနှစ်သာရ form ဖြစ်တယ်။ Kata ကစားတဲ့နေရာမှာ တစ်ကယ့်တိုက်ပွဲအတွင်းမှာ တိုက်ခိုက်သလို အတက် အဆင်း ထိုးကွက် ပယ်ကွက် သူ့စနစ်အတိုင်း အချိတ်အဆက်မိမိ ကစားရတယ်။ Kihon မတတ်ပဲ kata သွားဆော့လို့မရဘူး။ Kata ကိုအလှကွက်ပြရုံလောက် ဆော့တတ်ရုံနဲ့လည်း မရပြန်ဘူး။ တစ်ကယ့် ground မှာ ထိုးသတ်ဖို့ kumite ကိုလေ့ကျင့်ရတယ်။ Kumite မှာမှ ခုနက kata ရဲ့ bunkai တွေကိုသုံးပြီးတိုက်တာနဲ့ သမားရိုးကျတိုက်တာ ဆိုပြီး နှစ်မျိုးပြန်ကွဲသေးတယ်။ ထားတော့။ ပြောချင်တာ ကာရာတေးအကြောင်းမဟုတ်ဘူး။
Software engineering မှာလည်း kihon, kata, kumite ဆိုပြီး သုံးပိုင်းသွားတွေ့ရတယ်။ Kihon ဆိုတာကတော့ data modeling အပိုင်းဖြစ်တယ်။ Data modeling ဆိုတာမှာ OO pattern တွေသုံးပြီး model လုပ်တာ data structure တွေသုံးပြီး model လုပ်တာ အကုန်ပါတယ်။ ဘာ business logic မှမရှိသေးခင် ကိုယ့်ရဲ့ system ကို ဘယ်လို model တွေနဲ့တည်ဆောက်မလဲ ဘယ်လို structure ချမလဲဆိုတာကို အရင်မလုပ်နိုင်ရင် ဘာမှရှေ့ဆက်လို့မရဘူး။ Kata ကတော့ problem solving ဖြစ်တယ်။ ခုနက date model ကိုအသုံးပြုပြီး business objectives တွေကို ဘယ်လို satisify ဖြစ်အောင်လုပ်မလဲ ဘယ်လို algorithm နဲ့သင်တော်မလဲ ဒါသည် ဒုတိယအဆင့် ပြောရရင် leet code problem တွေသည် kata မှာ သွားအကြုံးဝင်တယ်။ ဆိုတော့ ရှေ့ကပြောသလို data model ကောင်းကောင်းမဆောက်နိုင်ရင် algorithm/architecture ဘယ်လောက်ကောင်းကောင်း မကယ်နိုင်ဘူး။
ဟုတ်ပြီ model လည်းကောင်းကောင်း design ချနိုင်ပြီ ဘယ်လို problem solve လုပ်ရမလဲဆိုတာလည်းရပြီ engineer ဖြစ်ပြီလားဆိုတော့ မဖြစ်သေးပြန်ဘူး တစ်ကယ် development လုပ်ဖို့ရာ လိုအပ်တဲ့ development knowledge, tooling, library or framework knowledge လိုသေးတယ်။ ဆိုတော့ ခုနက ရှေ့ကပြောခဲ့တဲ့ data modeling, data manipulation လိုကောင်မျိုးတွေအကုန်ရပြီး tooling တွေ framework တွေမသုံးတတ်ပြန်ရင်လည်း အလုပ်ရမှာမဟုတ်ဘူး။ ဆိုတော့ သုံးခုလုံး သူ့ဟာနဲသူ သမမျှတရမယ်။ ကုမ္ပဏီအင်တာဗျူးတွေမှာ kihon နဲ့ kata သဖွယ်ဖြစ်တဲ့ modeling, manipulation, problem solving လိုကောင်မျိုးကိုမေးတယ်။ ထိုးကွက် ကန်ကွက် ဘယ်လိုရှိတယ် အတက်အဆင်း အရှောင်အတိမ်း ဘယ်လိုရှောင်ရတိမ်းရမယ်ဆိုတာသိရင် တစ်ကယ် မြေပြင်မှာ ထိုးဖို့သတ်ဖို့ သင်ရလွယ်သလိုပဲ။ ရှေ့က software engineering နဲ့ပတ်သက်တဲ့ သိသင့်သိထိုက်တဲ့ practises တွေကို ကျေကျေလည်လည်သိထားရင် လက်ရှိကိုယ့်ရုံးကသုံးနေတဲ့ framework/tool ကိုမသိရင်တောင် သင်ဖို့မခက်ဘူးလို့ ယူဆလို့။ ဒါပေမယ့် similar frameowrk လိုကောင်မျိုးတွေကိုပါ မသုံးဖူးဘူးဆိုရင်လည်း အဆင်မပြေပြန်ဘူး။
အခုတလော အမေးများကြလို့ ဘယ်အပိုင်းဂရုစိုက်ကမလည်း မသိရင် အပေါ်ကစာပြန်ဖတ်ကြပါကုန် ဘယ်လိုဖြစ်ဖြစ် သုံးခုစလုံးတော့ ဟန်ချက်ညီဖို့လိုပါတယ်။
Data modeling နဲ့ ပတ်သက်လို့ပြောရရင် အခုမှစလုပ်တဲ့သူတွေက OOP ဆို အထူးအဆန်းကြီး ထင်ကြတယ်။ ပြောရရင် OO Design Pattern တွေဆိုတာ မသိလိုက်ပဲ သုံးဖြစ်နေကြတဲ့အရာတွေဖြစ်တယ် obj ကို initializer နဲ့မဆောက်ချင်ဘူး factory တွေရေးမိသွားတာပဲ တစ်ခါတလေ abstract factory တွေဖြစ်ရင်ဖြစ်မယ် share state လိုချင်တယ် singleton တွေရေးမိသွားတယ် class ကိုမပြင်ပဲ code အသစ်ထပ်ထည့်ချင်တယ် visitor class တွေရေးကြတယ် behaviour မတူတဲ့ obj နှစ်ခုကို ချိတ်သုံးချင်တယ် adapter တွေရေးကြတယ် obj တစ်ခုရဲ့ action ကို နောက် obj က သိချင်တယ် observer တွေရေးတယ် obj ကိုမှ customization တွေလုပ်ပြီး ရှုပ်ရှုပ်ထွေးထွေးတွေလုပ်ချင်တယ် builder တွေရေးကြတယ် event တွေနဲ့ event handling logic တွေကို decouple လုပ်ချင်တယ် command pattern ကောက်သုံးလို့ရတယ် service layer မှာ ရှုပ်ရှုပ်ထွေးထွေးရေးထားတယ် ယူသုံးမယ့် app layer ဘက်က လွယ်ချင်ရင် facade တွေရေးလိုက်လို့ရတယ် ဒါမှမဟုတ် proxy လည်းသုံးလို့ရတယ်
အခုရွတ်ပြတာ ကျွန်တော် ပုံမှန်ရေးနေကျ code အမျိုးအစားတွေကို oo pattern ခေါင်းစဉ်အောက်ကိုဆွဲသွင်းပြတာ ဒီအတိုင်း သတိမထားမိပဲသုံးနေကြတာ အများကြီး ဆိုတော့ OO Design Pattern ဆိုတာ ကြောက်စရာမဟုတ်ဘူး ကိုယ်ရေးနေတဲ့ code ကိုပဲ ဝိဂြိုလ်ပြုလိုက်တာသာဖြစ်တယ်။
