System Work Style

To Be A Good Developer (Part-2)

အားလုံး မဂၤလာပါရွင့္။
ကြၽန္မကေတာ့ Spiceworks Myanmar က မခင္ပြင့္ျဖဴခိုင္ ျဖစ္ပါတယ္။ ၿပီးခဲ့ေသာအပတ္ကေတာ့ Developer ေကာင္းတစ္ေယာက္ျဖစ္ဖို႔ ရွိသင့္တဲ့ အေၾကာင္းအခ်က္ေလးေတြကို အပိုင္း ၁ အေနျဖင့္ ေဝမွ်ေပးခဲ့ပါတယ္ေနာ္။ ဖတ္ရႈၿပီးခဲ့ေသာ ပရိသတ္မ်ားအတြက္ေရာ၊ မဖတ္ရေသးေသာ ပရိသတ္ေတြအတြက္ေကာ ထိုအပိုင္း ၁ ေလးကိုႏွိပ္၍ ဖတ္ရႈႏိုင္ပါတယ္။ ယခုတစ္ပတ္မွာေတာ့ Developer ေကာင္းတစ္ေယာက္မွာ ဘာေတြလိုအပ္လဲ၊ ေရွာင္ရမည့္ အက်င့္ေတြက ဘာေတြလဲဆိုတာကို ထပ္မံ မွ်ေဝေပးခ်င္ပါတယ္။

ဦးစြာပထမ ဘာေတြလုပ္သင့္လဲ ဆိုတာကို ေျပာျပေပးပါမယ္ေနာ္။

(၁) Study Code & Practice
Developer တစ္ေယာက္ဆိုရင္ Code ဆိုတဲ့စကားလုံးနဲ႔ မစိမ္းပါဘူးေနာ္။ အသုံးျပဳတဲ့ Language အလိုက္ပုံစံေလးေတြပဲ ကြဲျပားျခားနားပါတယ္။ သီအိုရီ သေဘာတရားခ်င္းေတြက တူညီၾကပါတယ္။ Code ေတြကို မ်ားမ်ားေလ့လာဖို႔လိုပါတယ္။ အေျခခံ စေလ့လာခါစမွာေတာ့ ဒီ Code က ဘာအတြက္၊ ဒါကေတာ့ ဟိုဟာအတြက္ဆိုၿပီး ေလ့လာမွတ္သားရပါတယ္။ ေနာက္ၿပီး ေလ့က်င့္ရပါတယ္။ ေလ့က်င့္ပါမ်ားလာေတာ့ ပိုမိုနားလည္လာၿပီး အေတြ႕အႀကဳံေတြပါ ရလာမွာျဖစ္ပါတယ္။ အခုေခတ္မွာဆိုရင္ ေတာ္ေတာ္ေလး ကံေကာင္းပါတယ္။ တကယ္လို႔ ကိုယ္ေရးလိုက္တဲ့ Code က မွားေနတယ္ဆိုရင္ Google ေပၚတက္ၿပီး အမွန္ကို ရွာေဖြ ေလ့လာႏိုင္ပါတယ္။

(၂) Documentation
မိမိတို႔အလုပ္မွာဆိုရင္လည္း Documentation ေတြေရးဖို႔ လိုအပ္ပါတယ္။ ဘာလို႔ဆို အဓိကေတာ့ မွတ္တမ္းေပါ့ေနာ္။ မိမိက အဲ့ဒီအလုပ္ေတြကို မွတ္တမ္းသာ မထားဘူးဆိုရင္ ေနာက္ထပ္ တစ္ေယာက္ကို လႊဲေျပာင္းေပးတဲ့အခါ အခက္အခဲေတြ႕ေစႏိုင္ပါတယ္။ တိတိက်က် အခ်က္အလက္ေတြကို မလုပ္ထားဘူးဆိုရင္ Project ေတြမွာ မတိက်၊ မေရရာေသာ လုပ္ေဆာင္ခ်က္ေတြနဲ႔ ျဖစ္လာလိမ့္မယ္။ မွတ္တမ္းသာ ရွိေနမယ္ဆိုရင္ Project ျပန္လည္ျပင္ဆင္တဲ့အပိုင္းမွာလည္း ျမန္ဆန္ပါလိမ့္မယ္။ Client ေတြကို Project နဲ႔ ပတ္သက္ၿပီး ေျပာဆိုရာမွာလည္း လြယ္ကူရွင္းလင္းစြာ ေျပာဆိုႏိုင္ပါလိမ့္မယ္။

