စာမေးခြင်း အတတ်ပညာ

Photo Credit : Tim Gouw

Developer အချင်းချင်း ပြဿနာဖြေရှင်းပေးဖို့ အကူအညီတောင်းတဲ့နေရာမှာလည်း ပညာသားတော်တော်တော့ ပါရတယ်။ လက်ရှိ ရုံးမှာ အလုပ်သင်တွေလာရင် ပြပေးဖြစ်တယ်၊ ပြီးတော့ လေ့လာမှာ စာသင်ရင်း တစ်ချို့သင်တန်းသားတွေလာမေးကြရင်လည်း ကိုယ်လည်း အတတ်နိုင်ဆုံး ရှင်းပြပေးပြီး လိုတဲ့နေရာတွေ ပြောပြပေးဖြစ်တယ်။ ဒီမှာဘာသွားတွေ့လဲဆိုတော့ ခုမှစလုပ်တဲ့သူတွေတော်တော်များများက tools တွေသေချာမသုံးတတ်သေးတာကတစ်ကြောင်း၊ သေချာပြန် မရှင်းပြတတ်တာကတစ်ကြောင်း တစ်ခါတစ်လေ error ရှင်းပေးရတာ တော်တော်ကြာတယ်။ ဟိုတစ်လောက တိုက်တိုက်ဆိုင်ဆိုင် Fragmented Podcast က Short, Self Contained, Correct, Example (SSCCE) (မဖတ်ရသေးရင် ဖတ်ကြည့်ကြပါ) အကြောင်းပြောတာလေးနားထောင်မိပြီး ကိုယ့်အတွေ့အကြုံလေး ပြန်ဝေမျှချင်စိတ်ဖြစ်တာနဲ့ ဒီစာလေးရေးဖြစ်သွားတယ်။

ကိုယ့်ဟာကိုယ်အဖြေရှာ

အရင်ဆုံးလုပ်ရမှာက ကိုယ့်ဟာကိုယ် အဖြေရှာကြည့်ဖို့ပဲ။ Documentation တွေရှာ၊​ StackOverflow မှာရှာ၊ Github က library ဆို issues တွေထဲဝင်ရှာ။ ဒီလိုရှာတဲ့နေရမှာ Google-fu ကိုကျွမ်းကျင်နေမှရမယ်။ အရှည်ကြီးတွေရေးပြီး ရှာမဲ့အစား၊ ဘာဘာဆိုပြီး လိုတိုရှင်းရှာတတ်ဖို့က developer တွေရဲ့ လိုအပ်တဲ့ အတတ်ပညာတစ်ခုလိုကိုဖြစ်နေတယ်။ အားလုံးရှာလို့ မတွေ့တော့ဘူးဆိုတော့မှ တစ်ခြားသူကိုအကူအညီတောင်းပါ။ ကျွန်တော်ကြုံဖူးသလောက် လာမေးတယ်၊ ကိုယ်က Google လည်းခေါက်လိုက်ရော ထိပ်မှာတင် Stackoverflow ကအဖြေတွေ့။ ဒီလိုကျ ကိုယ့်ကို ပြပေးတဲ့သူက ကိုယ်ကြိုးစားအားထုတ်မှုမရှိဘူးထင်သွားမယ်။ ပြင်ဆင်မှုမရှိပဲ ဘာဖြစ်ဖြစ်လာမေးတဲ့သူကို ဘယ်လောက်ပဲ သည်းခံနိုင်တယ်ပြောပြော လူသဘာဝအရ ကြာတော့ ချဉ်သွားတယ်။ ကိုယ်က ရှာထားတဲ့အချက် လေးတွေနဲ့လာတော့ “ကျွန်တော် ဒီက ဒါလေးတွေတော့ ဒီလိုပဲ စမ်းထားတယ်၊ ဒါပေမဲ့လည်း မရသေးဘူး” ဆိုရင် ဘာပဲပြောပြော “သြော်၊ ဒီကောင် နောက်ဆုံးမရလို့ ငါ့အားကိုးတာပဲ” ဆိုပြီး ကူပေးချင်စိတ်ပိုပေါက်တယ်။​

