အမြန်လမ်းနဲ့အမှန်လမ်း - Fast Way Vs the Right Way

Developer, Programmer အများစု အလုပ်လုပ်တဲ့အခါ လုပ်ငန်းအချိန်ဇယားကို အစပိုင်းမှာ ဘယ်လိုပဲ အဆင်ပြေအောင် လုပ်ထားပေမယ့် နောက်ပိုင်းမှာ အလွန်အကျွံ ဖိအားပေးခံရတဲ့ အချိန်နဲ့ အခြေအနေမျိုးတွေ ကြုံလာရတတ် ပါတယ်။ အဲဒီလိုအချိန်မှာ -

• အမှန်အတိုင်း လုပ်မလား (Doing it Right)
• အမြန်ပြီးအောင် လုပ်မလား(Doing it Quick)

ဆိုတဲ့ ရွေးစရာ လမ်းတွေ ရှိလာတတ်ပါတယ်။ ဒီနေရာမှာ အမြန်ပြီးအောင်လုပ်မယ်လို့ ဆုံးဖြတ်တာက "နောက်မှ ပြန်ပြင်မယ် အခုတော့ ပြီးအောင်ပဲ အရင်လုပ်မယ်" ဆိုတဲ့ အတွေးမျိုးနဲ့ လုပ်တာ ဖြစ်ပါတယ်။ အဲဒီလို ကတိမျိုးကို ကျွန်တော်တို့ဟာ - မိမိကိုယ်တိုင်၊ လုပ်ဖော်ကိုင်ဖက်များနဲ့ မိမိရဲ့ Customer - ကို ကတိပေးခဲ့မိတတ် ကြတာပါ။ ဒါပေမယ့် သိပ်မကြာခင် နောက်ထပ် အလုပ်သစ်တွေ၊ ပြဿနာသစ်တွေ ထပ်ရှိလာတဲ့အခါ ကျွန်တော်တို့ရဲ့ အာရုံစိုက်မှုက အဲဒီပြဿနာသစ်တွေ အပေါ် ပိုပြီး ရောက်သွားရင်း စောစောက ပေးထားတဲ့ ကတိတွေကို ပြန်ဂရုမစိုက်နိုင်တော့တာမျိုး ဖြစ်တတ်ပါတယ်။ ဒါကို "နည်းပညာဆိုင်ရာ ကြွေးမြီ (Technical Debt)" လို့ ပြောလို့ ရပါတယ်။ ဒီ နည်းပညာအကြွေးဟာ ကျွန်တော်တို့အတွက် ရန်သူဖြစ်ပါတယ်။

ရေရှည်ဆပ်ရမယ့် အတိုး

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

ချက်ချင်း ဖြေရှင်းပါ

တခါတလေမှာ ပြန်ပြင်လို့ မရတော့တဲ့ အခြေအနေမျိုးအထိ ကြုံတတ်တဲ့အတွက် အလုပ်တစ်ခုကို အမြန်ပြီးအောင် လုပ်လိုက်ရပြီဆိုရင် အမှားတွေ ပါမသွားအောင် အထူးဂရုစိုက်ဖို့ သိပ်အရေးကြီးပါတယ်။ ပြဿနာ မရှင်းပေမယ့် အရမ်းအမြန်လိုလို့ ပြီးအောင် လုပ်လိုက်ရပြီ ဆိုတာနဲ့ ချက်ချင်းလိုက်ပြီး Fix လုပ်ဖို့ အရေးကြီးပါတယ်။ အချိန်လုံး၀ မရတော့တဲ့ အခါမှ Fix လုပ်ဖို့ ကြိုးစားတာမျိုး မလုပ်သင့်ပါဘူး။

Keep Notice, Log Issue Tracking

မတော်တဆ အခုလို အခြေအနေမျိုး ကြုံလာရပြီဆိုရင်

 
1. ပထမဆုံး လုပ်သင့်တဲ့ အလုပ်ကတော့ အလွယ်တကူ သတိပြုနိုင်တဲ့၊ မြင်သာတဲ့ နေရာတစ်ခုမှာ ဒီပြဿနာကို ပြန်ဖြေရှင်းရဖို့ ရှိတယ်ဆိုတာကို ချက်ချင်းချရေးထားဖို့ ဖြစ်ပါတယ်။ ပြီးတော့
2. ကိုယ့်ရဲ့ Development Team မှာ Issue Tracking System ကို သုံးထားတယ်ဆိုရင် အဲဒီမှာ သွားရေးထားပြီး မိမိနဲ့ အများကို သတိပေးနိုင်အောင် စီစဉ်ဖို့ ဖြစ်ပါတယ်။

ဒါမှသာ မဖြစ်မနေ အမြန်ရှင်းရမယ့် ပြဿနာကို လူတိုင်းသိပြီး အတူ ဖြေရှင်းနိုင်မှာ ဖြစ်ပါတယ်။

အကြွေးကို မရှင်းဘဲ ပစ်ထားရင် အတိုးတွေတက်လာပြီး ထမ်းပိုးထက် လက်ခကြီးဆိုသလို ပြဿနာ တက်နိုင်ပါတယ်။ နည်းပညာအကြွေးကြောင့် ကိုယ်တည်ဆောက်ထားတဲ့ Program, Web Site တစ်ခုလုံး တစ်၀က်တစ်ပျက်နဲ့ ရပ်ဆိုင်းသွားတဲ့ အခြေအနေထိ ရင်ဆိုင်ရတာမျိုး ဖြစ်တတ်ပါတယ်။ နည်းပညာအကြွေးကို ချက်ချင်းဖြေရှင်းဖို့ကြိုးစားရင် အတိုးပေးရတာ သက်သာပါမယ်။

Original Article and Author

ဒီဆောင်းပါးဟာ O'Reilly ကထုတ်တဲ့ 97 Things Every Programmer Should Know စာအုပ်ထဲက Act with Prudence ဆောင်းပါးကို ဆီလျော်အောင် မြန်မာ ဘာသာပြန်ထားတာ ဖြစ်ပါတယ်။ မူရင်းရေးသားသူက Edinburgh မှာရှိတဲ့ Rational DOORS မှာ Principal Software Engineer အဖြစ် အလုပ်လုပ်နေတဲ့ Seb Rose ဖြစ်ပါတယ်။ သူဟာ 1987 မှာ Edinburgh University က ဘွဲ့ရခဲ့တာ ဖြစ်ပြီး၊ REKURSIV project မှာ အလုပ်စလုပ်ခဲ့ပါတယ်။ နောက်ပိုင်းမှာတော့ Freelance Contractor အဖြစ် လုပ်ကိုင်ခဲ့ပါတယ်။

ကျန်တဲ့ ဆောင်းပါးလေးတွေကိုလည်း အခုလိုပဲ ကြိုးစားဘာသာပြန်ပြီး မြန်မာညီအကို မောင်နှမများအတွက် ေ၀မျှသွားပါ့မယ်။ မူရင်းဆောင်းပါးကိုတော့ http://bit.ly/RightVsFirst မှာ ဖတ်နိုင်ပါတယ်။

This work is licensed under a Creative Commons Attribution 3