(၃) Start Standard Code
Code ေတြကို စတင္ေလ့လာတဲ့အခါမွာ ဘယ္လိုေရးရမလဲ၊ ဘာအတြက္သုံးတာလဲ စသျဖင့္ အရင္ေလ့လာၾကပါတယ္။ ေရးပုံေရးနည္းေတြကိုလည္း ေလ့လာမွတ္သားရပါတယ္။ တျဖည္းျဖည္း ေလ့လာရင္းနဲ႔ တျခားလူေတြရဲ႕ Idea ေတြနဲ႔ ေရးထားတဲ့ Code အသစ္အဆန္းမ်ားကိုလည္း ေတြ႕လာရပါတယ္။ သူတို႔ စဥ္းစားပုံ၊ စဥ္းစားနည္းေတြကိုလည္း ေတြ႕ျမင္ရပါတယ္။ မိမိကိုယ္တိုင္လည္း Code ေရးေသာအခါ ၿပီးစလြယ္မေရးဘဲ စနစ္တက် ေရးသင့္ပါတယ္။ မိမိက Code ကို Standard က်က် ေရးထားရင္ မိမိကိုယ္တိုင္ ျပန္လည္သုံးသပ္မယ္ဆိုရင္လည္း စိတ္ေက်နပ္စရာ ရမွာအမွန္ပဲ ျဖစ္ပါတယ္။ တျခားသူက ကိုယ့္ Code ကို ေလ့လာေသာအခါ ေသေသခ်ာခ်ာ ရွင္းရွင္းလင္းလင္းနဲ႔ ေလ့လာလို႔လည္းရသလို၊ နားလည္ရလြယ္ကူမွာလည္း ျဖစ္ပါတယ္။ Comment ေတြ ေရးသင့္တဲ့ေနရာမွာ ေရးထားေတာ့ တျခားသူက ကိုယ့္ Code ကို ျပန္ျပင္ဆင္မယ္ဆိုရင္ အခ်ိန္ေတြျမန္ဆန္လာမွာ ျဖစ္ပါတယ္။

ကုမၸဏီတစ္ခုနဲ႔တစ္ခုကလည္း Code Standard ထားပုံခ်င္း မတူညီၾကတာေတြလည္း ရွိပါတယ္။ မိမိဝင္ေရာက္လုပ္ကိုင္မည့္ ကုမၸဏီရဲ႕ Standard Code က ဘယ္လိုဆိုတာကို အရင္ ေလ့လာၾကည့္ပါ။ Standard Code က IT ကုမၸဏီေတြအတြက္ လိုအပ္ပါတယ္။ ဝန္ထမ္းတစ္ေယာက္က သူ႔စိတ္ႀကိဳက္ ႀကိဳက္သလိုေရးတယ္။ ေနာက္တစ္ေယာက္က တစ္မ်ိဳးေရးတယ္။ အဲ့ေတာ့ Code က Standard မက်ေတာ့ဘူး။ အဲ့ဒါကေတာ့ သိပ္ေတာ့ အဆင္မေျပလွပါဘူး။ ထို႔အတြက္ေၾကာင့္ IT ကုမၸဏီတိုင္းမွာ Standard Code ကို ခ်မွတ္သင့္တယ္လို႔ ကြၽန္မအေနနဲ႔ေတာ့ ထင္ျမင္မိပါတယ္။