Error ရှင်းပြချင်းအတတ်ပညာ

များသောအားဖြင့် ကြုံရတာ Code ကြီးပြပြီး အလုပ်မလုပ်ဘူးဆိုတာလောက်နဲ့ ပြောကြတယ်။ ပွင့်ပွင့်လင်းလင်းပြောရရင် လူတိုင်းက သူ့အလုပ်နဲ့သူရှုပ်နေကြတာ။ သင်တန်းမဟုတ်ပဲ အလုပ်ခွင်ထဲမှာဆိုပိုဆိုးတယ်။ သင်တန်းမှာက ပြပေးရမှာ ဆရာ/ဆရာမ တာဝန်မလို့၊ လုပ်ဖော်ကိုင်ဖက်ကြတော့ သူ့အလုပ်ကိုရပ်ပြီး ကူပေးရမှာ။ ကိုယ်က သူများအချိန်ကို ငှားသုံမှာဖြစ်လို့ သူ့အတွက် အဆင်ပြေဆုံးကို လုပ်ပေးဖို့ ကိုယ့်မှာတာဝန်ရှိတယ်။ ဒီလိုမျိုး ပြီးစလွယ် “မရဘူး ကြည့်ပေး” ဆိုတဲ့မလုံမလောက်တဲ့ အချက်အလက်ဆိုရင် ကြည့်ပေးတဲ့သူအတွက် တကယ်ကို အာရုံနောက်တယ်။ Error တစ်ခုကိုမေးမယ်ဆိုရင် ကျွန်တော်လုပ်နေကြနည်းကတော့

  • ကိုယ်က ဘာလုပ်ချင်တာဆိုတာကို တိုတိုနဲ့လိုရင်းပြောတယ်
  • ဘာလုပ်လိုက်ရင်တော့ ဘယ်လိုပုံစံမျိုးနဲ့ crash သွားတယ်ဆိုတာ ပြောတယ်။
  • လိုအပ်မယ်ဆိုရင် စမ်းတဲ့ environment အချက်အလက်(Android မှာဆို OS version, Phone Model etc.)
  • Error stacktrace (အောက်မှာ ဘယ်လို share ရတယ်ဆို ဆက်ရေးပေးမယ်)
  • Reproducible Code sample (Reproducible ဖြစ်ဖို့ အရေးကြီးတယ်)
  • Error ရောက်အောင် ဘယ်လိုလုပ်ရတယ်ဆို တစ်ဆင့်ချင်းသေချာ ပြောပြတယ်
  • စမ်းကြည့်ထားတဲ့ ပြင်နည်းတွေရှိရှင် ဘယ်လိုစမ်းထာတာမရကြောင်းပြောတယ်။

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

Code share နည်းအတတ်ပညာ

တော်တော်များများကြုံရတာ ရေးထားတဲ့ Code လေးပြပါဆိုရင် screenshot ကြီးပို့တယ်။ တစ်ချို့ဆို Screen ကို ဖုန်းနဲ့ရိုက်ထားတဲ့ ပုံကြီးပါပို့တယ်။ ဖုန်းနဲ့ရိုက်တော့ screen က အလင်းပြန်တာနဲ့ ဘာမှကိုမမြင်ရဘူး။ ဒါမျိုးကို ဘယ်လိုလုပ်ကြည့်ပေးရမတုန်း။ တစ်ဖက်က ကြည့်ပေးမဲ့လူက စမ်းကြည့်မယ်ဆိုရင်တောင် ကိုယ့် code ကို copy-paste အလွယ်တကူလုပ်ပြီး run လို့မရဘူး။

