Review myself

အခုတလော ရုံးအလုပ်တွေနဲ့ တော်တော်ရှုပ်သွားတယ်။ ၁ ပတ်လောက် အိမ်ပြန်နောက်ကျကုန်တယ်။ Dead Line နီးတဲ့ ပြဿနာ အပြင် အရင်က project က error တွေ ပြန်ရှင်းရတာ ၂ ရက် လောက် အချိန်ကုန်သွားသလို ကိုယ့်ကိုယ်ကို လည်း ပြန်သုံးသပ်မိတယ်။ အရင်က ပြဿနာ ဘာလို့ ဖြစ်တာလဲလို့ ပြန်သုံးသပ်ကြည့်လိုက်တော့

၁။ သေချာ ကောင်းမွန်တဲ့ Structure အရင်မချမိခြင်း။
၂။ App Development နဲ့ Web API ကို တပြိုင်တည်း တည်ဆောက်မိခြင်း။
၃။ Class တွေ ခွဲပြီး မတည်ဆောက်မိခြင်း။
၄။ Testing အားနည်းခြင်း။
၅။ ယုံကြည်မှု လွန်ကဲခြင်း။

စတဲ့ အချက်တွေကို တွေ့မိတယ်။

၁။ သေချာ ကောင်းမွန်တဲ့ Structure အရင်မချမိခြင်း။

Project စလုပ်ကတည်းက သေသေချာချာ ဘာတွေ လုပ်ချင်လဲဆိုတာကို မမေးထားမိဘူး။ ဒါတွေ လုပ်ချင်တယ်ဆိုတာကို OK ဖြစ်နိုင်တယ်။ လုပ်မယ် ဆိုပြီး လုပ်ခဲ့မိတယ်။ အဲဒီကတည်းက စမှားနေတာကို တွေ့ရတယ်။ စကတည်းက သူဌေး ဘာလုပ်ချင်လဲဆိုတဲ့ အချက်အလက်တွေကို သေသေချာချာ မတောင်းမိဘူး။ လုပ်နေရင်းနဲ့မှ ဒါလုပ်ချင်ရင် ဒါထည့်။ ဒါဖြစ်ချင်ရင် ထည့်။ ဒီလိုဖြစ်ပေါင်းများနေပြီ။ ဒီအချက်က ကိုယ့်ရဲ့ အားနည်းချက်ဖြစ်နေတာဆိုတာကို အခုတလောမှ ပြန်သုံးသပ်မိတယ်။ အလုပ်လုပ်တဲ့ အခါမှာ လုပ်ရမယ့် အချက်အလက်တွေ သေသေချာချာ မစုစည်းမိတာကိုက ကိုယ့်အမှားဖြစ်နေတာကို တွေ့ရတယ်။

ဖြစ်သင့်တာက အရင်ဆုံး အချက်အလက် ကျကျနန စုစည်းပြီး ဒါတွေ လုပ်မှာ သေချာပြီဆိုမှ ဘယ်လို ပုံစံ လုပ်ရမလဲဆိုတာကို သေသေချာချာ စနစ်တကျ တည်ဆောက်သင့်တယ်။ အခု အလုပ်လုပ်မိနေတဲ့ ပုံစံက လုပ်မယ်ဆိုရင် တစ်ခါတည်း ချလုပ်။ ပြီးမှ ဟိုဖြည့် ဒီဖြည့် ။ နောက်ပြီး ဟိုဟာ ဖြုတ်ဒီဟာဖြုတ် တွေ အရမ်းများလာတယ်။ နောက်ပြီး အြမဲတန်း No ဆိုတဲ့ ဆောင်ပုဒ်ကို မေ့သွားတာလည်း ပါတယ်။

ပုံမှန် အလုပ်လုပ်ကျနေတဲ့ ကျွန်တော့်ပုံစံက အမြဲတန်း No ပဲ။ ဘာပဲ ပြောပြော No ဆိုတာကို အရင်ဆုံး စတယ်။ ပြီးမှ ဘာတွေ ဖြစ်နိုင်မလဲ ဖြစ်သင့်သလဲဆိုတာကို တဆင့်ခြင်း စဉ်းစားတယ်။ သို့ပေမယ့် အခု project မှာ အကုန် Yes မိလိုက်တာ မှားမှန်းမသိ မှားသွားတယ်။ အကုန်လုံးက လုပ်လို့ရနေတာကိုး။ ဒါကြောင့် အကုန် Yes မိလိုက်တာ။

၂။ App Development နဲ့ Web API ကို တပြိုင်တည်း တည်ဆောက်မိခြင်း။