(၄) Review Code
Project တစ္ခုကို ေရးေနၿပီဆိုရင္ ကြၽန္မအပါအဝင္ လူေတာ္ေတာ္မ်ားမ်ားဟာ အဲ့ဒီ Project ရဲ႕ Output ကိုပဲ အရင္ျမင္ခ်င္ၾကတယ္။ အာ႐ုံထဲမွာ ၿပီးဖို႔ပဲ အေရးႀကီးေနတယ္။ မိမိတို႔ရဲ႕ Code ကို ျပန္လည္သုံးသပ္ျခင္းက နည္းၾကပါတယ္။ Output ကိုျမင္ၿပီဆိုရင္ Project တစ္ခုၿပီးၿပီေပါ့။ ေနာက္ဆက္လက္လုပ္ေဆာင္ရမယ့္ အဖြဲ႕ဝင္ေတြဆီကို လႊဲေျပာင္းေပးလိုက္ၾကတယ္။ အဲ့ေတာ့ ကိုယ့္ Code ေတြက ရႈပ္ပြေနတာလည္း ျဖစ္ႏိုင္သလို၊ မလိုလားအပ္တဲ့ Code ေတြလည္း ပါေနႏိုင္တာေပါ့။ Code ေတြကလည္း က်စ္လစ္မႈမရွိပဲ ျဖစ္ေနမွာေပါ့။ Code ၁၀ ေၾကာင္းေလာက္ပဲ ေရးရင္ရတာကို စာပိုဒ္တစ္ပိုဒ္ေလာက္ ျဖစ္ေနလိမ့္မယ္။ အဲ့လိုမ်ိဳးေတြမျဖစ္ရေအာင္ မိမိေရးလိုက္ေသာ Code ကိုျပန္ၿပီး Review လုပ္ဖို႔ လိုအပ္ပါတယ္။ ကိုယ့္ Code ကို ဘယ္လိုခ်ဳံ႕လို႔ရမလဲ၊ Function ေတြကို ဘယ္လိုအခ်ိန္မ်ိဳးမွာ သုံးသင့္လဲ၊ Common ေရးမလား စသျဖင့္ ေသခ်ာျပန္သုံးသပ္သင့္ပါတယ္။ ကြၽန္မဆိုရင္ အရင္က Code Review လုပ္ဖို႔ အေလ့အက်င့္မရွိပါဘူး။ သတိလည္းမထားမိဘူး။ အခုဆိုရင္ ကိုယ့္ Project ၿပီးရင္ေတာင္ Output ထြက္သြားၿပီဆို ဘယ္လိုမ်ိဳး ခ်ဳံ႕လို႔ရႏိုင္မလဲ စဥ္းစားၾကည့္တဲ့ အက်င့္ေလးျဖစ္လာတယ္။ တျခားလူေတြလည္း Code ေလးေတြကို Review လုပ္ဖို႔ တိုက္တြန္းအႀကံျပဳခ်င္ပါတယ္။

(၅) Testing
Project တစ္ခုၿပီးသြားၿပီဆိုရင္ အရမ္းအေရးႀကီးတဲ့ အစိတ္အပိုင္းတစ္ခုက Testing ပဲျဖစ္ပါတယ္။ Testing အတြက္ဆို အခ်ိန္သိပ္မယူ၊ မေပးျဖစ္ၾကဘူး။ အမွန္ေတာ့ သူ႔အတြက္ အခ်ိန္ေတြယူသင့္တယ္၊ အခ်ိန္ေတြ ေပးသင့္ပါတယ္။ Project တစ္ခုက Testing ေသခ်ာစစ္မွ အသုံးျပဳသူ လက္ထဲသို႔ စိတ္ခ်စြာ ထည့္ေပးလိုက္ႏိုင္မွာ ျဖစ္ပါတယ္။ Testing ေသခ်ာမလုပ္တဲ့ Project ဟာဆိုရင္ အသုံးျပဳသူေတြအတြက္ အမွားေတြနဲ႔ သက္ေတာင့္သက္သာ မရွိတဲ့အရာႀကီးျဖစ္ေနလိမ့္မယ္။ အလုပ္အတြက္ အခ်ိန္ေတြလည္း မျမန္ဆန္ေတာ့ပဲ ပိုမိုၾကန႔္ၾကာကုန္လိမ့္မယ္။ ေငြေၾကးပိုင္းဆိုင္ရာႏွင့္ ကိုယ္ပိုင္အခ်က္အလက္ပိုင္းဆိုင္ရာ Project ေတြဆို စဥ္းစားၾကည့္ပါလား။ စိုးရိမ္စရာႀကီးေနာ္။ အခ်ိန္မေပးပဲ Testing လုပ္တဲ့အခါ Error ေတြကို ေတြ႕လာရလိမ့္မယ္။ အဲ့ဒီ Error ကိုရွင္းေနတုန္းမွာပဲ ေနာက္ထပ္ Error ေတြ ထပ္ေတြ႕တယ္။ Project ကလည္း ညေနေပးရေတာ့မယ္…အခ်ိန္ေတြကမမီေတာ့ဘူး။ Schedule ေတြေနာက္က်မယ္။ Client ေတြဆီကို စကားေတြ ေျပာရေတာ့မယ္။ Client ေတြက ကိုယ့္ကို ယုံၾကည္မႈ အားနည္းလာတယ္။ ေနာက္ထပ္ Project လာဖို႔ ဆိုတာ သူတို႔အတြက္ သိပ္မလြယ္လွေတာ့ဘူး။ အဲ့လိုမျဖစ္ရေအာင္ Project တစ္ခု လုပ္ေတာ့မယ္ဆို Schedule ယူတဲ့ေနရာမွာ Testing အတြက္ပါ ေသခ်ာထည့္တြက္ စဥ္းစားသင့္ပါတယ္။

