Developer တစ်ယောက် ရဲ့ တာဝန်
ကိုယ့် program ကိုယ် စစ်ဆေးပါ။
Developer တစ်ယောက်ဟာ code ရေးနေဖို့ပဲ မဟုတ်ပါဘူး။ မိမိ code ကိုလည်း ကိုယ့်ဘာသာကိုယ် test လုပ်တတ်ဖို့ လိုပါတယ်။ အများအားဖြင့် developer တွေဟာ unit testing တွေကို QR လက်ထဲ လွဲလိုက်တာ များပါတယ်။ function တွေ အလုပ်လုပ် မလုပ်။ ကိုယ်ရေးထားတာတွေက မှန်မမှန် ပြန်စစ်ဖို့က developer တစ်ယောက်မှာ တာဝန်တွေ အများကြီး ရှိပါတယ်။
အလုပ်တွေမှာ Tester ဆိုပြီး ခေါ်တာထက် QA (Quality Assurance) position ဆိုပြီး ခေါ်တာပါ။ တနည်းပြောရင် သူတို့ရဲ့ တာဝန်က Tester တစ်ယောက် ထက်ပိုပါတယ်။ developer အတွက် unit test တွေ လုပ်ပေးဖို့ မဟုတ်ပါဘူး။
အစ နဲ့ အဆုံး သိပါစေ။
Project တစ်ခုက စလုပ်ပြီဆိုရင် အရေးအကြီးဆုံးက ဘယ်ကနေစပြီး ဘယ်မှာဆုံးမယ် ဆိုတာပဲ။ ကျွန်တော်တို့ ဘယ်လို မျိုး product လိုချင်မှန်း မသိသေးခင်မှာ project ကို စမရေးသင့်ဘူး။ Project တစ်ခု အကြောင်း သိအောင် ကိုယ့် အထက်က လူကို မေးပါ။ Project owner ကို မေးပါ။ တစ်ခါတစ်လေ ကိုယ့်အထက်က လူကိုယ်တိုင် ဘယ်လို project လိုချင်မှန်း မသိတာတွေ ရှိတတ်တယ်။ ဒါကြောင့် ဘာလိုချင်မှန်းသိပြီး အဆုံးသတ်မှာ ဘယ်လို project လိုချင်မှန်း သိဖို့ လိုတယ်။
တကယ်လို့ ကျွန်တော်တို့ဟာ အစကတည်းက ဘာလိုချင်မှန်း သေသေချာချာ မသိခဲ့ရင် Team တစ်ခုအနေနဲ့ ကောင်းမွန်စွာ အလုပ်မလုပ်နိုင်ခဲ့ရင် အောက်က ပုံထဲကလို project တစ်ခု ဖြစ်လာလိမ့်ပါမယ်။
ဒါကြောင့် ကိုယ်လုပ်မယ့် project အကောင်းကို အဆုံးသတ်ဟာ ဘာလဲ ဘာကို လိုချင်တာလဲ ဆိုတာကို အရင်ဆုံး သိအောင် ကြိုးစားဖို့ လိုပါလိမ့်မယ်။
သပ်ရပ်ရှင်းလင်းသော code
Live as if you were to die tomorrow. Learn as if you were to live forever.
- Mahatma Gandhi
ကျွန်တော်တို့ဟာ ဘယ်အချိန်မှာ သေသွားနိုင်မယ် ဆိုတာ မသိဘူး။ မနက်ဖြန် ရုံးသွားရုံးပြန် အချိန်မှာလည်း တစ်ခုခု ဖြစ်သွားနိုင်ပါတယ်။ ဒါကြောင့် ကျွန်တော်တို့ code ကို ရေးသားရာမှာလည်း မနက်ဖြန် ငါသေသွားခဲ့ရင် စိတ်လေးနဲ့ နောက်လူ အတွက် အဆင်ပြေအောင် ရေးသားဖို့ လိုပါတယ်။ အကယ်၍ ကိုယ်က နေထိုင် မကောင်းလို့ တစ်ခုခု ဖြစ်ပြီး ဆေးရုံတက်ရတဲ့ အခါမှာ တစ်ခြား တစ်ယောက်က ကိုယ့်ရဲ့ တာဝန်တွေကို လွဲပြောင်းပြီး လုပ်ရမှာပါပဲ။ အဲဒီ အခါမှာ ကိုယ့်ရဲ့ code တွေကို ကြည့်ပြီး ကျိန်ဆဲ နေရင်လည်း မကောင်းဘူး။ နားမလည်တဲ့ အပိုင်းတွေကို ဆေးရုံထိ လာပြီး မေးလည်း မကောင်းလှဘူး။ ဒါကြောင့် အတတ်နိုင်ဆုံး code ကို ရှင်းရှင်းလင်းလင်း ရေးထားဖို့ လိုပါတယ်။ Code တွေကို ရေးတဲ့ အခါမှာ ကိုယ့်ချစ်သူ ဖတ်ဖို့အတွက် ရေးတယ်လို့ သဘောထားပြီး ရေးပါ။ သို့မှသာ နားလည်လွယ်တဲ့ code တွေကို ရလာပါလိမ့်မယ်။
နောက်ပြီးတော့ Hard code တွေ ထက် သီးသန့် config file ဖြစ်ဖြစ် ကြေငြာပြီး သုံးသင့်တယ်။ သို့မှသာ နောင် အချိန်မှာ ပြောင်းရပြင်ရ လွယ်ပါလိမ့်မယ်။ ဥပမာ။။ production url က ဘာ development url က ဘာ ။ productionMode = true/false စတာတွေကို config အနေနဲ့ တနေရာတည်းမှာ သီးသန့် သိမ်းထားခြင်းဖြင့် နောင် အချိန်မှာ ပြုပြင်ပြောင်းလဲ ရတာ အဆင်ပြေပါလိမ့်မယ်။
document တွေ လုပ်ထားပါ။
ကိုယ်ဟာ ရုံးကနေ ဘယ်နေ့ ဘယ်အချိန်မှာ ဘယ်လို ထွက်မလဲ ဆိုတာ မသိဘူး။ ဒါမှမဟုတ် ကိုယ့် project ကို ဘယ်နေ့ ဘယ်အချိန်မှာ ဘယ်သူ့ကို လွှဲပေးရမလဲ ဆိုတာကိုလည်း မသိဘူး။ ဒါကြောင့် project တစ်ခုကို လုပ်နေခြင်းမှာပဲ တစ်ခါတည်း document လေးတွေ လုပ်ထားခဲ့ဖို့ လိုတယ်။ API document တွေ နောက်ပြီးတော့ business logic တွေပါ ရေးသားထားတဲ့ document တစ်ခု ဖန်တီးဖို့ လိုပါတယ်။ ပုံမှန် အားဖြင့် developer တွေဟာ document ဖန်တီးဖို့ ပျင်းကြပါတယ်။ ရုံးက ထွက်သွားရင်လည်း handover ကို ပြီးမြောက်အောင် မလွှဲသွားနိုင်တာ များပါတယ်။ အကယ်၍ document တွေသာ သေချာ လုပ်ခဲ့မယ်ဆိုရင် handover အဆင့်လေးတွေက လွယ်ကူသလို ကိုယ် ခွင့်ရက်ရှည် ယူထားတဲ့ အချိန် အခြားတစ်ယောက်က လွယ်လင့်တကူ ကိုယ့် code တွေကို ကူညီ ရေးသားပေးနိုင်ပါလိမ့်မယ်။
Style Guide
ရုံးတစ်ရုံးတည်းမှာ developers တွေ အများကြီး ရှိကြတဲ့ အတွက် တစ်ယောက်နဲ့ တစ်ယောက် ရေးသားပုံကလည်း မတူညီကြပါဘူး။ ဒါကြောင့် project တစ်ခုတည်းမှာ ရေးသားပုံ မျိုးစုံ တွေ့နိုင်တယ်။ အချို့တွေက variableName , အချို့က variable_name , အချို့က VarilableName စသည်ဖြင့် မျိုးစုံ ဖြစ်နေရင် ကြည့်လို့ မကောင်းလှပါဘူး။ ဒါကြောင့် style guide တစ်ခုကို ချမှတ်ထားပြီးတော့ ဘယ်ဟာကို ဘယ်လို style နဲ့ ရေးမယ်ဆိုတာကို သတ်မှတ်ထားဖို့ လိုတယ်။ သို့မှသာ code တွေဟာ စနစ်တကျ ပုံစံ တူ ဖြစ်နေပါလိမ့်မယ်။
နောက်ဆုံး အပိုင်းကိုတော့ နောက်နေ့မှ ဆက်ရေးပါတော့မယ်။