Code share မယ်ဆိုရင် သုံးလို့ရတဲ့ tools တွေအနေနဲ့ Gist, Pastebin တို့ရှိတယ်။ ဒီလို tool တွေမှာ ကိုယ့် code အပိုင်းအစလေးကို copy-paste လုပ်၊ link လေးထုတ်ပြီး သူများကိုပေးလိုက်ရုံပဲ။​ ဒါဆို တစ်ဖက်လူကလည်း သူ့စက်မှာ စမ်းကြည့်မယ်ဆို အလွယ်တကူစမ်းလို့ရတယ်။ ဒီမှာ နည်းလမ်းတစ်ခုရှိတာက comment လေးတွေထည့်ပြီး ကိုယ့် code ကိုပါရှင်းပြလို့ရသေးတယ်။ ဒါဆိုရင် code ဖတ်တဲ့သူအတွက်လည်း ကိုယ်ဘာဆိုလိုတယ်ဆိုတာ လွယ်လွယ်သိနိုင်တယ်။

 //Create an instance of moshi
 val moshi = Moshi.Builder().build()

 //transform entity to json, crashing here with NullPointerException
 moshi.adapter(Entity::class.java).toJson(value)

SSCCE အရပြောရမယ်ဆိုရင်

  • မလိုတဲ့ code အပိုင်းအစတွေဖယ်ထုတ်။​ အတတ်နိုင်ဆုံးမြန်မြန်စမ်းလို့ရအောင် ကိုယ့်အနေနဲ့ လိုအပ်တဲ့အပိုင်းတွေကို ရှာဖွေတတ်ရမယ်။ လိုအပ်ရင် file အသစ်ခွဲပြီး copy-paste ပြန်လုပ်။ လိုအပ်ရင် တန်း run လို့ရတဲ့အဆင့်ထိရောက်အောင် နည်းနည်းပြန်ပြင်ရေးတတ်ရမယ်။
  • လိုအပ်တဲ့အပိုင်းတွေအကုန်လုံးတစ်နေရာတည်းစု (gist မှာဆိုရင် code snippet အများကြီးကို တစ်စုတည်းသိမ်းလို့ရတယ်)။​ ကိုယ်က ဖြစ်တဲ့အပိုင်းလေးပဲဆိုပြီး ပေးလိုက်ပေမဲ့ ဖြစ်တဲ့အပိုင်းမှာ တစ်ခြားအပိုင်းတွေကို သုံးထာတာမျိုးတွေပါသွားနိုင်တယ်။​ ဒါဆိုရင် အဲ့အပိုင်းတွေပါ ထည့်ပေးရမယ်၊ အရမ်းများလို့ ပေးရမှာအဆင်မပြေရင် အနည်းဆုံး ဒီနားကတော့ ဘာလုပ်ဖို့ သုံးထားတာဆိုပြီး comment လောက်ရေးပေး။
  • Naming ကိုလည်း ရှင်းရှင်းလင်းလင်းပေးထား(​a, b, c နဲ့လာရင် ဘယ် variable ကဘာကိုဆိုလိုတာမှန်းမသိနိုင်ဘူး)
  • Third party library အဆန်းတွေသုံးတာဆို library ရဲ့ link တွေပါ ပို့ပေး။
  • လိုအပ်တဲ့ use case တွေပြောပြပေး။ ကိုယ်က တော့ ဒီလိုသုံးချင်တာ၊ ဒါပေမဲ့ တစ်ခြားတစ်မျိုးဆိုလည်း အဆင်ပြေအောင်လုပ်ပေးဖို့လိုမယ်ထင်ရင် အသုံးပြုမဲ့ ပုံစံကိုရှင်းပြ၊ input တွေပါရင် ဖြစ်နိုင်တဲ့ input ကဘာတွေဖြစ်နိုင်တယ်ဆိုတာ တစ်ခါတည်းထည့်ပြော။