ေနာက္တစ္ပိုင္းအေနနဲ႔ကေတာ့ Developer ေတြမွာ လုပ္တတ္တဲ့ ေရွာင္ရမည့္ အက်င့္ေလးေတြကို ေဝမွ်ေပးသြားပါမယ္ေနာ္။ ကဲ ဘာေတြျဖစ္မလဲဆိုတာကို ဆက္လက္ဖတ္ရႈ ၾကည့္ၾကရေအာင္ေနာ္။

(၁) Copy & Paste
Copy/ Paste စကားလုံးက IT နယ္ပယ္ကသူေတြအတြက္ေကာ တျခားနယ္ပယ္ကလူေတြအတြက္ေကာ မစိမ္းေလာက္ဖူးလို႔ေတာ့ ထင္ပါတယ္။ Copy/ Paste လုပ္တဲ့အခါမွာလည္း ေသခ်ာလုပ္ဖို႔ လိုပါတယ္။ ကိုယ္က အြန္လိုင္းကေန Code ေတြရွာတဲ့အခါမွာလည္း ေသခ်ာနားလည္တဲ့အခါမွ Copy လုပ္သင့္ပါတယ္။ နားမလည္တဲ့အခါ Modify လုပ္ဖို႔ ခက္ခဲပါလိမ့္မယ္။ ေနာက္တစ္ခုအေနနဲ႔ကေတာ့ Project တစ္ခုကေန တျခား Project ကို Code ေတြ Copy လုပ္တဲ့အခါမွာလည္း အသုံးျပဳတဲ့ Variable နာမည္ေတြကို ဂ႐ုစိုက္ပါ။ Project တစ္ခုမွာက နာမည္တစ္ခုသုံးေပမယ့္ တျခား Project မွာေတာ့ သူနဲ႔သက္ဆိုင္တဲ့ နာမည္ကိုသာ သုံးသင့္ပါတယ္။

(၂) Official Documentation
နည္းပညာအသစ္ေတြ ထြက္လာတိုင္း ကြၽန္မတို႔ဟာ Documentation ကို ဖတ္ဖို႔လိုအပ္ပါတယ္။ နည္းပညာသစ္ကို Google မွာ ဒီအတိုင္းလိုက္ရွာရင္ ပိုအခ်ိန္ကုန္ပါတယ္။ သူ႔ရဲ႕ သက္ဆိုင္တဲ့ Documentation ကိုဖတ္ရင္ ပိုမိုျမန္ဆန္ပါတယ္။ တခ်ိဳ႕က် Official Documentation ေတြကို မဖတ္ပဲ တျခားေနရာေတြမွာ လိုက္ရွာေနတတ္တဲ့ အက်င့္ေလးေတြလည္း ရွိပါတယ္။ အဲ့ဒီလူေတြထဲမွာ ကြၽန္မလည္း တစ္ေယာက္အပါအဝင္ပါပဲ။