အပေါ်မှာ ကျွန်တော် structure မကျသေးတဲ့ အချိန်မှာ Web API ကို တည်ဆောက်ရင်း တစ်ခါတည်း App Development ပါရေးသွားတယ်။ ဒီတော့ ဘာဖြစ်လဲဆိုတော့ Development process တစ်ခုလုံးက အရမ်းမြန်တာပေါ့။ အရမ်းမြန်ပေမယ့် စနစ်ကျနမှု မရှိဘူးဆိုတာကို သိပေမယ့် ပြဿနာတွေ လာမှပဲ ပြေးတွေ့တော့မယ်လေဆိုပြီး စိတ်ကလေး ထားမိသွားတယ်။ ဒါဟာ အရမ်းမှားယွင်းသွားတဲ့ အချက်ပဲ။ တကယ်တန်းဆိုရင် Web API တစ်ခုလုံးကို စမ်းပြီးတဲ့ အခါမှ App Development ကို စသင့်တယ်။ သို့ပေမယ့်လည်း သူဌေးက ဘာတွေ ပြီးသွားပြီလဲလို့ မေးရင် Web API ကို terminal ကနေ curl ပဲ ခေါ်ပြလို့ရမှာလေ။ သူဌေး အနေနဲ့လည်း မည်းမည်း screen ကြီးမှာ စာ ဖြူဖြူတွေ ပေါ်နေတာက လွဲလို့ တခြားဟာ မသိဘူး။ ဒါကြောင့် တစ်ခါတည်း App Development ကို လုပ်မိသွားတာထင်တယ်။ လုပ်ချင်စိတ်တွေ များသွားပြီးတော့ လုပ်သင့်တာတွေကို ဝေဖန် သုံးသပ်ဖို့ အားနည်းသွားတယ်။ ဒါဟာ အမှားကြီးမှားတာပဲ။

ပုံမှန်အားဖြင့် Web API ကို stable ဖြစ်လောက်မှ သာ App Development ကို စသင့်တယ်။ အခုတော့ အသစ်တစ်ခုလာ ထပ်ဖြည့်။ Web API မှာလည်းပြင် App မှာလည်း ပြင်။ ပြင်လိုက် ရေးလိုက်။ လုံးချာလည် လိုက်နေတာပဲ။ နောက်ဆုံး code တွေက ပွထနေကောပဲ။ တော်သေးတာက code တွေကို ဘာတွေ လုပ်သလဲဆိုတာကို comment တွေ သေသေချာချာ ရေးထားမိလို့ နောက်ပိုင်း ပြန်ပြင်တဲ့ အခါမှာ ဘာရေးထားသလဲဆိုတာကို မှတ်မိတာ။

၃။ Class တွေ ခွဲပြီး မတည်ဆောက်မိခြင်း။

အခုအချိန်မှာ ပြန်စဉ်းစားမိရင် တော်တော် အသုံးမကျတဲ့ ကောင်လို့ ကိုယ့်ကိုယ် ဆဲမိမှာ အသေချာပဲ။ Delegate Method ကို မသိသလို OOP လည်း မတောက်မခေါက် တတ်တဲ့ ကောင်။ သေချာ နားမလည်တဲ့ ကောင်လို့ ပြောမိမှာ သေချာတယ်။ အမှန်တိုင်းဆိုရင် Web API အတွက် သီးသန့် Class ကို ခွဲထုတ်ပြီးတော့ ရေးထားသင့်တယ်။ အခုတော့ program structure ထဲမှာ ရောရေးထားတဲ့ အခါမှာ အခြား အသစ်တွေ ထပ်ဖြည့်တော့ ပြဿနာတွေ တွေ့ကုန်ကော။ ဟိုဖြတ် ဒီထည့်နဲ့ မကြာသင့်တာတွေ ပိုကြာကုန်တယ်။ ဒီအချက်ကို တဖြည်းဖြည်းနဲ့ သဘောပေါက်လာသလို Singleton နဲ့ Delegate တွေကို အခု မှ သုံးသပ်လာတယ်။ တနည်းပြောရင် အတွေ့အကြုံ အားနည်းလို့ ဒီ ပြဿနာ ကြုံရတာပဲ။ Singleton ကို မသိသလို Delegate ကို မကြားဖူးတာဟာ ဒီ ပြဿနာတွေ ဖြစ်လာစေတာပဲ။ အဲဒါတွေကို မသိတော့ program code ထဲမှာ ရောရေးရင်းနဲ့ နောက်ပိုင်း ပြင်ရတဲ့ အခါမှာ ပြဿနာတွေ ရင်ဆိုင်ရတော့တာပဲ။

၄။ Testing အားနည်းခြင်း။

