စံပြပရိုဂရမ်မာ

၂၀၀၃ ခုနှစ် ဇန်န၀ါရီလ၊ အမေရိကန်နိုင်ငံ အာ်ရီဂွန်ပြည်နယ်(Oregon) ပည်နယ်မှာရှိတဲ့ Portland ဆိုတဲ့မြို မှာ၊ Scott Meyers[Effective C++ စာအုပ်များ ရးသားခဲ့သူ Ph.D. Computer science] နဲ  Bruce Eckel [Thinking in Java, Thinking in C++ စာအုပ်များရေးသားခဲ့သူ ၊ B.S Applied Physics, M.S Computer Engineering] တို က ဦးဆောင်ပြီး “ပိုမိုကောင်းမွန်သော ကုဒ်များရေးသားခြင်း” ဆိုတဲ့ တွ ဆုံဆွေးနွေးပွဲတစ်ခု ကျင်းပခဲ့ပါတယ်။ သုံးရက်ကြာကျင်းပခဲ့တဲ့ အဲဒီ ဆွးနွေးပွဲမှာ သူတို နှစ်ဦးအပါအ၀င် တခြားပညာရှင် ၁၅ ရာက်လောက်က၊ ပရိုဂရမ်မာတွေရဲ့ coding ရးသားခြင်းနဲ  သက်ဆိုင်တဲ့ အရည်အသွေးကို ဘယ်လို တိုးတက်ကောင်းမွန်လာအောင် လုပ်ကိုင်ဆောင်ရွက် မှင့်တင်ကြမလဲဆိုတဲ့ အချက်တွေကို အဓိကထားဆွေးနွေးခဲ့ကြတာပါ။ အဲဒီလို ဆွးနွေးကြတဲ့ အချက်တွေထဲက တခုကတော့၊ Software Engineering လာက တနည်းပြောရရင်တော့ ပရိုဂရမ်ရေးသားခြင်းနယ်ပယ်မှာ လျစ်လျူရှုခြင်းခံနေရတဲ့၊ တကယ့်အခြေခံအကျဆုံးအချက်တချက်ရှိနေတယ် ဆိုတဲ့ အကြောင်းပါပဲ။ အဲဒီ လျစ်လျူရှုခံနေရတဲ့အချက်ကတော့ Dave Thomas နဲ  Andy Hunt တို   ဖာ် ထုတ်ခဲ့တဲ့ DRY Principle[Don’t Repeat Yourself Principle] ဆိုတာပဲဖြစ်ပါတယ်။ ဒီ စည်းမျဉ်းကို DIE Principle (Duplication is Evil ) လို လဲခေါ်ပါတယ်။
ဒီအာရ်ဝိုင် ရဲ့ အတိုချုပ်အနှစ်သာရကတော့ “လုပ်ကိုင်ဆောင်ရွက်ပုံခြင်း၊ Logic ခင်း၊ သဘောတရားခြင်း တူညီနေတဲ့ Code တခု(တစု)ကို application တခုထဲမှာ solution တခုထဲမှာ ထပ်ခါတလဲလဲမရေးနဲ  တကြိမ်ထက်ပိုမရေးနဲ ” ဆိုတဲ့ စည်းကမ်းသတ်မှတ်ချက်ပဲဖြစ်တယ်။ ဒီအချက်ရဲ့အနှစ်သာရကို တချို  ပရိုဂရမ်မာတွေက နားမလည်သေးတာ ဖစ်နိုင်ပြီး၊ တချို ကတော့ အဲဒီ DRY Principle ကို လုံးဝမသိသေးတာဖြစ်နိုင်ပါတယ်။ Software ရးသားရာမှာ၊ တခြားလိုက်နာ ကျင့်ဆောင်သင့်တဲ့ အချက်တွေ အများကြီးရှိပါသေးတယ်။ ဒါပေမယ့်လည်း Scott ရဲ့လေ့လာတွေ  ရှိချက်အရ၊ ဒီ DRY Principle ကိုတောင် သဘောပေါက်နားလည်ပြီး လက်တွေ  လိုက်နာဆောင်ရွက်လာအောင် မလုပ်နိုင်ဘူးဆိုရင်၊ တခြားပိုမိုရှုပ်ထွေးတဲ့ အချက်တွေဖြစ်တဲ့
• ရိုးရိုးရှင်းရှင်းဖြစ်အောင်ရေး[KISS(Keep It Simple, Stupid!)
• မလိုသေးရင် မရေးသေးနဲ YAGNI (You Ain’t Gonna Need It)
• Class တခု function တခုဟာ တိကျတဲ့ လုပ်ငန်းတာ၀န် တခုအတွက်ပဲဖြစ်ရမယ် ။ တခုထက်ပိုရင် ခွဲရေး။ SRP(Single Responsibility Principle) SoC (Separation of Concern)
ဆိုတဲ့အချက်တွေကို ကာင်းကောင်းနားလည်သဘောပေါက်လိုက်နာဖို ဆိုတာ အတွက်တော့ မျှာ်လင့်ချက်မရှိဘူး လို ဆိုပါတယ်။ ဒီ စည်းမျဉ်းတွေကို ပည့်ပြည့်စုံစုံ ရှင်းပြနိုင်ဖို  ရှည်ရှားတဲ့ ဥပမာ coding တွ လိုအပ်တဲ့အတွက် နာက်နောင်ဆောင်းပါးတွေမှာမှ အလျဉ်းသင့်တဲ့အခါ သီးသန် ဆွးနွေးပါဦးမယ်။
ဒါ့အပြင်၊ တခြားလွဲမှားနေတဲ့ ပရိုဂရမ်ရေးသားခြင်းဆိုင်ရာ ယူဆချက်တခုနဲ ပတ်သက်လို  “ပရိုဂရမ်ရေးတယ်ဆိုတာ လူနဲ စက် ဆက်သွယ်ရေးမဟုတ်၊ လူ လူချင်းဆက်သွယ်ရေးသာဖြစ်တယ်” လို  Bruce Eckel ကဆိုပါတယ်။ အဓိပ္ပါယ်ကတော့၊ လူ(Programmer)ဟာ၊ စက်(Computer Processor) ကို ဘာလုပ်ရမယ်ဆိုတာ နားလည်သွားအောင် Code တွရေးရုံ၊ ညွှန်ကြားချက်(Instruction) တွပေးရုံလောက်သာမဟုတ်ဘူး လို ဆိုလိုတာပါ။ မှန်ပါတယ်။ Program(Software) ရးတယ်ဆိုတာ၊ Software Engineer တွ၊ Pragrammer တွ နဲ ၊ ဒီ Software ကို အပ်နှံရေးသားစေတဲ့ Customer တွရဲ့ဆက်သွယ်ရေး၊ ပရိုဂရမ်ရေးသားနေတဲ့ အဖွဲ ဝင်(Team member)တွေ အချင်းချင်းရဲ့ဆက်သွယ်ရေး၊ လက်ရှိအဖွဲ ဝင်တွေနဲ  အဖွဲ ဝင်အသစ်ဖြစ်လာမယ့်သူတွေနဲ ဆက်သွယ်ရေးအပြင်၊ အထက်ပိုင်း စီမံခန်  ခွဲအုပ်ချုပ်သူတွေနဲ ဆက်သွယ်ရေးဆိုတာတွေအထိ၊ ကျယ်ကျယ်ပြန် ပန် ပါ၀င်နေပါတယ်။
ကောင်းကောင်းအလုပ်လုပ်နိုင်ရုံ၊ Run နိုင်ရုံ Program/Software တခုထွက်လာဖို ဆိုတာလောက်ဟာ၊ ကျွန်တော်တို  Software ရးသားထုတ်လုပ်မှုဖြစ်စဉ်ရဲ့ “ဆုံးမှတ်၊ ပန်းတိုင်၊ နာက်ဆုံးဦးတည်ချက်” မဟုတ်ပါဘူး။ ဒါဟာ Extreme Programming နည်းစနစ်တွေမှာ သိပ်ကိုအရေးပါတဲ့အချက်ပဲဖြစ်ပါတယ်။ ဒီ XP ဆိုတာ၊ ဆာဖ့်ဝဲအပ်နှံရေးသားစေသူ (Customers)တွေကိုပါ၊ ဆာဖ့်ဝဲရေးသားထုတ်လုပ်မှုဖြစ်စဉ် (Software Development Process) မှာ၊ Software Engineer တွနဲ အတူပူးပေါင်းပါ၀င်စေပြီး၊ သူတို  (Customer)ရဲ့လိုလားချက် လိုအပ်ချက်တွေကို တစတစ တိုးမြှင့်အကောင်အထည်ဖော်တဲ့နည်းစနစ် (Incremental Development Process) ကိုအခြေခံထားတဲ့ Software ရးသားနည်းတခုပဲဖြစ်ပါတယ်။ ဒါကြောင့်မို  ကျွန်တော်တို ရဲ့ပန်းတိုင်ဟာ ကျွန်တော်တို ရးသားတဲ့ Coding တွကို၊ တခြားသူတွေ တတ်နိုင် သမျှ ဖတ်ရှုနားလည်သဘောပေါက်အောင် ရးဖို ပါပဲ။
ဒီလိုရေးသားခြင်းဖြင့်
၁။ Software တခုကို မဖြန် ချိမီ၊ Coding နဲ  Design တွကို ပန်လည်သုံးသပ်ရာမှာ လွယ်ကူမှုရှိခြင်း။
၂။ နာင်အနာဂတ်မှာ ကိုယ့်ရဲ့ team ကို ပူးပေါင်းပါ၀င်လာမယ့် Programmer အသစ်တွေဟာ၊ သိပ်များများစားစား အားစိုက်ထုတ်ဖို မလိုပဲ အဲဒီ ကုဒ်တွေကို နားလည်သဘောပေါက်နိုင်တဲ့အတွက်၊ ကိုယ့်ရဲ့ ပရိုဂရမ်ရေးသားတဲ့ အဖွဲ ရဲ့ အတွေ အကြုံနဲ  အရည်အချင်း မန်မြန်ဆန်ဆန်တိုးတက်လာနိုင်ခြင်း။
၃။ ဒီစနစ် ဒီဆောဖ့်ဝဲကို ပင်ဆင်ပြောင်းလဲတိုးချဲ့ရေးသားဖို လိုအပ်လာတဲ့အခါ၊ သိပ်မခက်ခဲတော့ခြင်း ဆိုတဲ့ အကျိုးကျေးဇူးတွေရနိုင်ပါတယ်။
Software Engineering ဆိုင်ရာဝေါဟာရတွေနဲ ပာရမယ်ဆိုရင်တော့၊ Coding ကိုဖတ်ရှုနိုင်စွမ်း (Readability) တိုးတက်လာရင်၊ နားလည်နိုင်စွမ်း (Understandability) လည်းတက်လာမယ်။ အဲဒီရဲ့အကျိုးဆက်ကြောင့် ပင်ဆင်ထိန်းသိမ်းနိုင်စွမ်း (Maintainability) မင့်မားလာတဲ့အတွက်၊ ပင်ဆင်ထိန်းသိမ်းမှုကုန်ကျစရိတ်(Maintenance Cost) လျာ့ကျလာပါတယ်။ ဒါ့အပြင် DRY Principle ကိုလိုက်နာသုံးစွဲထားတဲ့ ပရိုဂရမ်တွေမှာ ကုဒ်အရေအတွက်(Lines of Code) လျာ့ကျလာပြီး၊ ရှုပ်ထွေးမှု (Complexity) လည်း အထိုက်အလျောက်လျော့ကျလာပါတယ်။ ဒီနှစ်ခုလျော့ကျလာတဲ့အတွက်၊ ဆာဖ့်ဝဲ ရးသားမှုကုန်ကျစရိတ်( Development Cost) အပြင် Maintenance Cost ပါ သက်သာလာစေနိုင်ပါတယ်။ ဒါကြောင့် ပရိုဂရမ်ရေးသားတယ်ဆိုတာ အဖြေတခုအတွက် အပြိုင်အဆိုင်အားသွန်ကြိုးပမ်းရုံ သက်သက်မျှသာမဟုတ်ပဲ၊ ပင်နိုင် ပာင်းနိုင် တိုးချဲ နိုင်တဲ့ စနစ်(System)တစ်ခုတည်ဆောက် တဲ့ပုံစံမျိုးသာဖြစ်ရပါမယ်။
အဲဒီ “ပိုမိုကောင်းမွန်သော Code များရေးသားခြင်း” ဆိုတဲ့ ဆွးနွေးပွဲမှာပဲ၊ ထိတ်လန် စရာ ကိန်းဂဏန်းတွေ လည်းပေါ်ထွက်လာခဲ့ပါတယ်။ အဲဒါကတော့ လက်ရှိ ဆာ့ဖ်၀ဲလောကကြီးမှာ ပါ၀င်ရေးသားနေကြတဲ့ “၉၅-ရာခိုင်နှုန်းသော Programmer တွရဲ့ ဆာဖ့်ဝဲရေးသားထုတ်လုပ်နိုင်စွမ်း [Productivity - Software ရးသားရာတွင် လိုအပ်သော idea, စိတ်ကူးစိတ်သန်း၊ တွးခေါ်နိုင်စွမ်း၊ ဖန်တီးနိုင်စွမ်း၊ စသည်...] ဟာ တခြား ကျန်တဲ့ ၅-ရာခိုင်နှုန်း သာ Programmer  အာက်ကို အဆ-၂၀ အထိ နိမ့်ကျ နတယ်”ဆိုတာပါပဲ။ ကတယ်တော်တဲ့ တန်းမှီ အရည်အသွေးပြည့် ပရိုဂရမ်မာတစ်ရောက်ဟာ တခြားသာမာန် သူလိုငါလို ပရိုဂရမ်မာတွေထက် အဆ ၂၀ လာက် ပိုတော် ပိုပြေး နတယ်ဆိုတဲ့ သဘောပါပဲ။ ဒါ့အပြင် T.DeMarco နဲ  T.Lister [Peopleware : Productive Projects and Teams, 2nd Ed. by Tom Demarco, Timothy R. Lister] တို ရဲ့ စာအုပ်မှာ၊ တကယ့်လေ့လာတွေ ရှိချက်တွေကို အခြေပြု တွက်ချက်ထားတဲ့ စာရင်းဇယားတွေ အရ၊ ၅၀-ရာခိုင်နှုန်း ကနေ၊ ၉၀-ရာခိုင်နှုန်းထိသော Software Project တွဟာ၊ မူလက မျှာ်လင့် ရည်မှန်းထားသလောက် လုပ်ဆောင်နိုင်မှုမရှိကြဘူး လို ဆိုပါတယ်။ အဲဒီ အချက်နှစ်ချက်ဟာ ဘာကြောင့်ဖြစ်တယ်လို ထင်ပါသလဲ။ ဒီဆွေးနွေးပွဲက ကြားသိရတဲ့ အချက်အလက်တွေအရ ပုံနှိပ်ထုတ်ဝေသူများရဲ့ နည်းပညာဆိုင်ရာ စာအုပ်စာတမ်းတွေဟာ၊ ၁၀-ရာခိုင်နှုန်းလောက်သာ အရင်းကျေခဲ့ပြီး တစ်ရာခိုင်နှုန်းလောက်သာ ငွကြေးအရ အာင်မြင်ခဲ့တယ်လို ဆိုပါတယ်။
ဒါဟာ ဘာကိုညွှန်ပြနေသလဲဆိုရင် “Software ရးသားထုတ်လုပ်နိုင်စွမ်း အကြီးအကျယ် ကွာဟနိမ့်ကျနေတဲ့ အဲဒီ ၉၅-ရာခိုင်နှုန်းသော ပရိုဂရမ်မာ တွဟာ စာမဖတ်ကြဘူး၊ အသစ်သစ်သောနည်းပညာတွေ၊ အထွေထွေဗဟုသုတတွေကို အချိန်နဲ တပြေးညီ မလေ့လာ မလိုက်စားကြဘူး” ဆိုတဲ့အဖြေထွက်လာပါတယ်။ တကယ်တော့ အသစ်အသစ်သော ပညာရပ်တွေကို ဆည်းပူးရတယ်ဆိုတာ၊ သက်တောင့်သက်သာရှိလှတဲ့ အလုပ်မျိုးတော့ဘယ်ဟုတ်မလဲ။ ရုပ်ရော စိတ်ပါ အနည်းနဲ အများတော့ နာကျင်ပင်ပန်းခံရတာကိုး။ ဒါပေမယ့်လည်း ဒါဟာမိတ်ဆွေတို အတွက် အကောင်းဆုံးရင်းနှီးမြုပ်နှံမှုပဲ မဟုတ်ပါလား။ မိတ်ဆွေဟာ ဒီ Program ရးသားခြင်း၊ Software ရးသားခြင်း နယ်ပယ်မှာပဲ ဆက်လက်ကျင်လည်ရပ်တည်နေဦးမှာဆိုရင်တော့၊ အမြဲမပြတ် ရှာဖွေလေ့လာသင်ယူနေဖို  [သင်တန်းတွေ တခုပြီးတခု တက်နေဖို  တာ့မဟုတ်ဘူးပေါ့ဗျာ] ဆိုတာဟာ တကယ့်ကိုပဲ မရှိမဖြစ်လိုအပ်ချက်တရပ်ပါ။ မိတ်ဆွေဟာ ဒီလိုမှမလုပ်နိုင်ဘူး၊ မလုပ်လိုဘူး၊ ဒီလို လုပ်ဆောင်ကြိုး ပမ်းနေရတာတွေကို မနှစ်သက် မခံစားနိုင်ဘူးဆိုရင်တော့၊ ဒီအလုပ်(Program/Software ရးသားအသက်မွေးခြင်းအလုပ်) ကို စွန်  လွှတ်လိုက်တာ အကောင်းဆုံးပါပဲ။ “Love it, or Leave it” ပဲပေါ့။ If you can’t stand the heat, get out of the kitchen ဆိုတာလို၊ အပူဒဏ်မခံနိုင်ရင်တော့ မီးဖိုထဲက ထွက်ရုံသာရှိတော့တာပေါ့ဗျာ။
ကျွန်တော်တို လည်း ဒီလိုပညာခေတ်၊ ယှဉ်ပြိုင်ရမှုတွေ မင့်မားနေတဲ့ခေတ်၊ စိန်ခေါ်မှုတွေများနေတဲ့ခေတ်၊ Globalization ဖစ်နေတဲ့ခေတ်ကြီးထဲမှာ စာများများဖတ်ရပါလိမ့်မယ်။ ကြီးကဲသူတွေ၊ ဆရာဆရာမတွေ၊ လ့ကျင့် သင်ကြားပေးနေသူတွေ အနေနဲ လည်း ဒီ အချက်နဲ ပတ်သက်ပြီး လူငယ်တွေကို အလေးအနက် တိုက်တွန်းသင့်ပါတယ်။ ပညာရပ်တစ်ခုကို ထဲထဲဝင်ဝင် ချချေမြစ်မြစ် လ့လာချင်တဲ့ လူငယ်တွေအတွက် အလွယ်တကူလက်လှမ်းမှီနိုင်တဲ့၊ အင်္ဂလိပ်လိုဖတ်ဖို  အဆင်မပြေသေးရင်တောင်၊ မန်မာပညာရှင်တွေရဲ့  မန်မာလိုရေးသားထားတဲ့ သင်္ချာ၊ ရူပဗေဒ၊ အတွေးအခေါ်၊ network, programming ပညာရပ်ဆိုင်ရာ အထွေထွေ သုတစာအုပ်တွေ အများကြီးရှိပါတယ်။
“ဟာ…တို က ကွန်ပျူတာသမား…သင်္ချာတို ..ရူပဗေဒ တို အတွေးအခေါ်တို နဲ ဘာဆိုင်လို လဲ” ဆို ရင်တော့ “စမ်းကြည့်ပါဦးခင်ဗျာ” လို သာ အတိုချုပ် ဆိုပါရစေတော့။ ကွန်ပျူတာသိပ္ပံ နဲ  တခြားပညာရပ်တွေဟာ သင်္ချာနဲ  ရူပဗေဒရဲ့ အုတ်မြစ်ပေါ်မှာ တည်မှီ ဖွံ ဖိုး ကြီးထွား ရှင်သန်လာကြတာ မဟုတ်ပါလား။ သင်္ချာနဲ  ရူပဗေဒဆိုတာ သိပ္ပံပညာရပ်အားလုံးရဲ့အနှစ်ချုပ်ပ်ပဲပေါ့။ အတွေးအခေါ် အထွေထွေဗဟုသုတဆိုတာလည်း ပညာရပ်တခုကို လက်တွေ အသုံးကျလာတဲ့ အဆင့်ထိရောက်လာအောင် တခြားနယ်ပယ်ပေါင်းစုံက ပညာရပ်ပေါင်းစုံကို ပူးပေါင်းဆက်စပ်ပေးမယ့် တံတားကြီးတစင်းပဲမဟုတ်ပါလား။ ဒါကြောင့် ကျွန်တော်တို ဟာ “အရှည်တွေး အဝေးမျှော်” တယ်ဆိုရင်၊ အမြင့်ဆုံးကိုရည်မှန်းပြီး ပညာရပ်တခုကို ရဆုံး ရဖျားထိ လိုက်တော့မယ်ဆိုရင်၊ မိမိကိုယ် မိမိ “ကျမ်းမျိုးစုံ၍ ဉာဏ်ဟုန်ပြင်း” အာင် လုပ်ရပါလိမ့်မယ်။ ကိုယ်နဲ တိုက်ရိုက်သက်ဆိုင်တဲ့ နည်းပညာဆိုင်ရာ စာတွေကို ဖတ်ရာမှာလည်း “ငါက C, C++ မှ ၊ ငါက Java, J5EE ကွ၊ ငါက VB, C# .NET မှ၊ ငါ open source မှ PHP မှ….” ဆိုတာတွေကလည်း အလွန်ပဲ ကျဉ်းမြောင်းမှားယွင်းနေပါတယ်။ အိန္ဒိယ၊ ဥရောပ၊ အမေရိက နဲ  တရုတ် ဂျပန် စတဲ့ နိုင်ငံရပ်ခြား ကျာင်းသားများ၊ ပညာရှင်များဟာ Programming Language အနညှ်းဆုံး ၄-၅-၆ မျိုးလောက်တတ်ကျွမ်းကြပြီး၊ Program/Software ရးသားရာမှာ ဘယ်လို Language မျိုးကိုပဲသုံးစွဲပြီးရေးရ ရးရ ရးနိုင်တဲ့သူတွေ၊ Language Neutral ဖစ်သူတွေပါ။ သူတို နဲ ယှဉ်ပြိုင်နိုင်ဖို ဆိုရင်၊ ကျွန်တော်တို လည်း အဲဒီလို ပုံစံမျိုးဖြစ်အောင် အမှီလိုက် ကြိုးပမ်းရပါလိမ့်မယ်။ ဒါကြောင့် ကိုယ့်ရဲ့တတ်ကျွမ်းမှုဘောင်ထဲမှာပဲ ကိုယ့်ကိုယ်ကို ပိတ်မိ မနေအောင် အထူးဂရုစိုက်သင့်ပါတယ်။ ကျွန်တော်ဆိုလိုတာက၊ အကုန်လုံးချည်း ပညာရှင်အဆင့် ကျွမ်းကျင်နေရမယ်လို  မဆိုလိုပါဘူး။ ကိုယ့်ရဲ့အဓိကအားပြုရာ (Major) တခု အခိုင်အမာရှိရမှာ ဖစ်သလို၊ ကျန်တာတွေကိုလည်း အရန်တွဲဖက်လေ့လာမှု(Minor) အဖြစ် ပိုင်တူသွားသင့်တယ်လို  ဆိုလိုတာပါ။ ဒါမှသာ ပင်းထန်မြန်ဆန်တဲ့ နည်းပညာအပြောင်းအလဲ လှိုင်းတံပိုးတခု ရိုက်ခတ်လာခဲ့ရင်၊ အလိုက်သင့် ပါ၀င်စီးမျော နိုင်မှာပေါ့။ အရေးကြီးတာကတော့ စာမေးပွဲမှာအမှတ်ကောင်းဖို ၊ လက်မှတ်ရဖို  အတွက် စာတွေချည်း အလွတ်ကျက်နေမယ့်အစား၊ ပညာတတ်ဖို  အတွေးအခေါ်မြင့်မားဖို  ကိုယ့်ကိုယ်ကို ယုံကြည်မှုရှိဖို  စာများများဖတ်သင့်ပါတယ်။ စာအုပ်ပုံထဲမှာချည်း နစ်မြုပ်နေဖို လည်းမဟုတ်ပါဘူး။လက်တွေ  လည်းလုပ်၊ ပတ်ဝန်းကျင်လည်းလေ့လာ၊ ရည်မှန်းချက်တူသူတွေ နဲ လည်း တွ  ဆုံဆွေးနွေးအဖြေရှာ၊ ဒီလိုမှသာ ကျွန်တော်တို ဟာ “ဘွဲ  ရ-ပညာတတ်” တွဖြစ်လာမှာပေါ့ ။ အဲဒီလိုဖြစ်လာဖို ဆိုရာမှာတော့ လွယ်ကူသက်သာစွာ အသာလေးနဲ့တော့ ဘယ်ဖြစ်ပါ့မလဲ။ဘယ်လို တန်ဘိုးရှိတဲ့အရာကိုမှ လွယ်လွယ်နဲ  မရနိုင်ဘူးဆိုတာ မိတ်ဆွေတို အားလုံး ကာင်းကောင်းသိပြီးသားမို  အထွေအထူး မိကျောင်းမင်းရေခင်းပြ မနေတော့ပါဘူး။
ဒါ့အပြင် နာက်ဆုံးတင်ပြလိုတဲ့အချက်ကတော့၊ အတ္တမဲ့ ပရိုဂရမ်ရေးသားခြင်း (Egoless Programming) ဆိုတဲ့အကြောင်းပါ။ အုပ်စုလိုက်လုပ်ကြရတဲ့ ဒီ Program/Software ရးသားမှုလုပ်ငန်းစဉ်တလျောက်မှာ၊ ငါရေးတာအမှန်၊ ငါတွေးတာအကောင်းဆုံး၊ ငါ့ပရိုဂရမ်မှာ ဟာကွက်မရှိဘူး အမှား(Error) မရှိဘူး၊ ငါ့ Logic ကိုမပြင်နိုင်ဘူးဆိုတဲ့ စိတ်မျိုးမထားမိစေဖို ပါပဲ။ ကမ္ဘာကျော် အသုံးချဆောဖ့်ဝဲ(Application Software) တွ၊ ကွန်ပျူတာကို မာင်းနှင်လည်ပတ် စတဲ့ဆောဖ့်ဝဲ စနစ်(Operating System Software) တွ အားလုံးဟာ၊ အချိန်နဲ အမျှ အဆင့်မြှင့်မျိုးကွဲအသစ် (New Version) တွ မရပ်မနားထွက်ပေါ်နေတာ အားလုံးအသိပါ။
ဒါဟာ ဘာကိုညွှန်ပြနေသလဲဆိုရင် “ပြီးပြည့်စုံပြီး အမှားကင်းတဲ့ Software ဆိုတာ လုံး၀မရှိနိုင်ဘူး” ဆိုတာပါပဲ။ ဒါကြောင့် ကျွန်တော်တို ဟာ ပရိုဂရမ်ရေးသားရာမှာ၊ “ပျော့ပျောင်းတဲ့သဘောထား ကျယ်ပြန် တဲ့အမြင်” ရှိဖို လိုပါတယ်။ တခြားသူတွေနဲ  ညှိနှိုင်းဆောင်ရွက်လုပ်ကိုင်နိုင်တဲ့ စွမ်းရည်ရှိရပါမယ်။ ပရိုဂရမ်ရေးသားတယ်ဆိုတာ တဦးကောင်း တယောက်ကောင်း လုပ်ကိုင်ဆောင်ရွက်ရတာမျိုးမဟုတ်ပဲ၊ အဖွဲ နဲ စုပေါင်းဆောင်ရွက်ကြရတဲ့ Team Work သာလျှင်ဖြစ်ပါတယ်။ ဒါကြောင့် ကိုယ်ရေးတဲ့ ပရိုဂရမ်ကို၊ တခြား ပရိုဂရမ်မာတွေ အလွယ်တကူ ဖတ်ရှုနားလည် သဘောပေါက်နိုင်စေဖို ၊ ပင်နိုင် ပာင်းနိုင် တိုးချဲ နိုင်တဲ့ ပရိုဂရမ်ဖြစ်စေဖို ၊ ကိုယ်နဲ  ရးဖော်ရေးဖက်တွေရဲ့ စွမ်းဆောင်ရည် အတူတကွ မင့်မားလာစေဖို  အတတ်နိုင်ဆုံးကြိုးပမ်းအားထုတ် သင့်ပါတယ်။ coding ကာင်းတွေ ရးသားနိုင်ဖို  programmer ကာင်းတွေဖြစ်ဖို လိုအပ်ပါတယ်။ programmer ကာင်းတစ်ရောက်ဖြစ်ဖို  စာအစုံ စာများများ ဖတ်ဖို လိုပါတယ်။ ဖတ်ပြီးသမျှကို ပန်တွေးဖို  တွးမိသမျှကို လက်တွေ ချရေးကြည့်ဖို  မဖြစ်မနေလိုအပ်ပါတယ်။ စာဖတ်တယ်ဆိုရာမှာလည်း ပရိုဂရမ်ရေးသားခြင်းဆိုင်ရာ နည်းပညာတွေကိုသာမက၊ ပရိုဂရမ်ရေးသားခြင်းဆိုင်ရာ သဘောတူညီချက်(Convention of Coding Technique)တွေ၊ ပရိုဂရမ်ရေးသားရာမှာသုံးတဲ့ အမည်ပေးပုံ စည်းကမ်းများ(Naming Rules)၊ သင်္ချာ ရူပဗေဒ အထွေထွေသုတ စတဲ့ စာမျိုးစုံဖတ်ပြီး မိတ်ဆွေတို အားလုံး စာများများဖတ်ခြင်းဖြင့် “ကျမ်းမျိုးစုံ၍ ဉာဏ်ဟုန်ပြင်း” နိုင်ပါစေကြောင်း။
ရွှင်လန်းချမ်းမြေ့ပါစေ။

infoTherapy(2013)
(2013 ဒီဇင်ဘာလထုတ် ကွန်ပြူတာဂျာနယ်တွင် ဖါ်ပြပြီးသော ဆာင်းပါးဖြစ်ပါသည်။)