(၃) Health
က်န္းမာေရးက လူတိုင္းအတြက္ အေရးႀကီးပါတယ္။ က်န္းမာမွ ကိုယ္လုပ္ခ်င္တဲ့ ဘယ္အလုပ္ကိုမဆို လုပ္ႏိုင္မွာ ျဖစ္ပါတယ္။ ကြၽန္မတို႔ေတြဟာ ကြၽန္မတို႔ေနာက္ဆုံးထြက္သက္အထိ အလုပ္လုပ္ၾကရမွာပဲ ျဖစ္ပါတယ္။ အလုပ္ဆိုတာက ပိုက္ဆံရတဲ့အလုပ္တစ္ခုထဲကိုပဲ ဆိုလိုျခင္းမဟုတ္ပါဘူးေနာ္။ ကဲ ဒီေတာ့ က်န္းမာေရးက အေရးႀကီးတာေပါ့။ တခ်ိဳ႕ Developer ေတြဟာဆိုရင္ ထမင္းေမ့၊ ဟင္းေမ့၊ တခ်ိဳ႕က် ထိုင္ရာကမထ Code ေရးေနၾကတဲ့လူေတြရွိပါတယ္။ ကိုယ္လက္လႈပ္ရွားမႈကလည္း မရွိေတာ့ က်န္းမာေရးအတြက္ ကိုယ္သတိမထားမိတဲ့အခ်ိန္မွာ ဆိုး႐ြားသြားႏိုင္ပါတယ္။ ထို႔ေၾကာင့္ မိမိတို႔ဟာ မိမိက်န္းမာေရးကိုလည္း ဂ႐ုစိုက္သင့္ပါတယ္။ မိမိက်န္းမာမွ မိမိခ်စ္ျမတ္ႏိုးေသာ Code မ်ားကို ဆက္လက္ေရးႏိုင္မည္ ျဖစ္ပါတယ္။

(၄) Break Time/ Relax
ထိုေခါင္းစဥ္ကလည္း အထက္က ေဖာ္ျပခဲ့တဲ့ Health နဲ႔လည္း သက္ဆိုင္ပါတယ္။ မိမိတို႔ဟာ အလုပ္ေတြ ဘယ္ေလာက္ပဲ မ်ားေနပါေစ အနားယူရမယ့္အခ်ိန္မွာ အနားယူသင့္ပါတယ္။ အဲ့ဒီေနရာမွာ Self-management နဲ႔ဆိုင္တယ္ေပါ့ေနာ္။ အရင္က အလုပ္မွာ ၁နာရီနားတယ္ေပါ့။ အလုပ္မ်ားေနလို႔ မနားေတာ့ဘူးဆိုတာ မျဖစ္သင့္ပါဘူး။ အလြန္ဆုံး ၁၀ မိနစ္ေလာက္ေတာ့ မျဖစ္မေန အနားယူသင့္တယ္လို႔ ကြၽန္မအေနနဲ႔ ထင္ျမင္မိပါတယ္။ အလုပ္ေတြကို လုပ္ေနရလို႔ ပင္ပန္းၿပီး ေခါင္းရႈပ္ေနၿပီ။ ထိုအခ်ိန္ အလုပ္ကမၿပီးေသးလို႔ ဆက္လုပ္ေနရင္လည္း စဥ္းစားလို႔မရေတာ့လို႔ Idea မထြက္လာတဲ့အခ်ိန္ေတြလည္း ရွိမွာပဲေလ။ အဲ့လိုအခ်ိန္မ်ိဳးဆို ခဏနားၿပီး ဦးေႏွာက္ကို အနားေပးၿပီးမွ ဆက္လုပ္ရင္ ပိုမိုေကာင္းမယ္လို႔ ထင္ပါတယ္။

(၅) Control Anger
တခ်ိဳ႕ Developer ေတြက Code ေရးေနရင္း Code အေပၚမွာ စိတ္တိုလြယ္တဲ့လူေတြ ရွိပါတယ္။ တစ္ေယာက္ထဲ ေနၿပီးေရးေနတာက အဆင္ေျပသလိုလို ရွိေနေပမယ့္ အဖြဲ႕အစည္းနဲ႔အလုပ္လုပ္တဲ့အခါမွာေတာ့ တျခားလူေတြကို အေႏွာင့္အယွက္ေပးႏိုင္ပါတယ္။ တျခားလူေတြက အာ႐ုံရၿပီးအလုပ္လုပ္ေနခ်ိန္မွာ ကိုယ္က ေဒါသထြက္ၿပီး ထေအာ္လိုက္တာျဖစ္ျဖစ္၊ ေတာက္ေခါက္လိုက္တာျဖစ္ျဖစ္ တျခားလူက လန႔္ၿပီး အာ႐ုံပ်က္သြားႏိုင္ပါတယ္။ ကိုယ္အတြက္လည္း စိတ္ထဲ ေဒါသထြက္ေနတာနဲ႔ ေကာင္းေကာင္းစဥ္းစားလို႔ရမွာ မဟုတ္ဘူး။ ဒါ့ေၾကာင့္ မိမိအေနနဲ႔ ေဒါသကိုလည္း ထိန္းခ်ဳပ္ႏိုင္ရပါမယ္။