အမှန်တိုင်းဆိုရရင် ကိုယ်ရေးတဲ့ program ကို ကိုယ့်ဘာသာ ကိုယ် test လုပ်ရမှာ အမုန်းဆုံးပဲ။ Error မရှာချင်သလို ရှာရမှာလည်း တော်တော်ပျင်းတယ်။ ဒီအချက်က ကိုယ့်စိတ်နဲ့ ဆိုင်တယ်။ အတွေ့အကြုံနဲ့ ပညာနဲ့ မသက်ဆိုင်သေးဘူး။ Test လုပ်ရမှာ ပျင်းနေတာကို ဖျက်နိုင်အောင် ကြိုးစားရမယ်။ ဒါဟာ အရေးကြီးတယ်။ အခု project တစ်ခု တည်းမှာ မဟုတ်ဘူး။ နောက်ပိုင်း လုပ်ရမယ့် project တွေကိုလည်း သေသေချာချာ Test လုပ်အောင် စိတ်ကို ကျင့်ပေးရလိမ့်မယ်။ နောက်ပြီး ခေါင်းက condition တွေ အများကြီးကို မမှတ်ထားနိုင်ဘူး။ Mind Node ကို ကောင်းကောင်း အသုံးချင်သင့်ပြီလို့ ကိုယ့်ဘာသာကိုယ် သတိပေးနေရတယ်။

၅။ ယုံကြည်မှု လွန်ကဲခြင်း။

ဒါကတော့ အမြဲတန်း ဖြစ်နေကျ အမှားပဲ။ ကိုယ့်ကိုယ်ကို ပြန်ပြန်ပြီး သတိထားနေရတယ်။ ကိုယ်ရေးထားတဲ့ code တွေကို ကိုယ်ယုံမိသလို testing ပိုင်းအားနည်းတော့ ပိုဆိုးသွားတယ်။ ဒီအချက်ကိုတော့ အခုတော့ ပြင်လို့ရသွားပြီလို့ ထင်တာပဲ။ ပြီးခဲ့တဲ့ ၁ပတ် တော်တော်ပင်ပန်းသွားတော့ ဘာကြောင့် ဖြစ်ရတာလဲ ပြန်လှန်သုံးသပ်ရင်းနဲ့ ဒီ အချက်ကို သဘောပေါက်မိသွားတယ်။ ဒါကို ပြင်ဖို့ လိုတယ်ဆိုတာကို ချက်ခြင်း သိသလို ပြင်လည်း ပြင်နေတယ်။

တစ်ခါတစ်လေ Dead Line အရမ်းကပ်လာရင် နောက်ပြီး Project Manager က Management ပုံစံ မှားယွင်းသွားတဲ့ အခါမှာ တချို့ မထင်မှတ်တဲ့ အမှားလေးတွေကနေ ပြဿနာကြီးတွေ ဖြစ်ကုန်တတ်တယ်။ ဥပမာ။။ Web API stable မဖြစ်သေးပဲနဲ့ product တစ်ခုကို မြင်ချင်တာမျိုးပေါ့။ ဒါမျိုး ကိစ္စတွေမှာ ကိုယ်တိုင် သေချာ ရှင်းပြဖို့ အတွက် လိုအပ်တယ်။ အမြဲတန်းလိုလို စကားများများ မပြောချင်တဲ့ ကိုယ့်အကျင့်ကိုလည်း ပြင်သင့်တယ်။ လိုအပ်သလောက် စကားများများ မပြောတဲ့ အခါမှာ နားလည်မှုတွေ လွှဲကုန်တယ်။ လိုအပ်သလောက် စကားပြောအောင်တော့ ကြိုးစားရမယ်။

နောက် project တွေမှာ အခု သင်ခန်းစာတွေကနေပြီးတော့ ပို အဆင်ချောလာအောင် ဆောင်ရွက်နိုင်မယ်လို့လည်း ယုံကြည်ထားတယ်။ တစ်နှစ်ထက် တစ်နှစ် ပိုသိလာသလို အတွေ့အကြုံတွေကလည်း ပိုပိုများလာတယ်။ တနည်းပြောရင် မနှစ်က စိတ်ညစ် စိတ်ပျက် စိတ်ဓာတ်ကျရတဲ့ အရေအတွက်ထက် ဒီနှစ်အတွင်း စိတ်ညစ် စိတ်ပျက် စိတ်ဓာတ်ကျရတဲ့ အရေအတွက်က ပိုများလာတယ်။ ပြဿနာတွေ တစ်ခုဖြတ်ကျော်ပြီးသွားတိုင်းမှာ အတွေ့အကြုံတစ်ခုကတော့ အမြဲလိုလို ကျန်ခဲ့တာပဲလေ။