အပေါ်မှာပြောခဲ့တဲ့ error stack trace ကိုလည်း ဒီလိုပဲ pastebin ထဲဖြစ်ဖြစ်ထည့်ပြီး link ပို့ပေးလို့ရတယ်။ Error stack ကလည်း Logging tool တစ်ခုခုကို ကျွမ်းကျင်နေမှ error ဘယ်လိုဖတ်ရတယ်ဆိုတာသိနိုင်မှာဆိုတော့ ကိုယ်သုံးမဲ့ toolchain ကိုလည်း ကျွမ်းကျင်အောင်လုပ်ဖို့လိုတယ်။​

ဒီနည်းကို ကျွမ်းကျင်ချင်ရင်တော့ Github က issue ဖွင့်ထားတာတွေဝင်ကြည့်ရင် သူများတွေ ဘယ်လိုမျိုးပြောကြလဲဆိုတာ လေ့လာလို့ရတယ်။

အနေအထိုင်တတ်ခြင်း အတတ်ပညာ

လူတွေဆိုတာ စိတ်အမျိုးမျိုးနဲ့ဆိုတော့ တစ်ယောက်နဲ့တစ်ယောက် ချဉ်းကပ်တဲ့ပုံစံခြင်းကတူချင်မှတူမယ်။ ကျွန်တော့်အနေနဲ့က အရင်ဆုံး အလုပ်အားရဲ့လား အရင်မေးတယ်၊ အားတယ်ဆိုမှ ခွင့်တောင်းပြီး မေးချင်တာလေးတွေမေးတယ်။ မအားသေးဘူးဆိုရင်လည်း “ထပ်စမ်းကြည့်လိုက်ဉီးမယ်, မရမှပြန်လာခဲ့မယ်” ဆိုပြီး အားတဲ့အချိန်ကို စောင့်တယ်။ စောင့်နေတုန်းလည်း ကိုယ့်ဟာကိုယ်လျှောက်စမ်းကြည့်တယ်။

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


ပြန်ခြုံငုံပြီးပြောရမယ်ဆိုရင်

  • ကိုယ်ဟာကိုယ် အရင်ရှာပြီး ဖြေရှင်းတတ်ရမယ်။
  • ဘာလုပ်ချင်တာ၊ ဘာဖြစ်သွားတယ်ဆိုတာကို လိုတိုရှင်း အချက်အလက်လုံလုံလောက်လောက်နဲ့ ရှင်းပြတတ်ရမယ်။
  • Screen ကြီးကို ဓာတ်ပုံရိုက်ပြီးမပို့ပါနဲ့၊ tool တစ်ခုခုနဲ့ share ပါ။
  • ကူပေးတဲ့သူကို စိတ်ထက်ထက်သန်သန်နဲ့မေးပါ။

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

Read more

Platform Engineering: Developers for Developers

Platform Engineering: Developers for Developers

Software Development Team တွေကို ချဲ့ထွင်တဲ့အခါမှာ အတားအဆီးမရှိအောင် Process တွေ၊​ စံနှုန်းတွေ၊ Automation အစရှိတွေကို တာဝန်ယူတဲ့ အဖွဲ့တစ်ဖွဲ့ သီးသန့်ထားလေ့ရှိတယ်။ ဒီ Team ကို Platform Engineering လိုခေါ်တွင်တယ်။

lock-1 By Aung Kyaw Paing
Spikes: Making Unknowns Known

Spikes: Making Unknowns Known

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

By Aung Kyaw Paing
Tips & Tricks for Distributed Remote Collaboration

Tips & Tricks for Distributed Remote Collaboration

အပေါ်ယံလောက်ကြည့်ရင်တော့ ဒါဟာ Co-located team တွေလောက် အလုပ်မတွင်ဘူးထင်ရပေမဲ့ တကယ်ထိရောက်အောင်အလုပ်လုပ်တတ်ရင် Distributed Team ကလည်း သူ့ဟာနဲ့သူ သာတဲ့အချက်တွေရှိတယ်။ ဒီတော့...

By Aung Kyaw Paing
ссс