(၆) Patient
ဘယ္အလုပ္ကိုမဆို စိတ္ရွည္ရွည္ထားပါ။ Project တစ္ခုမွာ Error ရွိေနၿပီဆိုရင္လည္း ဘာေၾကာင့္ျဖစ္လာတယ္ဆိုတာကို စိတ္ရွည္စြာနဲ႔ အေျဖရွာပါ။ စိတ္ရွည္သည္းခံျခင္းဟာ ေအာင္ျမင္မႈတစ္ခုပါ။

(၇) Humble
မိမိကိုယ္ကို မိမိ ႏွိမ့္ခ်တတ္ပါေစ။ တခ်ိဳ႕လူေတြက သူတို႔ေတာ္ေနၿပီဆိုရင္ ပညာမာန္တက္ ဂုဏ္ေမာက္ၾကပါတယ္။ တျခားလူေတြက သူတို႔ေလာက္မေတာ္ဘူးဆိုတဲ့ အေတြးအျမင္ေတြ ျဖစ္လာကုန္ၾကတယ္။ ထိုအျမင္ေတြက အလုပ္ေတြမွာ အရမ္းထိခိုက္ၾကပါတယ္။ အဖြဲ႕အစည္းနဲ႔အလုပ္လုပ္ရတယ္ဆို Teamwork အားမေကာင္းေတာ့ပါဘူး။ အလုပ္က အမွန္တကယ္ ၿပီးသင့္သေလာက္မၿပီး ျဖစ္လာတတ္ပါတယ္။ ကြၽန္မကေတာ့ အဖြဲ႕အစည္းရဲ႕လုပ္အားဟာ တစ္ဦးတစ္ေယာက္လုပ္အားထက္ ပိုေတာ္ၿပီး၊ Strong ျဖစ္ပါတယ္လို႔ ထင္ျမင္မိပါတယ္။

(၈) Accept Criticism
တျခားလူေတြက ကိုယ့္ Project ကို ေဝဖန္တဲ့အခါ ေဝဖန္ခြင့္ေပးပါ။ တခ်ိဳ႕က် ေဝဖန္တာကို မႀကိဳက္ၾကဘူး။ ေဝဖန္တဲ့ေနရာမွာလည္း ေကာင္းေသာေဝဖန္ျခင္းကိုသာ မိမိအေနနဲ႔ အေလးထားပါ။ အဆိုးဘက္က ေဝဖန္ျခင္းမ်ိဳးကိုေတာ့ လ်စ္လ်ဴရႈေပးႏိုင္ရင္ေတာ့ အေကာင္းဆုံးပါ။ လူဆိုတာက ပုထုဇဥ္ဆိုေတာ့ ေျပာရတာေတာ့ ခက္ပါတယ္။ ကြၽန္မအပါအဝင္ေပါ့ေနာ္။ ေဝဖန္တာကို အေကာင္းဘက္ကေန ေျပာင္းလဲၿပီး လက္ခံၾကမယ္ဆိုရင္ေတာ့ ထိုလူအတြက္ ေအာင္ျမင္မႈေနာက္တစ္ခု ထပ္တိုးတာေပါ့။

အထူးသတိျပဳရမယ့္ အခ်က္ေလးတစ္ခုအေနနဲ႔ကေတာ့ မိမိတို႔ဟာ Code ေရးေနတဲ့လူအခ်င္းခ်င္း တစ္ဦးကိုတစ္ဦး မေႏွာင့္ယွက္မိေစေအာင္ သတိျပဳေပးပါေနာ္။

ဒီေလာက္ေလးနဲ႔ ကြၽန္မရဲ႕ မွ်ေဝျခင္းေလးကို အဆုံးသတ္ပါရေစေနာ္။ အခ်ိန္ေပးဖတ္ရႈေပးတဲ့ စာဖတ္ပရိသတ္ႀကီးကို ေက်းဇူးတင္ပါတယ္ရွင့္။ အေတြးတစ္ခုခု၊ အသိတစ္ခုခု ရသြားမယ္ဆိုရင္ ကြၽန္မဝမ္းသာမိပါတယ္ရွင့္။ သာယာေသာေန႔ေလး ျဖစ္ပါေစရွင့္။

Hello

Leave a Reply

Your email address will not be published. Required fields are marked *