-Choose the one you want to use. Enjoy!
Wednesday, April 29, 2015
Let's use pure Myanmar Unicode in Windows 8
-In Windows 8.1, pure Myanmar Unicode font has been already included on the system. -You don't have to install any extra font or "Keyboard" to use. -First, make sure that there is "Myanmar Text" by open "MS Word" and see the font drop down.
-Now, Let's make ready for Keyboard/Input of Myanmar. -Type "Control Panel" in the Windows 8.1 search box. (Note: Click the "Windows" icon and just type the word you want to search.)
-Click the Control Panel to Open. -In the "Clock, Language and Region" group, click "Add a language" link.
-Type "Myanmar" or "Burmese" in the search language box.
-Click the font name and just click "Add". -Now, u will see in the list as:
Done. -Now, you are ready to type/use pure "Myanmar" unicode. -To change the input method(keyboard), just press "Windows" key and "Space Bar"
-Choose the one you want to use. Enjoy!
-Choose the one you want to use. Enjoy!
Thursday, April 2, 2015
ဆော့ဖ်ဝဲ ဗိသုကာဒီဇိုင်းပုံစံများ (Software Architectural Design Patterns)
Design Pattern ရဲ့ သမိုင်းကြောင်းအကျဉ်း
• ၁၉၇၇-၇၉ မှာ ဗိသုကာပညာရှင် ခရစ်စ်တိုဖာ အလက်စ်ဇန်းဒါး Christopher Wolfgang Alexander (born in October 4th, 1936 in Vienna, Austria) က၊ အဆောက်အဦး နဲ မို့ရွာတည်ဆောက်မှုဆိုင်ရာ ဒီဇိုင်းပုံစံ နဲ ပတ်သက်တဲ့ အတွေးအခေါ် အယူအဆ တစ်ရပ်ကို “A Pattern Language: Towns, Buildings, Construction” ဆိုတဲ့ စာတမ်းမှာ တင်ပြခဲ့တယ်။
• အဲဒီအတွေးအခေါ် အယူအဆ သဘောတရားတွေကို အခြေခံပြီး အမေရိကန် ေဆာ့ဖ်၀ဲအင်ဂျင်နီယာတွေဖြစ်တဲ့ Kent Beck နဲ Ward Cunningham တို က၊ object oriented programming ရးသားတဲ့ နရာမှာ ‘pattern’ တွ အသုံးချကြည့်တဲ့နည်းလမ်းတွေကို စမ်းသပ်ခဲ့ပြီး၊ “Using Pattern Languages for Object-Oriented Programs” ဆို တဲ့ စာတမ်းတစ်စောင်ကို ၁၉၈၇ မှာ ACM(Association for Computing Machinery) ကဦးစီးကျင်းပတဲ့၊ OOPSLA (Object Oriented Programming, Systems, Languages and Applications) ကွန်ဖရင့် မှာ တင်သွင်းခဲ့ပါတယ်။
• ၁၉၈၀ နှာင်းပိုင်းနဲ ၁၉၉၀ အစောပိုင်း ကာလတွေမှာ ဆာ့ဖ်၀ဲအင်ဂျင်နီယာတွေ နဲ ဆာ့ဖ်၀ဲဗိသုကာတွေက ဆာ့ဖ်၀ဲ ရးသား တည်ဆောက်ရာမှာ သုံးတဲ့ ဗိသုကာပုံစံတွေ ကို ခွဲခြားစိစစ်ပြီး ၎င်းတို ကိုသုံးစွဲတဲ့ နရာမှာ တွ ကြုံရတဲ့ ပဿနာ တွနဲ ပတ်သက်လို အသေးစိပ် စတင် လ့လာခဲ့ကြတယ်။
• ၁၉၉၅ ခုနှစ်မှာတော့၊ ဒီကနေ ခတ် ဆာ့ဖ်၀ဲအင်ဂျင်နီယာပညာရပ်နယ်ပယ်ရဲ့ ဂန္ထ၀င်စာအုပ် “Design Pattern : Elements of Reusable Object-Oriented Software” ကို Erich Gamma, Richard Helm, Ralph Johnson နဲ John Vlissides တို က ရးသားထုတေ်၀ခဲ့တယ်။ အဲဒီပုဂ္ဂိုလ် လးရောက်ကို ဆာ့ဖ်၀ဲဒီဇိုင်းလောကမှာ လးဦးဂိုဏ်း (Gang of Four - GoF) လို ခါ်ကြတယ်။
• ၁၉၉၇ မှာ Joseph Yoder နဲ Jeffrey Baraclow က၊ security pattern တွနဲ ပတ်သက်တဲ့ “Architectural Patterns for Enabling Application Security” ဆိုတဲ့ စာတမ်းတစ်စောင်ကို ထုတေ်၀ခဲ့တယ်။
Design Pattern ဆိုတာ ဘာလဲ
ခရစ်စ်တိုဖာ အလက်စ်ဇန်းဒါး က Pattern ဆိုတာကို ဟာဒီလိုရှင်းပြပါတယ်။
“ပုံစံတိုင်း ပုံစံတိုင်းဟာ ပင်ပပတ်၀န်းကျင်မှာ ထပ်တလဲလဲ တွ ကြုံနေကျ ပဿနာကို ဖါ်ပြတယ်။ ပီးရင် အဲဒီပြဿနာရဲ့ တကယ့်ရင်းမြစ်အဖြေ ကို ဖါ်ပြတယ်။
အဲလိုနည်းနဲ ခင်ဗျားဟာ ဆင်တူအလုပ်တစ်ခုကို ဘယ်တော့မှ နှစ်ခါပြန်လုပ်စရာမလိုပဲ အဲဒီဖြေရှင်းနည်းကိုပဲ အကြိမ်ကြိမ် အထပ်ထပ် ပန်သုံးစွဲနိုင်တယ်”။
သူပြောတာကတော့ အဆောက်အဦးနဲ မို ရွာတည်ဆောက်ရေးကို ရည်ညွှန်းတာဖြစ်ပေမယ့်၊ အဲဒီစကားဟာ object oriented design pattern တွအတွက်လည်း လုံး၀မှန်ကန်တဲ့ စကားဖြစ်ပါတယ်။ နယ်ပယ်ခြင်းမတူပေမယ့် တကယ့်အနှစ်သာရကတော့ ပဿနာနဲ အဖြေ ဘယ်လို ဆက်စပ် ဖွဲ စည်း တည်ဆောက်ထားသလဲဆိုတာပါပဲ။ သူရည်ညွှန်းတဲ့ အဖြေဆိုတာ နံရံတွေ တံခါးပေါက်တွေ ဖစ်ပြီး၊ ကျွန်တော်တို ရဲ့ အဖြေဆိုတာကတော့၊ object တွ interface တွပေါ့။
ယေဘုယျအားဖြင့် pattern တစ်ခုမှာ အဓိက အစိပ်အပိုင်း ၄-ပိုင်း ပါ၀င်ပါတယ်။
၁. pattern ရဲ့ အမည်
၂. ဒီ pattern ဖစ်လာစေတဲ့ အရင်းခံ ပဿနာ
၃. အဲဒီပြဿနာအတွက် ဖရှင်းပုံ
၄. ဒီ pattern ကို သုံး လို ဖစ်လာတဲ့ အကျိုးဆက်တွေ
Software Design Pattern ဆိုတာ
class တွရဲ့ ဖွဲ စည်းတည်ဆောက်ပုံ နဲ object တွ အချင်းချင်း အပြန်အလှန် ဆက်သွယ်ပုံကို ဖါ်ပြထားတဲ့
ဆာ့ဖ်၀ဲလုပ်ငန်းခွင်ရဲ့ အရင် အတွေ အကြုံတွေအပေါ် အခြေခံပြီး၊ ယဘုယျ ပဿနာ နဲ ဖစ်နိုင်တဲ့ အဖြေကို ပုံစံတကျ ဖါ်ပြထားတဲ့
လက်တွေ ပင်ပလောကရဲ့ ဆာ့ဖ်၀ဲရေးသားထုတ်လုပ်မှု လုပ်ငန်းခွင်တွေမှာ၊ ထပ်တလဲလဲ တွ ကြုံနေရတဲ့ ဆာ့ဖ်၀ဲနဲ ပတ်သက်တဲ့ ဒီဇိုင်းပိုင်းဆိုင်ရာ ပဿနာတွေရဲ့ အဖြေ အဖြစ်၊ သင့်လျော်သလို ပန်လည်သုံးစွဲနိုင်တဲ့ ဆာ့ဖ်၀ဲဗိသုကာဒီဇိုင်းပုံစံ” ဖစ်ပါတယ်။
အတိုချုပ်ပြောရရင်တော့ “design pattern ဆိုတာ ဆာ့ဖ်၀ဲရေးသားထုတ်လုပ် တဲ့အခါ၊ ယဘုယျ ကြုံတွေ နကျ object-oriented design ပဿနာတွေကို ဘယ်လို ဖရှင်းမလဲ ဆိုတာ ပုံစံတကျဖေါ်ပြထားတဲ့ ဆာ့ဖ်၀ဲတည်ဆောက်မှုဆိုင်ရာ ဗိသုကာဒီဇိုင်းပုံစံ” ဖစ်ပါတယ်။
အခြေခံ Design Pattern ဘယ်နှစ်မျိုးရှိသလဲ
လေးဦးဂိုဏ်း ဖါ်ထုတ်တင်ပြခဲ့တဲ့ ဒီဇိုင်းပုံစံတွေဟာ ဒီကနေ ဆာ့ဖ်၀ဲလောကမှာရှိတဲ့ ဒီဇိုင်းပုံစံတွေအားလုံးရဲ့ အခြေခံပါ။ သူတို တင်ပြခဲ့တဲ့ Design Pattern စုစုပေါင်း ၂၃ မျိုးရှိပြီး အဲဒီ ၂၃ မျိုးကို အဓိကအုပ်စုကြီးသုံးစုအဖြစ် ခွဲခြားထားပါတယ်။ အဲဒါတွေကတော့
i. object တွကို ဘယ်လို စတင်ဖန်တီးတည်ဆောက် (instantiate) မလဲဆိုတာကို အဓိကထား ဖါ်ပြတဲ့ Creational Design Pattern
ii. class တွ object တွကို ဘယ်လို ဘယ်ပုံ ဖွဲ စည်းတည်ဆောက် ထားသလဲဆိုတာကို အဓိကထားဖေါ်ပြတဲ့ Structural Design Pattern နဲ
iii. Object တွ class တွရဲ့ အပြုအမူ လုပ်ကိုင်ဆောင်ရွက်ပုံ (ဘာတွေကို ဘယ်လိုလုပ်ကြသလဲဆိုတာ) ကို အဓိကထားဖေါ်ပြတဲ့ Behavioral Design Pattern
ဆိုပြီး ဖစ်ပါတယ်။
အောက်ပါဇယားမှာ GoF ရဲ့ ဒီဇိုင်းပုံစံ ၂၃ မျိုးကို အုပ်စု ၃-စု ခွဲပြီး ၊ အတိုချုပ် ရှင်းလင်းချက်နဲ တကွ ဖါ်ပြထားပါတယ်။
Creational Patterns
စဉ် အမည် အတိုချုပ် အဓိပ္ပါယ်
၁ Abstract Factory ဆက်နွယ်ပတ်သက်မှုရှိနေတဲ့ class တွအတွက် object ဆာက်တဲ့ ပုံစံ။
၂ Builder Object တည်ဆောက်တဲ့ နရာနဲ ကိုယ်စားပြုတဲ့ နရာ သပ်သပ်စီ ခွဲထားတဲ့ ပုံစံ။
၃ Factory Method အမွေယူထားတဲ့ class ပါင်းများစွာအတွက် object ဆာက်တဲ့ ပုံစံ။
၄ Prototype လုံး၀ ပီးပြည့်စုံတဲ့အဆင့်အထိ တည်ဆောက်ပြီးသား object တစ်ခုကို၊ ထပ်တူညီပွားယူတဲ့ ပုံစံ။
၅ Singleton class တစ်ခုအတွက် object တစ်ခုတိတိ ကိုပဲ တည်ဆောက်ခွင့်ပေးတဲ့ ပုံစံ။
Structural Patterns
စဉ် အမည် အတိုချုပ် အဓိပ္ပါယ်
6 Adapter မတူညီတဲ့ class တွအတွက်၊ သူတို အားလုံးနဲ ကိုက်ညီမယ့် interface တွ တည်ဆောက်တဲ့ ပုံစံ။
7 Bridge အသုံးပြုမယ့် object ရဲ့ interface နဲ ၊ အဲဒီ object ကိုယ်စားပြုတဲ့ class ကို သပ်သပ်စီ ခွဲထားတဲ့ ပုံစံ။
8 Composite သီးသန် တစ်ခုတည်းဖြစ်တဲ့ object တွနဲ ၊ တစ်ခုနဲ တစ်ခု တွဲဖက်ပူးပေါင်း နတဲ့ object တွရဲ့ tree structure ကို ဖါ်ပြတဲ့ ပုံစံ။
9 Decorator Object တစ်ခုရဲ့ ဆာင်ရွက်ရမယ့် လုပ်ငန်းတာ၀န်တွေကို၊ run time မှာ ထပ်ထည့်တဲ့ ပုံစံ။
10 Facade စနစ်ခွဲ (sub system) တစ်ခုလုံးကို class တစ်ခုတည်းက ကိုယ်စားပြုတဲ့ ပုံစံ။
11 Flyweight Object တွကို ထိထိရောက်ရောက် မျှေ၀သုံးစွဲနိုင်ဖို ချိန်ညှိထားတဲ့ပုံစံ။
12 Proxy Object တစ်ခုကို တခြား object တစ်ခုနဲ ကိုယ်စားပြု သုံးစွဲတဲ့ ပုံစံ။
Behavioral Patterns
စဉ် အမည် အတိုချုပ် အဓိပ္ပါယ်
13 Chain of Responsibilities တွဲစပ်နေတဲ့ object တွ အချင်းချင်းကြားမှာ လုပ်ငန်းတာ၀န်တွေကို လက်ဆင့်ကမ်းဖြန် ၀ လုပ်ဆောင်စေတဲ့ပုံစံ။
14 Command command request ကို object ထဲမှာ ဖုံးအုပ် ထည့်သွင်း တည်ဆောက်ထားတဲ့ပုံစံ။
15 Interpreter ပရိုဂရမ်ထဲမှာ ဘာသာစကားဆိုင်ရာ အစိပ်အပိုင်းကို ထည့်သွင်းတည်ဆောက်ထားတဲ့ပုံစံ။
16 Iterator အစုအေ၀းထဲမှာပါတဲ့ element တခုချင်းစီကို အစီအစဉ်အလိုက် ဆွဲယူအသုံးပြုတဲ့ပုံစံ။
17 Mediator class တွအချင်းချင်း ရိုးရှင်းတဲ့ ဆက်သွယ်မှုပုံစံကို သတ်မှတ်တဲ့ပုံစံ။
18 Memento လိုအပ်ရင် မူလအခြေအနေကို ပန်ရနိုင်အောင် object ရဲ့ အတွင်းပိုင်းအခြေအနေကို ရယူသိမ်းဆည်းထားတဲ့ပုံစံ။
19 Observer class တခုမှာ အပြောင်းအလဲတခုဖြစ်တိုင်း တခြား class တွကို တပြိုင်တည်း အသိပေး အကြောင်းကြားတဲ့ ပုံစံ။
20 State object တခုရဲ့ အခြေအနေပြောင်းရင် အပြုအမူကိုပါ ပာင်းစေတဲ့ ပုံစံ။
21 Strategy ပဿနာဖြေရှင်းပုံ algorithm ကို class ရဲ့ အတွင်းထဲမှာ ဖုံးအုပ် ထည့်သွင်း တည်ဆောက်ထားတဲ့ ပုံစံ။
22 Template Method ပဿနာဖြေရှင်းပုံ အသေးစိပ်အဆင့်တွေကို sub-class တွဆီ လွှဲပြောင်းပေးထားတဲ့ ပုံစံ။
23 Visitor class ကို ဘာမှ မပြောင်းစေပဲနဲ လုပ်ဆောင်ချက်အသစ်ကို သတ်မှတ်တဲ့ပုံစံ။
တိကျသေချာတဲ့ ဖွဲ စည်းမှု ပုံသဏ္ဍန် ပါ်လွင်ဖို နဲ ၊ အနက်အဓိပ္ပါယ်ကို ရှင်းလင်းစွာနားလည်သဘောပေါက်နိုင်ဖို ၊ Design Pattern တွကိုဖေါ်ထုတ်တင်ပြရာမှာ၊ အာက်ပါ အချက်တွေ ပါ၀င်သင့်တယ်လို GoF က ဆိုပါတယ်။
1. Intent (အကျဉ်းချုပ် ရှင်းလင်းချက်)
2. Motivation (နောက်ခံပြဿနာနဲ ဖရှင်းပုံ)
3. Applicability (လက်တွေ အသုံးချနိုင်မှု အနေအထား)
4. Structure (ဖွဲ စည်းတည်ဆောက်ပုံ)
5. Participants (ပါ၀င်တဲ့ class, object, interface တွ)
6. Collaborations (class တွ object တွ အချင်းချင်း ပူးပေါင်းလုပ်ဆောင်ပုံ)
7. Consequences (အကျိုးဆက်)
8. Implementation (အကောင်အထည်ဖေါ်ဆောင်ရွက်မှုပုံစံ)
9. Sample Code (နမူနာ ကုဒ်)
10. Known Uses (ပြင်ပလောက ရဲ့ သုံးစွဲမှုများ)
11. Related Patterns (ဆက်စပ်ပုံစံများ)
ဆိုပြီးဖြစ်ပါတယ်။
ကဲ ဒီတော့ ပထမဆုံး အနေနဲ Creational patterns အုပ်စုထဲက အတော်အတန် ရိုးရှင်းလွယ်ကူတဲ့ Factory Design Pattern အကြောင်းကို ကျွန်တော်တို စတင်လေ့လာကြည့်ကြပါစို ။ တကယ်တော့ မိတ်ဆွေတို သိတဲ့အတိုင်း အထက်မှာတင်ပြခဲ့သလိုပဲ creational design pattern ဆိုတာ “ဆော့ဖ်၀ဲစနစ်တခုအတွင်းမှာ၊ ကိုယ်လိုအပ်တဲ့ အခြေအနေနဲ သင့်တော်မယ့် လိုက်လျောညီထွေဖြစ်မယ့် object ကို ဘယ်လို တည်ဆောက်မလဲ ဆိုတဲ့ object တည်ဆောက်တဲ့ နည်းစနစ်တွေနဲ ပတ်သက်ပြီး အထူးပြုလေ့လာတဲ့ ဒီဇိုင်းပုံစံ” တခုပါ။ “ဒီ object ဆာက်တာများ ဘာဆန်းလို ဒီလို တကူးတက တသီးတသန် ကြီး လုပ်နေရတာတုန်း” လို မိတ်ဆွေတို ထင်ကောင်းထင်ပါလိမ့်မယ်။ တကယ်တော့ ဒီဇိုင်းပိုင်းဆိုင်ရာပြဿနာတွေနဲ ဒီဇိုင်းရှုပ်ထွေးမှုကိုဖြစ်စေတာ အဲဒီ object တည်ဆောက်တဲ့ အခြေခံပုံစံတွေ ကိုယ်တိုင်ပါပဲ။ ဒါကြောင့် object တည်ဆောက်ပုံကို ထိန်းချုပ်တဲ့ ဒီ creational design pattern တွကို software complexity ကို လျာ့ချနိုင်ဖို နဲ ဆာ့ဖ်၀ဲဒီဇိုင်းပိုင်းဆိုင်ရာပြဿနာတွေ ဖရှင်းနိုင်ဖို အသုံးချနိုင်ပါတယ်။
Factory Design Pattern
Object တည်ဆောက်နိုင်ဖို အတွက် interface တစ်ခုကို ဖန်တီးပေးထားပါတယ်။ ဒါပေမယ့် ဘယ် object ကို ဆာက်မလဲဆိုတာတော့ sub-class, child-class တွကို ရွးချယ် ဆုံးဖြတ်ခွင့် ပးထားပါတယ်။ ဒီ factory method ကို virtual constructor လို လဲ လူသိများပါတယ်။ ဘာလို လဲဆိုတော့ ဒီ pattern ဟာ constructor ကို အစားထိုးဖို အတွက်သုံးတာဖြစ်လို ပါ။ ပီးတော့လည်း ဒီ ဒီဇိုင်းပုံစံဟာ object တွကို create လုပ်ရာမှာ design time မှာထက် run time ရာက်မှ instantiate လုပ်ခွင့်ပေးထားတဲ့အတွက်၊ class ရဲ့ object creation ကို ကြိုတင်ပြီး ပုံသေ သတ်မှတ်ထားတာမျိုးမဟုတ်ပဲ၊ လိုအပ်တော့မှ လိုအပ်သလို ထိန်းချုပ်တည်ဆောက်တာမျိုးဖြစ်ပါတယ်။
using System;
usingSystem.Collections.Generic;
namespaceInfoTherapy.DesignPattern.Factory
{
public interface IEmployee
{
doubleSalary { get; }
}
public class ProjectManager: IEmployee
{
public double Salary
{
get{ return 100.00; }
}
}
public class Developer : IEmployee
{
public double Salary
{
get { return 75.00; }
}
}
public class DBA : IEmployee
{
public double Salary
{
get{ return 70.00; }
}
}
public class EmployeeFactory
{
public enum EmployeeType
{
ProjectManager,
Developer,
DBA
}
public static IEmployeegetEmployee(EmployeeType empType)
{
IEmployeeemployee = null;
switch(empType)
{
case EmployeeType.ProjectManager:
employee = new ProjectManager();
break;
caseEmployeeType.Developer:
employee = new Developer();
break;
caseEmployeeType.DBA:
employee = new DBA();
break;
default:
thrownew ArgumentException(string.Format(
"An employee of type {0} cannot be found",
Enum.GetName(typeof(EmployeeType), empType)));
}
returnemployee;
}
}
class FactoryDPDemo
{
static void Main(string[] args)
{
Dictionary<EmployeeFactory.EmployeeType, IEmployee> employees =
newDictionary<EmployeeFactory.EmployeeType, IEmployee>();
//let's create a new employee for each available employee type.
//Each item is insatantiated without the client needing to know
//what type of object is being created.
//this is handled by the factory method
foreach(EmployeeFactory.EmployeeTypeeType in
Enum.GetValues(typeof(EmployeeFactory.EmployeeType)))
{
employees.Add(eType, EmployeeFactory.getEmployee(eType));
}
//now let's iterate through our dictionary and
//diplay the base salary for each factory object
foreach(EmployeeFactory.EmployeeTypetype in employees.Keys)
Console.WriteLine(string.Format(
"The basic salary for {0} is {1:C} per hour.",
type, employees[type].Salary));
Console.ReadKey();
}
}
}
ဆက်လက်တင်ပြပါမည်။
ရွှင်လန်းချမ်းမြေ့ပါစေ။
infoTherapy-2015
• ၁၉၇၇-၇၉ မှာ ဗိသုကာပညာရှင် ခရစ်စ်တိုဖာ အလက်စ်ဇန်းဒါး Christopher Wolfgang Alexander (born in October 4th, 1936 in Vienna, Austria) က၊ အဆောက်အဦး နဲ မို့ရွာတည်ဆောက်မှုဆိုင်ရာ ဒီဇိုင်းပုံစံ နဲ ပတ်သက်တဲ့ အတွေးအခေါ် အယူအဆ တစ်ရပ်ကို “A Pattern Language: Towns, Buildings, Construction” ဆိုတဲ့ စာတမ်းမှာ တင်ပြခဲ့တယ်။
• အဲဒီအတွေးအခေါ် အယူအဆ သဘောတရားတွေကို အခြေခံပြီး အမေရိကန် ေဆာ့ဖ်၀ဲအင်ဂျင်နီယာတွေဖြစ်တဲ့ Kent Beck နဲ Ward Cunningham တို က၊ object oriented programming ရးသားတဲ့ နရာမှာ ‘pattern’ တွ အသုံးချကြည့်တဲ့နည်းလမ်းတွေကို စမ်းသပ်ခဲ့ပြီး၊ “Using Pattern Languages for Object-Oriented Programs” ဆို တဲ့ စာတမ်းတစ်စောင်ကို ၁၉၈၇ မှာ ACM(Association for Computing Machinery) ကဦးစီးကျင်းပတဲ့၊ OOPSLA (Object Oriented Programming, Systems, Languages and Applications) ကွန်ဖရင့် မှာ တင်သွင်းခဲ့ပါတယ်။
• ၁၉၈၀ နှာင်းပိုင်းနဲ ၁၉၉၀ အစောပိုင်း ကာလတွေမှာ ဆာ့ဖ်၀ဲအင်ဂျင်နီယာတွေ နဲ ဆာ့ဖ်၀ဲဗိသုကာတွေက ဆာ့ဖ်၀ဲ ရးသား တည်ဆောက်ရာမှာ သုံးတဲ့ ဗိသုကာပုံစံတွေ ကို ခွဲခြားစိစစ်ပြီး ၎င်းတို ကိုသုံးစွဲတဲ့ နရာမှာ တွ ကြုံရတဲ့ ပဿနာ တွနဲ ပတ်သက်လို အသေးစိပ် စတင် လ့လာခဲ့ကြတယ်။
• ၁၉၉၅ ခုနှစ်မှာတော့၊ ဒီကနေ ခတ် ဆာ့ဖ်၀ဲအင်ဂျင်နီယာပညာရပ်နယ်ပယ်ရဲ့ ဂန္ထ၀င်စာအုပ် “Design Pattern : Elements of Reusable Object-Oriented Software” ကို Erich Gamma, Richard Helm, Ralph Johnson နဲ John Vlissides တို က ရးသားထုတေ်၀ခဲ့တယ်။ အဲဒီပုဂ္ဂိုလ် လးရောက်ကို ဆာ့ဖ်၀ဲဒီဇိုင်းလောကမှာ လးဦးဂိုဏ်း (Gang of Four - GoF) လို ခါ်ကြတယ်။
• ၁၉၉၇ မှာ Joseph Yoder နဲ Jeffrey Baraclow က၊ security pattern တွနဲ ပတ်သက်တဲ့ “Architectural Patterns for Enabling Application Security” ဆိုတဲ့ စာတမ်းတစ်စောင်ကို ထုတေ်၀ခဲ့တယ်။
Design Pattern ဆိုတာ ဘာလဲ
ခရစ်စ်တိုဖာ အလက်စ်ဇန်းဒါး က Pattern ဆိုတာကို ဟာဒီလိုရှင်းပြပါတယ်။
“ပုံစံတိုင်း ပုံစံတိုင်းဟာ ပင်ပပတ်၀န်းကျင်မှာ ထပ်တလဲလဲ တွ ကြုံနေကျ ပဿနာကို ဖါ်ပြတယ်။ ပီးရင် အဲဒီပြဿနာရဲ့ တကယ့်ရင်းမြစ်အဖြေ ကို ဖါ်ပြတယ်။
အဲလိုနည်းနဲ ခင်ဗျားဟာ ဆင်တူအလုပ်တစ်ခုကို ဘယ်တော့မှ နှစ်ခါပြန်လုပ်စရာမလိုပဲ အဲဒီဖြေရှင်းနည်းကိုပဲ အကြိမ်ကြိမ် အထပ်ထပ် ပန်သုံးစွဲနိုင်တယ်”။
သူပြောတာကတော့ အဆောက်အဦးနဲ မို ရွာတည်ဆောက်ရေးကို ရည်ညွှန်းတာဖြစ်ပေမယ့်၊ အဲဒီစကားဟာ object oriented design pattern တွအတွက်လည်း လုံး၀မှန်ကန်တဲ့ စကားဖြစ်ပါတယ်။ နယ်ပယ်ခြင်းမတူပေမယ့် တကယ့်အနှစ်သာရကတော့ ပဿနာနဲ အဖြေ ဘယ်လို ဆက်စပ် ဖွဲ စည်း တည်ဆောက်ထားသလဲဆိုတာပါပဲ။ သူရည်ညွှန်းတဲ့ အဖြေဆိုတာ နံရံတွေ တံခါးပေါက်တွေ ဖစ်ပြီး၊ ကျွန်တော်တို ရဲ့ အဖြေဆိုတာကတော့၊ object တွ interface တွပေါ့။
ယေဘုယျအားဖြင့် pattern တစ်ခုမှာ အဓိက အစိပ်အပိုင်း ၄-ပိုင်း ပါ၀င်ပါတယ်။
၁. pattern ရဲ့ အမည်
၂. ဒီ pattern ဖစ်လာစေတဲ့ အရင်းခံ ပဿနာ
၃. အဲဒီပြဿနာအတွက် ဖရှင်းပုံ
၄. ဒီ pattern ကို သုံး လို ဖစ်လာတဲ့ အကျိုးဆက်တွေ
Software Design Pattern ဆိုတာ
class တွရဲ့ ဖွဲ စည်းတည်ဆောက်ပုံ နဲ object တွ အချင်းချင်း အပြန်အလှန် ဆက်သွယ်ပုံကို ဖါ်ပြထားတဲ့
ဆာ့ဖ်၀ဲလုပ်ငန်းခွင်ရဲ့ အရင် အတွေ အကြုံတွေအပေါ် အခြေခံပြီး၊ ယဘုယျ ပဿနာ နဲ ဖစ်နိုင်တဲ့ အဖြေကို ပုံစံတကျ ဖါ်ပြထားတဲ့
လက်တွေ ပင်ပလောကရဲ့ ဆာ့ဖ်၀ဲရေးသားထုတ်လုပ်မှု လုပ်ငန်းခွင်တွေမှာ၊ ထပ်တလဲလဲ တွ ကြုံနေရတဲ့ ဆာ့ဖ်၀ဲနဲ ပတ်သက်တဲ့ ဒီဇိုင်းပိုင်းဆိုင်ရာ ပဿနာတွေရဲ့ အဖြေ အဖြစ်၊ သင့်လျော်သလို ပန်လည်သုံးစွဲနိုင်တဲ့ ဆာ့ဖ်၀ဲဗိသုကာဒီဇိုင်းပုံစံ” ဖစ်ပါတယ်။
အတိုချုပ်ပြောရရင်တော့ “design pattern ဆိုတာ ဆာ့ဖ်၀ဲရေးသားထုတ်လုပ် တဲ့အခါ၊ ယဘုယျ ကြုံတွေ နကျ object-oriented design ပဿနာတွေကို ဘယ်လို ဖရှင်းမလဲ ဆိုတာ ပုံစံတကျဖေါ်ပြထားတဲ့ ဆာ့ဖ်၀ဲတည်ဆောက်မှုဆိုင်ရာ ဗိသုကာဒီဇိုင်းပုံစံ” ဖစ်ပါတယ်။
အခြေခံ Design Pattern ဘယ်နှစ်မျိုးရှိသလဲ
လေးဦးဂိုဏ်း ဖါ်ထုတ်တင်ပြခဲ့တဲ့ ဒီဇိုင်းပုံစံတွေဟာ ဒီကနေ ဆာ့ဖ်၀ဲလောကမှာရှိတဲ့ ဒီဇိုင်းပုံစံတွေအားလုံးရဲ့ အခြေခံပါ။ သူတို တင်ပြခဲ့တဲ့ Design Pattern စုစုပေါင်း ၂၃ မျိုးရှိပြီး အဲဒီ ၂၃ မျိုးကို အဓိကအုပ်စုကြီးသုံးစုအဖြစ် ခွဲခြားထားပါတယ်။ အဲဒါတွေကတော့
i. object တွကို ဘယ်လို စတင်ဖန်တီးတည်ဆောက် (instantiate) မလဲဆိုတာကို အဓိကထား ဖါ်ပြတဲ့ Creational Design Pattern
ii. class တွ object တွကို ဘယ်လို ဘယ်ပုံ ဖွဲ စည်းတည်ဆောက် ထားသလဲဆိုတာကို အဓိကထားဖေါ်ပြတဲ့ Structural Design Pattern နဲ
iii. Object တွ class တွရဲ့ အပြုအမူ လုပ်ကိုင်ဆောင်ရွက်ပုံ (ဘာတွေကို ဘယ်လိုလုပ်ကြသလဲဆိုတာ) ကို အဓိကထားဖေါ်ပြတဲ့ Behavioral Design Pattern
ဆိုပြီး ဖစ်ပါတယ်။
အောက်ပါဇယားမှာ GoF ရဲ့ ဒီဇိုင်းပုံစံ ၂၃ မျိုးကို အုပ်စု ၃-စု ခွဲပြီး ၊ အတိုချုပ် ရှင်းလင်းချက်နဲ တကွ ဖါ်ပြထားပါတယ်။
Creational Patterns
စဉ် အမည် အတိုချုပ် အဓိပ္ပါယ်
၁ Abstract Factory ဆက်နွယ်ပတ်သက်မှုရှိနေတဲ့ class တွအတွက် object ဆာက်တဲ့ ပုံစံ။
၂ Builder Object တည်ဆောက်တဲ့ နရာနဲ ကိုယ်စားပြုတဲ့ နရာ သပ်သပ်စီ ခွဲထားတဲ့ ပုံစံ။
၃ Factory Method အမွေယူထားတဲ့ class ပါင်းများစွာအတွက် object ဆာက်တဲ့ ပုံစံ။
၄ Prototype လုံး၀ ပီးပြည့်စုံတဲ့အဆင့်အထိ တည်ဆောက်ပြီးသား object တစ်ခုကို၊ ထပ်တူညီပွားယူတဲ့ ပုံစံ။
၅ Singleton class တစ်ခုအတွက် object တစ်ခုတိတိ ကိုပဲ တည်ဆောက်ခွင့်ပေးတဲ့ ပုံစံ။
Structural Patterns
စဉ် အမည် အတိုချုပ် အဓိပ္ပါယ်
6 Adapter မတူညီတဲ့ class တွအတွက်၊ သူတို အားလုံးနဲ ကိုက်ညီမယ့် interface တွ တည်ဆောက်တဲ့ ပုံစံ။
7 Bridge အသုံးပြုမယ့် object ရဲ့ interface နဲ ၊ အဲဒီ object ကိုယ်စားပြုတဲ့ class ကို သပ်သပ်စီ ခွဲထားတဲ့ ပုံစံ။
8 Composite သီးသန် တစ်ခုတည်းဖြစ်တဲ့ object တွနဲ ၊ တစ်ခုနဲ တစ်ခု တွဲဖက်ပူးပေါင်း နတဲ့ object တွရဲ့ tree structure ကို ဖါ်ပြတဲ့ ပုံစံ။
9 Decorator Object တစ်ခုရဲ့ ဆာင်ရွက်ရမယ့် လုပ်ငန်းတာ၀န်တွေကို၊ run time မှာ ထပ်ထည့်တဲ့ ပုံစံ။
10 Facade စနစ်ခွဲ (sub system) တစ်ခုလုံးကို class တစ်ခုတည်းက ကိုယ်စားပြုတဲ့ ပုံစံ။
11 Flyweight Object တွကို ထိထိရောက်ရောက် မျှေ၀သုံးစွဲနိုင်ဖို ချိန်ညှိထားတဲ့ပုံစံ။
12 Proxy Object တစ်ခုကို တခြား object တစ်ခုနဲ ကိုယ်စားပြု သုံးစွဲတဲ့ ပုံစံ။
Behavioral Patterns
စဉ် အမည် အတိုချုပ် အဓိပ္ပါယ်
13 Chain of Responsibilities တွဲစပ်နေတဲ့ object တွ အချင်းချင်းကြားမှာ လုပ်ငန်းတာ၀န်တွေကို လက်ဆင့်ကမ်းဖြန် ၀ လုပ်ဆောင်စေတဲ့ပုံစံ။
14 Command command request ကို object ထဲမှာ ဖုံးအုပ် ထည့်သွင်း တည်ဆောက်ထားတဲ့ပုံစံ။
15 Interpreter ပရိုဂရမ်ထဲမှာ ဘာသာစကားဆိုင်ရာ အစိပ်အပိုင်းကို ထည့်သွင်းတည်ဆောက်ထားတဲ့ပုံစံ။
16 Iterator အစုအေ၀းထဲမှာပါတဲ့ element တခုချင်းစီကို အစီအစဉ်အလိုက် ဆွဲယူအသုံးပြုတဲ့ပုံစံ။
17 Mediator class တွအချင်းချင်း ရိုးရှင်းတဲ့ ဆက်သွယ်မှုပုံစံကို သတ်မှတ်တဲ့ပုံစံ။
18 Memento လိုအပ်ရင် မူလအခြေအနေကို ပန်ရနိုင်အောင် object ရဲ့ အတွင်းပိုင်းအခြေအနေကို ရယူသိမ်းဆည်းထားတဲ့ပုံစံ။
19 Observer class တခုမှာ အပြောင်းအလဲတခုဖြစ်တိုင်း တခြား class တွကို တပြိုင်တည်း အသိပေး အကြောင်းကြားတဲ့ ပုံစံ။
20 State object တခုရဲ့ အခြေအနေပြောင်းရင် အပြုအမူကိုပါ ပာင်းစေတဲ့ ပုံစံ။
21 Strategy ပဿနာဖြေရှင်းပုံ algorithm ကို class ရဲ့ အတွင်းထဲမှာ ဖုံးအုပ် ထည့်သွင်း တည်ဆောက်ထားတဲ့ ပုံစံ။
22 Template Method ပဿနာဖြေရှင်းပုံ အသေးစိပ်အဆင့်တွေကို sub-class တွဆီ လွှဲပြောင်းပေးထားတဲ့ ပုံစံ။
23 Visitor class ကို ဘာမှ မပြောင်းစေပဲနဲ လုပ်ဆောင်ချက်အသစ်ကို သတ်မှတ်တဲ့ပုံစံ။
တိကျသေချာတဲ့ ဖွဲ စည်းမှု ပုံသဏ္ဍန် ပါ်လွင်ဖို နဲ ၊ အနက်အဓိပ္ပါယ်ကို ရှင်းလင်းစွာနားလည်သဘောပေါက်နိုင်ဖို ၊ Design Pattern တွကိုဖေါ်ထုတ်တင်ပြရာမှာ၊ အာက်ပါ အချက်တွေ ပါ၀င်သင့်တယ်လို GoF က ဆိုပါတယ်။
1. Intent (အကျဉ်းချုပ် ရှင်းလင်းချက်)
2. Motivation (နောက်ခံပြဿနာနဲ ဖရှင်းပုံ)
3. Applicability (လက်တွေ အသုံးချနိုင်မှု အနေအထား)
4. Structure (ဖွဲ စည်းတည်ဆောက်ပုံ)
5. Participants (ပါ၀င်တဲ့ class, object, interface တွ)
6. Collaborations (class တွ object တွ အချင်းချင်း ပူးပေါင်းလုပ်ဆောင်ပုံ)
7. Consequences (အကျိုးဆက်)
8. Implementation (အကောင်အထည်ဖေါ်ဆောင်ရွက်မှုပုံစံ)
9. Sample Code (နမူနာ ကုဒ်)
10. Known Uses (ပြင်ပလောက ရဲ့ သုံးစွဲမှုများ)
11. Related Patterns (ဆက်စပ်ပုံစံများ)
ဆိုပြီးဖြစ်ပါတယ်။
ကဲ ဒီတော့ ပထမဆုံး အနေနဲ Creational patterns အုပ်စုထဲက အတော်အတန် ရိုးရှင်းလွယ်ကူတဲ့ Factory Design Pattern အကြောင်းကို ကျွန်တော်တို စတင်လေ့လာကြည့်ကြပါစို ။ တကယ်တော့ မိတ်ဆွေတို သိတဲ့အတိုင်း အထက်မှာတင်ပြခဲ့သလိုပဲ creational design pattern ဆိုတာ “ဆော့ဖ်၀ဲစနစ်တခုအတွင်းမှာ၊ ကိုယ်လိုအပ်တဲ့ အခြေအနေနဲ သင့်တော်မယ့် လိုက်လျောညီထွေဖြစ်မယ့် object ကို ဘယ်လို တည်ဆောက်မလဲ ဆိုတဲ့ object တည်ဆောက်တဲ့ နည်းစနစ်တွေနဲ ပတ်သက်ပြီး အထူးပြုလေ့လာတဲ့ ဒီဇိုင်းပုံစံ” တခုပါ။ “ဒီ object ဆာက်တာများ ဘာဆန်းလို ဒီလို တကူးတက တသီးတသန် ကြီး လုပ်နေရတာတုန်း” လို မိတ်ဆွေတို ထင်ကောင်းထင်ပါလိမ့်မယ်။ တကယ်တော့ ဒီဇိုင်းပိုင်းဆိုင်ရာပြဿနာတွေနဲ ဒီဇိုင်းရှုပ်ထွေးမှုကိုဖြစ်စေတာ အဲဒီ object တည်ဆောက်တဲ့ အခြေခံပုံစံတွေ ကိုယ်တိုင်ပါပဲ။ ဒါကြောင့် object တည်ဆောက်ပုံကို ထိန်းချုပ်တဲ့ ဒီ creational design pattern တွကို software complexity ကို လျာ့ချနိုင်ဖို နဲ ဆာ့ဖ်၀ဲဒီဇိုင်းပိုင်းဆိုင်ရာပြဿနာတွေ ဖရှင်းနိုင်ဖို အသုံးချနိုင်ပါတယ်။
Factory Design Pattern
Object တည်ဆောက်နိုင်ဖို အတွက် interface တစ်ခုကို ဖန်တီးပေးထားပါတယ်။ ဒါပေမယ့် ဘယ် object ကို ဆာက်မလဲဆိုတာတော့ sub-class, child-class တွကို ရွးချယ် ဆုံးဖြတ်ခွင့် ပးထားပါတယ်။ ဒီ factory method ကို virtual constructor လို လဲ လူသိများပါတယ်။ ဘာလို လဲဆိုတော့ ဒီ pattern ဟာ constructor ကို အစားထိုးဖို အတွက်သုံးတာဖြစ်လို ပါ။ ပီးတော့လည်း ဒီ ဒီဇိုင်းပုံစံဟာ object တွကို create လုပ်ရာမှာ design time မှာထက် run time ရာက်မှ instantiate လုပ်ခွင့်ပေးထားတဲ့အတွက်၊ class ရဲ့ object creation ကို ကြိုတင်ပြီး ပုံသေ သတ်မှတ်ထားတာမျိုးမဟုတ်ပဲ၊ လိုအပ်တော့မှ လိုအပ်သလို ထိန်းချုပ်တည်ဆောက်တာမျိုးဖြစ်ပါတယ်။
using System;
usingSystem.Collections.Generic;
namespaceInfoTherapy.DesignPattern.Factory
{
public interface IEmployee
{
doubleSalary { get; }
}
public class ProjectManager: IEmployee
{
public double Salary
{
get{ return 100.00; }
}
}
public class Developer : IEmployee
{
public double Salary
{
get { return 75.00; }
}
}
public class DBA : IEmployee
{
public double Salary
{
get{ return 70.00; }
}
}
public class EmployeeFactory
{
public enum EmployeeType
{
ProjectManager,
Developer,
DBA
}
public static IEmployeegetEmployee(EmployeeType empType)
{
IEmployeeemployee = null;
switch(empType)
{
case EmployeeType.ProjectManager:
employee = new ProjectManager();
break;
caseEmployeeType.Developer:
employee = new Developer();
break;
caseEmployeeType.DBA:
employee = new DBA();
break;
default:
thrownew ArgumentException(string.Format(
"An employee of type {0} cannot be found",
Enum.GetName(typeof(EmployeeType), empType)));
}
returnemployee;
}
}
class FactoryDPDemo
{
static void Main(string[] args)
{
Dictionary<EmployeeFactory.EmployeeType, IEmployee> employees =
newDictionary<EmployeeFactory.EmployeeType, IEmployee>();
//let's create a new employee for each available employee type.
//Each item is insatantiated without the client needing to know
//what type of object is being created.
//this is handled by the factory method
foreach(EmployeeFactory.EmployeeTypeeType in
Enum.GetValues(typeof(EmployeeFactory.EmployeeType)))
{
employees.Add(eType, EmployeeFactory.getEmployee(eType));
}
//now let's iterate through our dictionary and
//diplay the base salary for each factory object
foreach(EmployeeFactory.EmployeeTypetype in employees.Keys)
Console.WriteLine(string.Format(
"The basic salary for {0} is {1:C} per hour.",
type, employees[type].Salary));
Console.ReadKey();
}
}
}
ဆက်လက်တင်ပြပါမည်။
ရွှင်လန်းချမ်းမြေ့ပါစေ။
infoTherapy-2015
Thursday, May 29, 2014
Finding the Roots of an Equation
WHAT
"Root" is a more formal way to say "answer" or "solution". A number is called a root of an equation if when the number is substituted into the equation and both sides simplified, the result is an identity, such as 2=2 or 8=8, etc.
Or
The root of a one dimensional equation is the value of x for which the equation y=f(x)=0.
Example 1
There are two roots to this equation x²+6=5x
They are 3 and 2.
3 is one root because when you substitute 3 for x
3²+6=5(3)
9+6=15
15=15
Also 2 is a root, because when you substitute 2 for x
2²+6=5(2)
4+6=10
10=10
Example 2
The root value for the given equation y = f(x) = 10x2 + 31x - 14 is "0.4"
because if we substitute the root value "0.4" to the equation and we get zero.
(10 * (0.4)^2) + (31 * 0.4) -14 = 0
WHY
One might ask what this has to do with chemistry or science, etc. There are many examples of chemical problems in which one needs to find the roots of equations. Some of the chemical examples include
HOW
So, now is the time to ask how do we fine the roots for the given equation?
1. Newton’s method (Newton-Raphson method)
Newton’s method consists of four steps:
1. Guess a value of the root, x.
2. Calculate f(x) and the derivative f’(x), i.e., df(x)/dx
3.
4. Iterate
[to be continued...]
"Root" is a more formal way to say "answer" or "solution". A number is called a root of an equation if when the number is substituted into the equation and both sides simplified, the result is an identity, such as 2=2 or 8=8, etc.
Or
The root of a one dimensional equation is the value of x for which the equation y=f(x)=0.
Example 1
There are two roots to this equation x²+6=5x
They are 3 and 2.
3 is one root because when you substitute 3 for x
3²+6=5(3)
9+6=15
15=15
Also 2 is a root, because when you substitute 2 for x
2²+6=5(2)
4+6=10
10=10
Example 2
The root value for the given equation y = f(x) = 10x2 + 31x - 14 is "0.4"
because if we substitute the root value "0.4" to the equation and we get zero.
(10 * (0.4)^2) + (31 * 0.4) -14 = 0
WHY
One might ask what this has to do with chemistry or science, etc. There are many examples of chemical problems in which one needs to find the roots of equations. Some of the chemical examples include
- · Weak acid/base equilibria; titrations
- · The vapor pressure equation, ln P = A + (B/T) + C ln T
- · Equation of state problems
- · Equilibrium calculations
- · Quantum mechanics
- · Kinetics
HOW
So, now is the time to ask how do we fine the roots for the given equation?
1. Newton’s method (Newton-Raphson method)
Newton’s method consists of four steps:
1. Guess a value of the root, x.
2. Calculate f(x) and the derivative f’(x), i.e., df(x)/dx
3.
4. Iterate
[to be continued...]
Monday, January 6, 2014
ကွန်ပြူတာသိပ္ပံ ၌ သင်္ချာ၏အခန်းကဏ္ဌ
မိတ်ဆက်နိဒါန်း
ကျွန်တော်ဟာ programming, software engineering နဲ computer science ပညာရပ်တွေနဲ ပတ်သက်ပြီး နီးစပ်ရာ လူငယ်တွေနဲ တွ ဆုံဆွေးနွေးတဲ့အခါ “သင်္ချာပညာရပ်ဟာ ကွန်ပြူတာသိပ္ပံရဲ့ အခြေခံအုတ်မြစ်တွေထဲကတခုဖြစ်ကြောင်း၊ အဲဒါအပြင် ကွန်ပြူတာသိပ္ပံအတွက် အလွန်အရေးကြီးတဲ့ အစိပ်အပိုင်းတွေထဲက တခုဖြစ်ကြောင်း၊ ဒါကြောင့် အိုင်တီသမား လူငယ်တွေအနေနဲ သင်္ချာကို အလေးလား လ့လာသင့်ကြောင်း” တင်ပြလေ့ရှိပါတယ်။ အဲဒီအခါမှာ တချို က သင်္ချာရဲ့အရေးပါမှု၊ သူ ရဲ့အကျိုးသက်ရောက်မှုနဲ ပတ်သက်ပြီး ပန်လှန်မေးခွန်းထုတ်တာ ဆွးနွေးတာကို ကြုံရပါတယ်။ “ကျုပ်တို လည်း programming, software engineering, computer science ဘာသာရပ်တွေ အသုံးပြုပြီး ရးနေ သားနေ အလုပ် လုပ်နေသူတွေပါ။ ကျာင်းမှာတော့ ကွန်ပြူတာသိပ္ပံဘာသာအတွက် သင်္ချာကို အထိုက်အလျောက် သင်ခဲ့ရပေမယ့် ကျုပ်တို ရဲ့ လုပ်ငန်းခွင်တွေမှာတော့ သင်္ချာဆိုတာကို တသီးတသန် တခန်းတနားကြီး အသုံးပြုနေတာမတွေ ရပါဘူး။ ခင်ဗျားပြောသလိုဆိုရင် သင်္ချာကို ဘယ်လိုနေရာမျိုးတွေမှာ ဘယ်လောက်အတိုင်းအတာအထိ ဘယ်သူတွေက ဘယ်လိုအသုံးချနေကြတာလဲဗျ” ဆိုတာပါ။ တချို ကဆိုရင် “ပရိုဂရမ်မာ ဆာ့ဖ်၀ဲအင်ဂျင်နီယာဖြစ်ဖို သင်္ချာ ဒီလောက် မလိုပါဘူး။ သင်္ချာက ဘာမှ သိသိသာသာ အထောက်အကူမဖြစ်ဘူး။” လို ဆိုကြပါတယ်။ တကယ်တော့ ဒီဆောင်းပါးဟာ အဲဒီလို ငင်းချက်တွေအတွက် တတ်နိုင်သလောက် အတိုချုပ် ကျိုးစားရှင်းလင်းချက်တခုမျှသာဖြစ်ပါတယ်။
အမှန်တော့လည်း သာမန်လက်တွေ လုပ်ငန်းခွင် အများစုမှာတော့ သိပ်အဆင့်မြင့်တဲ့ သင်္ချာပညာရပ်တွေကို အမြဲတန်းကြီးအသုံးချ နတာမဟုတ်ပဲ အခြေခံ အက္ခရာသင်္ချာ ပညာရပ်လောက်ကိုသာ “ကျွဲကူးရေပါ” မသိမသာ သုံးနေတာဖြစ်ပါတယ်။ ဘယ်နေရာမှာလဲဆိုတာ့ ပရိုဂရမ်ရေးတဲ့နေရာမှာပါ။ ဒါပေမယ့် အထူးသတိပြုရမယ့်အချက်က ကွန်ပြူတာသိပ္ပံဆိုတာ ပရိုဂရမ်ရေးခြင်းဆို တဲ့ ဘာင်ကျဉ်းကျဉ်းလေးမဟုတ်ပါဘူး။ အကြောင်းအရာတွေ ထပ်နေမှာမလိုလားတဲ့အတွက်၊ ၂၀၁၃ ဂျွန်လိုင်လထုတ် ကွန်ပြူတာဂျာနယ်မှာ ဖါ်ပြခဲ့တဲ့ ‘ကွန်ပြူတာသိပ္ပံ နှင့် ကိုင်းကွဲပညာရပ်များ’ ဆိုတဲ့ ဆာင်းပါးကိုသာ ပန်လည်ဖတ်ရှုကြည့်ပါလို ရည်ညွှန်းပါရစေ။
တကယ်တော့ အာင်မြင်တဲ့ ကွန်ပြူတာသိပ္ပံပညာရှင်တရောက် ဖစ်နိုင်ဖို အတွက် အသုံးချသင်္ချာပညာတွေဖြစ်တဲ့ အစုသီအိုရီ (Sets Theory), ဖစ်နိုင်ခြေသီအိုရီ (Probability Theory), ကိန်းသီအိုရီ(Number Theory) နဲ ဘူးလ် ရဲ့ အက္ခရာသင်္ချာ (Boolean Algebra) ပညာရပ်တွေဟာ မရှိမဖြစ်တွေပါ။ ကွန်ပြူတာသိပ္ပံပညာရှင်တရောက်ဟာ သူ အတွက် သင့်လျော်မယ့် လိုအပ်မယ့် သင်္ချာပညာရပ်တွေကို ထဲထဲ၀င်၀င် ကျွမ်းကျင်မှုမရှိဘူးဆိုရင် သူ ကို computer scientist လို တာင် ခါ်နိုင်မှာမဟုတ်ပါဘူး။ ဘာလို လဲဆိုတာကို ရှ လျှာက် ဆက်လက်တင်ပြမယ့် အပိုင်းတွေမှာ မိတ်ဆွေတို အထင်အရှား တွ မင်ရမှာဖြစ်ပါတယ်။ သတိပြုသင့်တဲ့အချက်ကတော့ ကွန်ပြူတာသိပ္ပံမှာ ဘယ်လိုသင်္ချာအမျိုးအစားကို ဘယ်လောက်အတိုင်းအတာအထိ အသုံးချကြသလဲဆိုတာက ကွန်ပြူတာသိပ္ပံပညာမဟာဌာန (Faculty of Computer Science) ကြီးရဲ့ ဌာနခွဲ (department) အမျိုးအစားတွေပေါ်မှာလည်း မူတည်မှာဖြစ်ပါတယ်။ Theoretical Computer Science, Software, Networking, Database, Operating Systems, Computing Systems, Artificial Intelligence စသည်ဖြင့် ဘာသာရပ်တွေ ဌာနတွေ ကွဲပြားသွားတာနဲ အမျှ၊ သူတို အသုံးပြုကြတဲ့ သင်္ချာကိုင်းကွဲ တွလည်း အနည်းနဲ အများ မတူခြားနားသွားမှာဖြစ်ပါတယ်။ ဘာပဲဖြစ်ဖြစ် သချာတာတခုကတော့ ကွန်ပြူတာသိပ္ပံရဲ့ ကိုင်းကွဲဘာသာရပ်တိုင်းမှာ သင်္ချာပညာကိုင်းကွဲတွေဟာ တခုမဟုတ် တခု၊ ဒါမှမဟုတ် တခုထက်ပိုပြီး အမြဲပါ၀င်နေမှာသာဖြစ်ပါတယ်။
၁။ Programming နှင့် သင်္ချာ
ပရိုဂရမ်ဘာသာစကားအားလုံးမှာရှိတဲ့ လုပ်ဆောင်ချက် (function) တွနဲ လုပ်ဆောင်ချက်ဆိုင်ရာ သငေ်္ကတ (operator) တွအကြောင်း ကာင်းကောင်းနားလည်နိုင်ဖို အတွက် သင်္ချာအခြေခံ အသိပညာတွေဟာ မဖြစ်မနေလိုအပ်ပါတယ်။ ဥပမာအနေနဲ ပရရင် ပရိုဂရမ်ဘာသာစကားတိုင်းမှာ ပါ၀င်သုံးစွဲထားတဲ့
• ပါင်း နှုတ် မှာက် စား အကြွင်း သငေ်္ကတတွေဖြစ်တဲ့ arithmetic operator (+, -, *, /, %)
• ကြီးသလား ငယ်သလား ညီသလား ဆိုတဲ့ comparison operator (>, <, ==)
• နှင့် ၊ သို မဟုတ် ၊ မဟုတ် ..စတာတွေ ပါ၀င်တဲ့ logical operator (and, or, not, &&, ||, !)
• တန်ဘိုးထည့်သွင်းရာမှာသုံးတဲ့ assignment operator (=, :=)
• တကယ်လို ဒါဖြစ်ရင် ဒါလုပ်၊ မဖြစ်ရင် ဒါလုပ် ဆိုတဲ့ အခြေအနေပြ conditional operator(if..else, ? .. :)
စတာတွေ အားလုံးဟာ သင်္ချာပညာကနေ ဆင်းသက်လာတဲ့ programming language တခုအတွက် တကယ့်အခြေခံ မရှိမဖြစ် သငေ်္ကတတွေပဲ မဟုတ်ပါလား။ အဲဒီထဲကမှ အထူးသဖြင့် arithmetic operator, logical operator နဲ conditional operator တွကို program ရးသားရာမှာ ကျွမ်းကျွမ်းကျင်ကျင် အသုံးချနိုင်ဖို အတွက်ဆိုရင် သူတို နဲ သက်ဆိုင်တဲ့ သင်္ချာအသိပညာကို ပိုင်နိုင်ထားရမှာဖြစ်ပါတယ်။
ပရိုဂရမ်(ဆော့ဖ်၀ဲ) ရးတဲ့နေရာမှာ ယုတ္တိဗေဒ(logic) ဟာ ဗဟိုချက်မ လိုအပ်ချက်ဖြစ်ပါတယ်။ အဲဒီ ယုတ္တိဗေဒပညာရပ်ဟာ သင်္ချာနဲ သင်္ချာပညာရပ်ဆိုင်ရာ စည်းမျဉ်း စည်းကမ်း နည်းလမ်း တွမှာ အခြေခံထားတာပါ။ ဒါဆိုရင်ရှင်းပါပြီ။ ဘယ်လို ရှုဒေါင့်ကပဲကြည့်ကြည့် သင်္ချာဟာ တွက်ချက်မှုပညာရပ် (computing) ကို အာင်မြင် မှန်ကန်တဲ့ လမ်းကြောင်းပေါ်ရောက်ဖို မရှိမဖြစ်ပဲ ဆိုတာတွေ ရမှာဖြစ်ပါတယ်။
Quicksort, Hoare Logic နဲ Communicating Sequential Process (CSP) စတာတွေကို တည်ထွင် ဖန်တီးခဲ့တဲ့၊ တားရင်းဆု(Turing Award)ရှင် အလွန်ထင်ရှားတဲ့ ဗိတိသျှ ကွန်ပြူတာသိပ္ပံပညာရှင် Sir Charles Antony Richard Hoare (born 11 January 1934) က
• ကွန်ပြူတာဆိုတာ သင်္ချာစက် (mathematical machine) တွဖြစ်တယ်။ (သူ ရဲ့ အပြုအမူ လုပ်ဆောင်ချက်တွေကို သင်္ချာနည်းနဲ သတ်မှတ်ထားတာဖြစ်တယ်။)
• ကွန်ပြူတာပရိုဂရမ်ဆိုတာ သင်္ချာဆိုင်ရာ ဖါ်ပြချက်တွေဖြစ်တယ်။ (ဘယ်ဟာက ဘာလဲဆိုတာကို တိတိကျကျ သတ်မှတ်ဖေါ်ပြထားရတယ်။)
• ပရိုဂရမ်ဘာသာစကားဆိုတာ သင်္ချာဆိုင်ရာ အတွေးအခေါ်အယူအဆ ဖစ်တယ်။
• ပရိုဂရမ်ရေးတယ်ဆိုတာ သင်္ချာတွက်တာပဲ။
လို ဆိုခဲ့ပါတယ်။
၂။ Software Engineering နှင့် သင်္ချာ
ပရိုဂရမ် စ’ ရးကာစ လူသစ်တန်းတွေအတွက် သင်္ချာက အရေးမကြီးသေးပေမယ့်၊ ရှုပ်ထွေး ခက်ခဲ နက်နဲတဲ့ ပရိုဂရမ်တွေ ရးတဲ့အဆင့်မျိုး ရာက်လာပြီဆိုရင်တော့ အဲဒီပရိုဂရမ်မာအနေနဲ အဆင့်မြင့်သင်္ချာတွေကို အသုံးမပြုလို ကို မရတော့တဲ့ အခြေအနေမျိုး ရာက်လာမှာ အသေအချာသာဖြစ်ပါတယ်။ အဆင့်မြင့် scientific calculators, video games နဲ 3-D Graphical applications တွ၊ Image Processing ဆာ့ဖ်၀ဲတွေဖြစ်တဲ့ မျက်နှာသွင်ပြင်ခွဲခြားတဲ့စနစ် (Face Recognition System) တို လက်ဗွေရာတွေကို တိုက်ဆိုင်စစ်ဆေးတဲ့စနစ် (Finger-Printing Matching System)တို လို ဆာ့ဖ်၀ဲတွေ၊ ရဒါစနစ် (Radar System) အချက်ပြစနစ် (signaling system) စတဲ့ program တွ software တွ ရးတော့မယ်ဆိုရင် ရှုပ်ထွေး အဆင့်မြင့်တဲ့ သင်္ချာပညာတွေမသုံးပဲ မသိပဲ ရးလို လုံး၀မရတော့ပါဘူး။
၃။ Relational Database နှင့် သင်္ချာ
ဒီကနေ ခတ်အခါမှာ database နဲ ကင်းလွတ်တဲ့ business application ရယ်လို မရှိပါဘူး။ အဲဒီလို အရေးပါလှတဲ့ database (relational database ပါ့ဗျာ) နည်းပညာတွေဟာ ဘယ်အပေါ်မှာ အခြေပြုပြီး တည်ထွင်ဖန်တီးတည်ဆောက်ထားတာဖြစ်ပါသလဲ။ အလွန်ပဲရှင်းပါတယ်။ မိတ်ဆွေတို ရဲ့ မရှိမဖြစ် RDBMS မှာ မသုံးမဖြစ်သုံးနေရတဲ့ စကားလုံးတွေဖြစ်တဲ့ one to one relation, one to many, many to many, စတဲ့ စကားလုံးတွေဟာ အစုသီအိုရီ (Set Theory) က စကားလုံးတွေဆိုတာ ဆယ်တန်းကျောင်းသားတောင်အလွယ်တကူသိနိုင်ပါတယ်။ ဒါ့အပြင် union, intersection, set difference, cartesian product or cross product စတဲ့ စကားလုံးတွေကရော။ ဒါ့အပြင် programmer တိုင်း၊ software engineer တိုင်း၊ developer တိုင်း မတတ်မဖြစ် မသိမဖြစ် Structured Query Language (SQL) ဆိုတာလည်း relational algebra နဲ relational calculus ဆိုင်ရာ အတွေးအခေါ် အယူအဆ သဘောတရားတွေကို အခြေပြုတည်ဆောက်ထားတာပါ။ relational calculus ဆိုတာ သင်္ချာယုတ္တိ(mathematical logic) ပညာရပ်တခုဖြစ်တဲ့ first-order logic နဲ predicate calculus ကို အခြေခံထားတာပါ။
၄။ ကွန်ပြူတာသိပ္ပံနှင့်သင်္ချာ
ကွန်ပြူတာသိပ္ပံဟာ ပဿနာဖြေရှင်းပုံ နည်းလမ်းအဆင့်ဆင့် (algorithm) နဲ ဆိုင်တဲ့ ပညာရပ်တွေကို အသေးစိပ် သရုပ်ခွဲ ဆန်းစစ်လေ့လာတဲ့ ပညာရပ်ဖြစ်ပြီး၊ အဲဒီ algorithm နဲ နှီးနွယ်ပတ်သက် ဆက်စပ်တဲ့ ပညာရပ်တွေဟာ သင်္ချာပညာပေါ်မှာ အကြီးအကျယ်မှီခိုနေတာဖြစ်ပါတယ်။ အထူးသဖြင့် သဘောတရားရေးရာ ကွန်ပြူတာသိပ္ပံ (Theoretical Computer Science) ပညာရပ်မှာဆိုရင် discrete mathematics ဟာ ခိုင်ခိုင်မာမာ ပါ၀င် နရာယူထားတာကိုတွေ ရမှာဖြစ်ပါတယ်။ Discrete Maths ဆိုတာ တကယ်တော့ အစဉ်မပြတ် ဆက်တိုက်ဖြစ်ပျက်နေခြင်း သဘောတရားတွေထက်၊ အပိုင်းလိုက် အပိုင်းလိုက် သီးခြား ရှိနေတဲ့ ပတ်တောင်းဖြစ်စဉ်တွေ တန်ဘိုးတွေ ရလာဒ်တွေ ကို လ့လာတဲ့ သင်္ချာဖွဲ စည်းပုံတည်ဆောက်ပုံ တမျိုးပဲဖြစ်ပါတယ်။ Discrete Maths ရဲ့ အနှစ်သာရကို မိတ်ဆွေတို မင်သာအောင် ဥပမာပြရလျှင်၊ ကိန်းစဉ်တန်းတွေကို number line ပါ်မှာဖေါ်ပြတဲ့အခါ ကိန်းတခုကနေ နာက်တခုကို ချက်ခြင်းကြီး တိုက်ရိုက် ရာက်သွားတာ ပာင်းသွားတာမဟုတ်ဘူးဗျ။ ဆိုလိုတာကဗျာ 1 ကနေ 2 ကို သွားဖို ရာက်ဖို ဆိုရင်၊ 1.1, 1.2, 1.3, 1.4.. စသည်ဖြင့် တန်ဘိုးတွေ စဉ်ဆက်မပြတ် တဆင့်ခြင်း နဲနဲခြင်း တိုးတက်သွားပြီး မှ 2 ကိုရောက်လာတာ။ အဲဒီလို စဉ်ဆက်မပြတ်ဖြစ်ခြင်း သဘောတရားကို သုံးတဲ့သင်္ချာ (Continuous Maths) က calculus လို သင်္ချာမျိုး။ Discrete Maths က 1, 2, 3 ဆိုတဲ့ ကိန်းပြည့် (integer) တွကိုပဲ စိတ်၀င်စားတယ်။ ကြားတန်ဘိုးတွေကို စိတ်မ၀င်စားဘူး။ ခါင်းဆိုခေါင်း ပန်းဆိုပန်း ဒင်္ဂါးပြား ဒါင်လိုက်ဖြစ်နေမှာကို မစဉ်းစားဖူး၊ အမှန်ဆိုရင်လည်း အမှန် အမှားဆိုရင်လည်းအမှား နဲနဲမှန်တာတို များများမှန်တာတို ဆိုတဲ့ တဆင့်ခြင်း တိုးတက်ပြောင်းလဲလာတဲ့ ကြားသဘာ၀ တွကို မစဉ်းစားဘူး။ အဲဒီလို သီးသန် ပတ်တောင်း သဘောဆောင်လို သူ ကို Discrete Maths လို ခါ်တာ။ ကဲ ထားပါတော့။ ဒါကြောင့် သီအိုရီသဘောတရားရေးရာတွေကို အသားပေးလေ့လာတဲ့ အဲဒီ သီအိုရီကွန်ပြူတာသိပ္ပံ ပညာရပ်မှာဆိုရင် Discrete Maths ကိုင်းကွဲတွေဖြစ်တဲ့ Graph Theory, Set Theory, Probability Theory, Number Theory, Computational Geometry, Quantum Computation, Algebra နဲ တခြား အဆင့်မြင့် သင်္ချာဘာသာရပ်တွေ အများအပြားပါ၀င်နေတာဖြစ်ပါတယ်။
၅။ ကွန်ပြူတာသိပ္ပံ ရူပဗေဒ နှင့် သင်္ချာ
ကွန်ပြူတာတွေအလုပ်လုပ်တဲ့ ကျွန်တော်တို မျက်စိနဲ မမြင်ရတဲ့ binary system ဆိုတာလည်း တကယ်တော့ သင်္ချာ ပဲမဟုတ်လား။ အဲဒါကို တကယ့်လက်တွေ မှာ အကောင်အထည်ဖေါ်တဲ့ အခါ၊ ထရန်စ္စတာ (transitor) တွ ဆီလီကွန် (cilicon chip) ပားတွေအပေါ်မှာ လျှပ်စီးကြောင်း ရဲ့ အဖွင့် အပိတ် (on-off) သဘောတရားနဲ လုပ်ထားတာပဲ ဖစ်ပါတယ်။ အင်ဂျင်နီယာပညာရပ်အားလုံးရဲ့ ရသောက်မြစ်ဖြစ်တဲ့ အလင်း အသံ အပူ လျှပ်စစ် သံလိုက် မက္ကင်းနစ် အီလက်ထရွန်နစ် စတဲ့ ပညာရပ်တွေဟာ အားလုံးသိတဲ့အတိုင်း ရူပဗေဒပညာရပ်ရဲ့ ကိုင်းကွဲတွေပဲမဟုတ်ပါလား။ ဒါကြောင့် နာက်ထပ် အရေးကြီးတဲ့ အချက်တချက်ကတော့ ကွန်ပြူတာသိပ္ပံပညာရပ် ကိုင်းကွဲတချို မှာဆိုရင် ရူပဗေဒ (Physics) ပညာရပ်ဟာ အဓိက အခန်းကဏ္ဏက ပါ၀င်နေတယ် ဆိုတာ သိထားရပါမယ်။ ဥပမာ Computer Engineering, Computer Technology,
Hardware Engineering (processor, mother-board, memory, quantum memory ..စတာတွေ တည်ထွင် ထုတ်လုပ်ခြင်း)၊
System Engineering (ကွန်ပြူတာ network ပိုင်းသက်သက်ကို ပာတာမဟုတ်။ software, hardware, netware တွနဲ ပူးပေါင်းပါ၀င်ဖွဲ စည်းတည်ဆောက်ထားတဲ့၊ လယာဉ် ပျံသန်းမှု ထိမ်းချုပ်ရေးစနစ်တို ၊ ဘဏ်တွေနဲ ငွသွင်း ငွထုတ်စက် အကြွေး၀ယ် လက်ငင်း၀ယ် စနစ်တွေ ပါ၀င်ချိတ်ဆက်ထားတဲ့ Finicial Transaction System Management တို ၊ ကွန်ပြူတာနဲ ထိမ်းချုပ်ထားတဲ့ မို ပ သယ်ယူပို ဆာင်ရေးစနစ် ကား/ရထား..စသည်တို ကို ဆိုလိုတာ)၊
Networking Engineering (ဖြုတ်ရုံ တတ်ရုံ ၊ သူများရေးပြီးသား software တွ၊ သူများတည်ထွင်ပြီးသား netware တွကို ဟိုဟိုဒီဒီ configure လုပ်ရုံ အလုပ်မျိုးကို ဆိုလိုတာမဟုတ်ပါ။ controlling , signaling, data transmission စတဲ့ အဆင့်မြင့် စနစ်တွေကို တည်ဆောက်တဲ့ ပညာရပ်မျိုးကို ဆိုလိုတာ) စတဲ့ ကွန်ပြူတာသိပ္ပံရဲ့ တချို ကိုင်းကွဲ ပညာရပ်တွေမှာ ရူပဗေဒ ဟာ မရှိမဖြစ်ပညာရပ်တခုပေါ့။ တခါ ရူပဗေဒ နဲ သင်္ချာဆိုတာ အကြီးအကျယ် နှီးနွယ်ဆက်စပ် နတာဖြစ်ပါတယ်။ သင်္ချာမပါပဲ ရူပဗေဒကို ကုန်စင်ပြည့်စုံစွာ နားလည်အောင် လ့လာဖို ဆိုတာ ဘယ်လိုမှ မဖြစ်နိုင်ပါဘူး။ ဒါဆိုရင် ကွန်ပြူတာသိပ္ပံမှာ သင်္ချာပညာဟာ ဘယ်လောက်အထိ အရေးပါလှတယ်ဆိုတာ မိတ်ဆွေတို အနေနဲ ပိုပြီး ရှင်းရှင်းလင်းလင်း သိမြင်သွားပြီလို ယူဆပါတယ်။
လက်တွေ အခက်အခဲများ
သို သာ်.. အင်း..သို သာ်လည်းပေါ့ဗျာ။ မိတ်ဆွေတို ရဲ့ ပတ်၀န်းကျင်မှာ အမှန်တရား နဲ တကယ်ဖြစ်နေတာနဲ အမြဲတမ်း မတူနိုင်ဘူးဆိုတာကိုတော့ သတိထားမိမယ်ထင်ပါတယ်။ အဲဒီ သဘောပါပဲ။ ကွန်ပြူတာသိပ္ပံအတွက် သင်္ချာဟာ အဓိကနေရာက ပါ၀င်နေတယ်ဆိုတာက တကယ့်အမှန်တရားပါ ဒါပေမယ့် တကယ်ဖြစ်နေတာကတော့ တမျိုးဖြစ်ကောင်း ဖစ်နေနိုင်ပါတယ်။ “ပရိုဂရမ်မာ ဆာ့ဖ်၀ဲအင်ဂျင်နီယာဖြစ်ဖို သင်္ချာမလိုပါဘူးကွာ။ သင်္ချာက ဘာမှ သိသိသာသာ အထောက်အကူမဖြစ်ပါဘူး။” လို ပာသူတွေအတွက် ကျာထောက်နောက်ခံပြုလောက်စရာ လက်တွေ အခြေအနေတွေကလည်း အထင်အရှားရှိနေပြန်တာကိုး။ အကြောင်းရင်းတွေက အလွန်ပဲရှုပ်ထွေး ကျယ်ပြန် လှတဲ့ ပညာရေး စနစ်ရဲ့ အားနည်းချက်တွေမှာ မစ်ဖျားခံနေပါတယ်။
ပထမအချက်အနေနဲ ကတော့ ကျာင်းသူကျောင်းသားတွေကို သင်္ချာဘွဲ ဒီဂရီ ရအောင်ယူဖို ၊ သင်္ချာပညာရပ်ကို ထဲထဲ၀င်၀င် ထူးထူးချွန်ချွန်ဖြစ်အောင်လုပ်ဖို မက်လောက်တဲ့ တွန်းအားအနေနဲ ဘာမှထင်ထင်ရှားရှားမရှိတာက အကြောင်းတချက်ပဲဖြစ်ပါတယ်။ အဲဒီလို တွန်းအားမရှိတဲ့အတွက် ကျာင်းသားတွေဟာ သင်္ချာပညာရပ်ကို နက်နက်နဲနဲ လ့လာသင်ယူဖို လိုလိုလားလားမရှိတာ၊ လိုလိုလားလားမရှိခဲ့လို လုံလုံလောက်လောက် မပြင်ဆင်ခဲ့တာ၊ အဲဒီလို သင်္ချာပညာရပ်ကို အခြေခံကောင်းအောင် လုံလုံလောက်လောက် မပြင်ဆင်ခဲ့တာတွေရဲ့ နာက်ဆက်တွဲအကျိုးဆက်တွေအဖြစ်၊ ကျာင်းသူ ကျာင်းသားတွေရဲ့ တက္ကသိုလ် ဘာသာရပ် ရွးချယ်မှုပုံစံနဲ ၊ ရွးချယ်လိုက်တဲ့ ဘာသာရပ်အပေါ်မှာ နားလည်တတ်ကျွမ်းမှု အပေါ်မှာ သိသိသာသာ ရိုက်ခတ်လာပါတော့တယ်။
နောက်တချက်အနေနဲ ကျွန်တော်တို ရဲ့ အဆင့်မြင့်ပညာရေးစနစ်မှာ သင်္ချာကို သီးသန် ရပ်တည်နေတဲ့ ဘာသာရပ် (closed subject ) တခု အဖြစ်သင်ကြားပြီး၊ ကွန်ပြူတာသိပ္ပံကိုတော့ နည်းပညာဆိုင်ရာ ဘာသာရပ် (technical subject) တခုအဖြစ်သင်ကြားလာကြခြင်း ဖစ်ပါတယ်။ ဒါကြောင့် သင်္ချာဟာ တခြားပညာရပ်တွေနဲ ဆက်စပ်အသုံးချမရတဲ့ သီးသန် ထီးတည်း ပညာရပ်ကြီးအဖြစ် ရှုမြင်ခံရပြီး၊ ကွန်ပြူတာသိပ္ပံစစ်စစ် ဘွဲ ဒီဂရီတွေကျပြန်တော့ သိပ္ပံပညာရှင်(scientist)တို အင်ဂျင်နီယာ(engineer)တို လို အလုပ်မျိုးတွေအတွက် လိုအပ်တဲ့ တကယ့်အဆင့်မြင့်ပညာရေး (education) အဖြစ်ကနေ၊ နည်းပညာပိုင်း သက်သက်ကိုသာ လ့ကျင့်သင်ကြားပေးလိုက်တဲ့ (purely technical training) ဘွဲ တွအဖြစ် တဖြည်းဖြည်း တန်ဘိုး အသွင်ပြောင်းလာတာ တွ ရပါတယ်။ အကျိုးဆက်ကတော့ “သင်္ချာသမားက ကွန်ပြူတာသိပ္ပံကို ထဲထဲ၀င်၀င်မသိ၊ ကွန်ပြူတာသိပ္ပံသမားက သင်္ချာကို ခခြေမြစ်မြစ် မတတ်” ပဲ ပညာရပ်နှစ်ခုဟာ အစေးမကပ်ဖြစ်လာရပါတော့တယ်။ အဲဒီအခါမှာ ၀ိရောဓိတွေ ကြီးကြီးမားမား ဖစ်လာပြန်ပါတယ်။ တချို အလုပ်ရှင်တွေက “သင်္ချာသမားနဲ အင်ဂျင်နီယာတွေကိုပဲအလုပ်ခန် မယ်ဗျာ။ ကွန်ပြူတာသိပ္ပံနဲ ဘွဲ ရထားတဲ့သူတွေက ပဿနာကို ဘယ်လိုဖြေရှင်းရမလဲဆိုတာ မသိကြဘူးဗျ” လို ဆိုပါတယ်။ ဒါဟာဘာလို လဲဆိုတော့ အင်ဂျင်နီယာဘာသာရပ်တွေနဲ ၊ ရုပ်သိပ္ပံ(physical sciences) ဘာသာရပ်တွေမှာ သင်္ချာပညာကို ခိုင်ခိုင်မာမာ နာက်ခံထား သင်ကြားထားတဲ့အတွက်၊ သင်္ချာအခြေခံ အတွေးအခေါ် အားကောင်းတဲ့သူတွေဟာ ပဿနာကို ပိုပြီး ထိရောက်အောင်ဖြေရှင်းနိုင်တယ်လို ယူဆတာကိုး။ တခြားဖက်က ကြည့်ပြန်တော့လည်း တချို အလုပ်ရှင်တွေက “တကယ်တန်းကျတော့ သင်္ချာသမားတွေ ပဿနာဖြေရှင်းပြီဆိုရင် သူတို ဖရှင်းတဲ့ ပုံစံကို တခြားသူတွေ အလွယ်တကူ နားမလည်ကြဘူးဗျ။ သူတို ရဲ့ လုပ်ထုံးလုပ်နည်းတွေနဲ အဖြေတွေဟာ တခြား သင်္ချာသမားမဟုတ်သူတွေနဲ အဆင်ပြေပြေ မဆက်သွယ်နိုင်ဘူး (သင်္ချာသမားမဟုတ်သူတွေ နားမလည်နိုင်ဘူး)။ သူတို ရဲ့ဖြေရှင်းပုံတွေဟာ လက်တွေ လာကနဲ ကင်းကွာနေတယ်” လို ဆိုကြပြန်ပါတယ်။
အဲဒီ၀ိရောဓိတွေကြောင့်လည်း ဆန်းသစ်တည်ထွင်ဖန်တည်းမှု အားကောင်းတဲ့ သူတချို က သင်္ချာ နဲ ကွန်ပြူတာသိပ္ပံကို စာစောစီးစီး လမ်းခွဲလိုက်ကြတာ ဖစ်နိုင်ပါတယ်။ ဆိုလိုတာက တကယ့်အရည်အသွေးရှိတဲ့ သူတချို က ပုံမှန် ကွန်ပြူတာသိပ္ပံပညာရေးလမ်းကြောင်းကို အလေးအနက်မထားတော့ပဲ စွန် လွှတ်လိုက်တာ ကို ဆိုလိုတာပါ။ အထူးသဖြင့် ဆာ့ဖ်၀ဲသမားတွေပေါ့။ ဘာလို လဲဆိုတော့ အခုလက်ရှိအနေအထားအရ “ဆော့ဖ်၀ဲအင်ဂျင်နီယာဆိုတာ သီအိုရီတည်ဆောက်သူမဟုတ်ဘူး၊ နည်းလမ်းတွေကို အသုံးချသူသာဖြစ်တယ်..” လို ခံယူထားကြတဲ့့အပြင်၊ ဆာ့ဖ်၀ဲအင်ဂျင်နီယာလုပ်ငန်းမှာ နာက်ဆုံးအဆင့် ထွက်ကုန်(final product) ကိုသာ အဓိကထားပြီး၊ ဘယ်လိုသီအိုရီ ဘယ်လိုသဘောတရားရေးရာတွေကို အသုံးချခဲ့တယ် ဆိုတာကျတော့ များသောအားဖြင့် လျစ်လျူရှု ထားကြလို ပဲ ဖစ်ပါတယ်။ ဒါကြောင့် သင်္ချာကို အလေးအနက်မထားတဲ့ ဆာ့ဖ်၀ဲသမားတွေအနေနဲ ၊ လတ်တလော လုပ်ငန်းခွင်မှာ အဆင်ပြေပေမယ့်၊ ရရှည်မှာကျတော့ ဆာ့ဖ်၀ဲကျွမ်းကျင်လုပ်သား အဆင့်ကနေ ကွန်ပြူတာသိပ္ပံပညာရှင်အဆင့်ကို ဘယ်လိုမှ တက်မလာနိုင်တော့ပါဘူး။ တက်လာနိုင်ဖို လုံလောက်တဲ့ သီအိုရီ သဘောတရား နဲ နာက်ခံသင်္ချာပညာရပ်တွေမှ မရှိတာကိုး။ ပီးတော့လည်း သင်္ချာ ကွန်ပြူသိပ္ပံ နဲ တခြားပညာရပ်တွေ ကို ကိုယ်ပိုင်စိတ်ကူးစိတ်သန်းနဲ အချိုးညီညီ မပေါင်းစပ်နိုင်တဲ့အတွက် ဘယ်လိုအသစ်အဆန်းကိုမှ မယ်မယ်ရရ ထိထိရောက်ရောက် မတည်ထွင်နိုင်တော့ပါဘူး။
နိဂုံးအမှာ
ဆိုပါစို ဗျာ ကွန်ပြူတာသမားတွေအတွက် မန်မာစာအရေးကြီးသလားဆိုရင် အဖြေက “ကြံကြံ ဖန်ဖန်ဗျာ” အများစုက ဖကြမယ်ထင်ပါတယ်။ ဘယ်လိုမှ မဆက်စပ်ဘူးထင်ရတဲ့ အရာကိုပဲ ဆက်စပ်စဉ်းစားကြည့်ကြပါစို ။ နည်းပညာနဲ အထိအတွေ နည်းသူတွေကို အထောက်အကူပြုနိုင်ဖို (စေတနာကောင်း ရည်ရွယ်ချက်ကောင်းနဲ ) ရးသားထုတေ်၀တဲ့ တချို စာအုပ်တွေရဲ့ စာအုပ်မျက်နှာဖုံးမှာ software ဆိုတဲ့ အင်္ဂလိပ်စကားလုံးအတွက်(ထင်ပါရဲ့) မန်မာလို ‘ဆော့ဖ်၀ဲလ်’ ဆိုပြီး ရးသားထားတာတွေ မိတ်ဆွေတို တွ ဖူးမှာပါ။ ဒါကြောင့် ဒီ လို ရိုးရှင်းတွင်ကျယ်ပြီးသား software ဆိုတဲ့ စကားလုံးတလုံးကို တိုက်ရိုက်အသံဖလှယ်တာတောင် မူရင်းစကားလုံးနဲ နီးစပ်မှုမရှိဘူးဆိုရင်၊ ကျယ်ပြန် တဲ့ လးနက်တဲ့ ခက်ခဲတဲ့ ၀ါဟာရတွေကို မှန်ကန်အောင် ဖွင့်ဆိုရှင်းပြနိုင်လိမ့်မယ်လို တခြားနယ်ပယ်ကပုဂ္ဂိုလ်တွေ ပညာရှင်တွေက ဘယ် ကြည်ကြတော့မှာလဲ။ ........................................................................................
.................................
..........
............
ပညာသင်ကြားခြင်းရဲ့ ရည်ရွယ်ချက်က ကိုယ်ပိုင်ညာဏ်နဲ အမှန်အမှားကို စဉ်းစား ချင့်ချင် ၀ဖန် ပိုင်းခြားနိုင်ဖို ပဲ မဟုတ်ပါလား။
ရွှင်လန်းချမ်းမြေ့ပါစေ။
infoTherapy-2014
REF:
1. “Benefits and Advantages of an Integrated Mathematics and Computer Science Degree” By T.C. Hurley, Department of Mathematics, National University of Ireland, Galway, http://www.uiginn.com/maths/pstudents/benefits.shtml
2. "The Mathematics of Programming" By C.A.R Hoare, Inaugural Lecture, University of Oxford, Clarendon Press 1986 (The mathematics of programming: an inaugural lecture delivered before the University of Oxford on Oct. 17, 1985)
ကျွန်တော်ဟာ programming, software engineering နဲ computer science ပညာရပ်တွေနဲ ပတ်သက်ပြီး နီးစပ်ရာ လူငယ်တွေနဲ တွ ဆုံဆွေးနွေးတဲ့အခါ “သင်္ချာပညာရပ်ဟာ ကွန်ပြူတာသိပ္ပံရဲ့ အခြေခံအုတ်မြစ်တွေထဲကတခုဖြစ်ကြောင်း၊ အဲဒါအပြင် ကွန်ပြူတာသိပ္ပံအတွက် အလွန်အရေးကြီးတဲ့ အစိပ်အပိုင်းတွေထဲက တခုဖြစ်ကြောင်း၊ ဒါကြောင့် အိုင်တီသမား လူငယ်တွေအနေနဲ သင်္ချာကို အလေးလား လ့လာသင့်ကြောင်း” တင်ပြလေ့ရှိပါတယ်။ အဲဒီအခါမှာ တချို က သင်္ချာရဲ့အရေးပါမှု၊ သူ ရဲ့အကျိုးသက်ရောက်မှုနဲ ပတ်သက်ပြီး ပန်လှန်မေးခွန်းထုတ်တာ ဆွးနွေးတာကို ကြုံရပါတယ်။ “ကျုပ်တို လည်း programming, software engineering, computer science ဘာသာရပ်တွေ အသုံးပြုပြီး ရးနေ သားနေ အလုပ် လုပ်နေသူတွေပါ။ ကျာင်းမှာတော့ ကွန်ပြူတာသိပ္ပံဘာသာအတွက် သင်္ချာကို အထိုက်အလျောက် သင်ခဲ့ရပေမယ့် ကျုပ်တို ရဲ့ လုပ်ငန်းခွင်တွေမှာတော့ သင်္ချာဆိုတာကို တသီးတသန် တခန်းတနားကြီး အသုံးပြုနေတာမတွေ ရပါဘူး။ ခင်ဗျားပြောသလိုဆိုရင် သင်္ချာကို ဘယ်လိုနေရာမျိုးတွေမှာ ဘယ်လောက်အတိုင်းအတာအထိ ဘယ်သူတွေက ဘယ်လိုအသုံးချနေကြတာလဲဗျ” ဆိုတာပါ။ တချို ကဆိုရင် “ပရိုဂရမ်မာ ဆာ့ဖ်၀ဲအင်ဂျင်နီယာဖြစ်ဖို သင်္ချာ ဒီလောက် မလိုပါဘူး။ သင်္ချာက ဘာမှ သိသိသာသာ အထောက်အကူမဖြစ်ဘူး။” လို ဆိုကြပါတယ်။ တကယ်တော့ ဒီဆောင်းပါးဟာ အဲဒီလို ငင်းချက်တွေအတွက် တတ်နိုင်သလောက် အတိုချုပ် ကျိုးစားရှင်းလင်းချက်တခုမျှသာဖြစ်ပါတယ်။
အမှန်တော့လည်း သာမန်လက်တွေ လုပ်ငန်းခွင် အများစုမှာတော့ သိပ်အဆင့်မြင့်တဲ့ သင်္ချာပညာရပ်တွေကို အမြဲတန်းကြီးအသုံးချ နတာမဟုတ်ပဲ အခြေခံ အက္ခရာသင်္ချာ ပညာရပ်လောက်ကိုသာ “ကျွဲကူးရေပါ” မသိမသာ သုံးနေတာဖြစ်ပါတယ်။ ဘယ်နေရာမှာလဲဆိုတာ့ ပရိုဂရမ်ရေးတဲ့နေရာမှာပါ။ ဒါပေမယ့် အထူးသတိပြုရမယ့်အချက်က ကွန်ပြူတာသိပ္ပံဆိုတာ ပရိုဂရမ်ရေးခြင်းဆို တဲ့ ဘာင်ကျဉ်းကျဉ်းလေးမဟုတ်ပါဘူး။ အကြောင်းအရာတွေ ထပ်နေမှာမလိုလားတဲ့အတွက်၊ ၂၀၁၃ ဂျွန်လိုင်လထုတ် ကွန်ပြူတာဂျာနယ်မှာ ဖါ်ပြခဲ့တဲ့ ‘ကွန်ပြူတာသိပ္ပံ နှင့် ကိုင်းကွဲပညာရပ်များ’ ဆိုတဲ့ ဆာင်းပါးကိုသာ ပန်လည်ဖတ်ရှုကြည့်ပါလို ရည်ညွှန်းပါရစေ။
တကယ်တော့ အာင်မြင်တဲ့ ကွန်ပြူတာသိပ္ပံပညာရှင်တရောက် ဖစ်နိုင်ဖို အတွက် အသုံးချသင်္ချာပညာတွေဖြစ်တဲ့ အစုသီအိုရီ (Sets Theory), ဖစ်နိုင်ခြေသီအိုရီ (Probability Theory), ကိန်းသီအိုရီ(Number Theory) နဲ ဘူးလ် ရဲ့ အက္ခရာသင်္ချာ (Boolean Algebra) ပညာရပ်တွေဟာ မရှိမဖြစ်တွေပါ။ ကွန်ပြူတာသိပ္ပံပညာရှင်တရောက်ဟာ သူ အတွက် သင့်လျော်မယ့် လိုအပ်မယ့် သင်္ချာပညာရပ်တွေကို ထဲထဲ၀င်၀င် ကျွမ်းကျင်မှုမရှိဘူးဆိုရင် သူ ကို computer scientist လို တာင် ခါ်နိုင်မှာမဟုတ်ပါဘူး။ ဘာလို လဲဆိုတာကို ရှ လျှာက် ဆက်လက်တင်ပြမယ့် အပိုင်းတွေမှာ မိတ်ဆွေတို အထင်အရှား တွ မင်ရမှာဖြစ်ပါတယ်။ သတိပြုသင့်တဲ့အချက်ကတော့ ကွန်ပြူတာသိပ္ပံမှာ ဘယ်လိုသင်္ချာအမျိုးအစားကို ဘယ်လောက်အတိုင်းအတာအထိ အသုံးချကြသလဲဆိုတာက ကွန်ပြူတာသိပ္ပံပညာမဟာဌာန (Faculty of Computer Science) ကြီးရဲ့ ဌာနခွဲ (department) အမျိုးအစားတွေပေါ်မှာလည်း မူတည်မှာဖြစ်ပါတယ်။ Theoretical Computer Science, Software, Networking, Database, Operating Systems, Computing Systems, Artificial Intelligence စသည်ဖြင့် ဘာသာရပ်တွေ ဌာနတွေ ကွဲပြားသွားတာနဲ အမျှ၊ သူတို အသုံးပြုကြတဲ့ သင်္ချာကိုင်းကွဲ တွလည်း အနည်းနဲ အများ မတူခြားနားသွားမှာဖြစ်ပါတယ်။ ဘာပဲဖြစ်ဖြစ် သချာတာတခုကတော့ ကွန်ပြူတာသိပ္ပံရဲ့ ကိုင်းကွဲဘာသာရပ်တိုင်းမှာ သင်္ချာပညာကိုင်းကွဲတွေဟာ တခုမဟုတ် တခု၊ ဒါမှမဟုတ် တခုထက်ပိုပြီး အမြဲပါ၀င်နေမှာသာဖြစ်ပါတယ်။
၁။ Programming နှင့် သင်္ချာ
ပရိုဂရမ်ဘာသာစကားအားလုံးမှာရှိတဲ့ လုပ်ဆောင်ချက် (function) တွနဲ လုပ်ဆောင်ချက်ဆိုင်ရာ သငေ်္ကတ (operator) တွအကြောင်း ကာင်းကောင်းနားလည်နိုင်ဖို အတွက် သင်္ချာအခြေခံ အသိပညာတွေဟာ မဖြစ်မနေလိုအပ်ပါတယ်။ ဥပမာအနေနဲ ပရရင် ပရိုဂရမ်ဘာသာစကားတိုင်းမှာ ပါ၀င်သုံးစွဲထားတဲ့
• ပါင်း နှုတ် မှာက် စား အကြွင်း သငေ်္ကတတွေဖြစ်တဲ့ arithmetic operator (+, -, *, /, %)
• ကြီးသလား ငယ်သလား ညီသလား ဆိုတဲ့ comparison operator (>, <, ==)
• နှင့် ၊ သို မဟုတ် ၊ မဟုတ် ..စတာတွေ ပါ၀င်တဲ့ logical operator (and, or, not, &&, ||, !)
• တန်ဘိုးထည့်သွင်းရာမှာသုံးတဲ့ assignment operator (=, :=)
• တကယ်လို ဒါဖြစ်ရင် ဒါလုပ်၊ မဖြစ်ရင် ဒါလုပ် ဆိုတဲ့ အခြေအနေပြ conditional operator(if..else, ? .. :)
စတာတွေ အားလုံးဟာ သင်္ချာပညာကနေ ဆင်းသက်လာတဲ့ programming language တခုအတွက် တကယ့်အခြေခံ မရှိမဖြစ် သငေ်္ကတတွေပဲ မဟုတ်ပါလား။ အဲဒီထဲကမှ အထူးသဖြင့် arithmetic operator, logical operator နဲ conditional operator တွကို program ရးသားရာမှာ ကျွမ်းကျွမ်းကျင်ကျင် အသုံးချနိုင်ဖို အတွက်ဆိုရင် သူတို နဲ သက်ဆိုင်တဲ့ သင်္ချာအသိပညာကို ပိုင်နိုင်ထားရမှာဖြစ်ပါတယ်။
ပရိုဂရမ်(ဆော့ဖ်၀ဲ) ရးတဲ့နေရာမှာ ယုတ္တိဗေဒ(logic) ဟာ ဗဟိုချက်မ လိုအပ်ချက်ဖြစ်ပါတယ်။ အဲဒီ ယုတ္တိဗေဒပညာရပ်ဟာ သင်္ချာနဲ သင်္ချာပညာရပ်ဆိုင်ရာ စည်းမျဉ်း စည်းကမ်း နည်းလမ်း တွမှာ အခြေခံထားတာပါ။ ဒါဆိုရင်ရှင်းပါပြီ။ ဘယ်လို ရှုဒေါင့်ကပဲကြည့်ကြည့် သင်္ချာဟာ တွက်ချက်မှုပညာရပ် (computing) ကို အာင်မြင် မှန်ကန်တဲ့ လမ်းကြောင်းပေါ်ရောက်ဖို မရှိမဖြစ်ပဲ ဆိုတာတွေ ရမှာဖြစ်ပါတယ်။
Quicksort, Hoare Logic နဲ Communicating Sequential Process (CSP) စတာတွေကို တည်ထွင် ဖန်တီးခဲ့တဲ့၊ တားရင်းဆု(Turing Award)ရှင် အလွန်ထင်ရှားတဲ့ ဗိတိသျှ ကွန်ပြူတာသိပ္ပံပညာရှင် Sir Charles Antony Richard Hoare (born 11 January 1934) က
• ကွန်ပြူတာဆိုတာ သင်္ချာစက် (mathematical machine) တွဖြစ်တယ်။ (သူ ရဲ့ အပြုအမူ လုပ်ဆောင်ချက်တွေကို သင်္ချာနည်းနဲ သတ်မှတ်ထားတာဖြစ်တယ်။)
• ကွန်ပြူတာပရိုဂရမ်ဆိုတာ သင်္ချာဆိုင်ရာ ဖါ်ပြချက်တွေဖြစ်တယ်။ (ဘယ်ဟာက ဘာလဲဆိုတာကို တိတိကျကျ သတ်မှတ်ဖေါ်ပြထားရတယ်။)
• ပရိုဂရမ်ဘာသာစကားဆိုတာ သင်္ချာဆိုင်ရာ အတွေးအခေါ်အယူအဆ ဖစ်တယ်။
• ပရိုဂရမ်ရေးတယ်ဆိုတာ သင်္ချာတွက်တာပဲ။
လို ဆိုခဲ့ပါတယ်။
၂။ Software Engineering နှင့် သင်္ချာ
ပရိုဂရမ် စ’ ရးကာစ လူသစ်တန်းတွေအတွက် သင်္ချာက အရေးမကြီးသေးပေမယ့်၊ ရှုပ်ထွေး ခက်ခဲ နက်နဲတဲ့ ပရိုဂရမ်တွေ ရးတဲ့အဆင့်မျိုး ရာက်လာပြီဆိုရင်တော့ အဲဒီပရိုဂရမ်မာအနေနဲ အဆင့်မြင့်သင်္ချာတွေကို အသုံးမပြုလို ကို မရတော့တဲ့ အခြေအနေမျိုး ရာက်လာမှာ အသေအချာသာဖြစ်ပါတယ်။ အဆင့်မြင့် scientific calculators, video games နဲ 3-D Graphical applications တွ၊ Image Processing ဆာ့ဖ်၀ဲတွေဖြစ်တဲ့ မျက်နှာသွင်ပြင်ခွဲခြားတဲ့စနစ် (Face Recognition System) တို လက်ဗွေရာတွေကို တိုက်ဆိုင်စစ်ဆေးတဲ့စနစ် (Finger-Printing Matching System)တို လို ဆာ့ဖ်၀ဲတွေ၊ ရဒါစနစ် (Radar System) အချက်ပြစနစ် (signaling system) စတဲ့ program တွ software တွ ရးတော့မယ်ဆိုရင် ရှုပ်ထွေး အဆင့်မြင့်တဲ့ သင်္ချာပညာတွေမသုံးပဲ မသိပဲ ရးလို လုံး၀မရတော့ပါဘူး။
၃။ Relational Database နှင့် သင်္ချာ
ဒီကနေ ခတ်အခါမှာ database နဲ ကင်းလွတ်တဲ့ business application ရယ်လို မရှိပါဘူး။ အဲဒီလို အရေးပါလှတဲ့ database (relational database ပါ့ဗျာ) နည်းပညာတွေဟာ ဘယ်အပေါ်မှာ အခြေပြုပြီး တည်ထွင်ဖန်တီးတည်ဆောက်ထားတာဖြစ်ပါသလဲ။ အလွန်ပဲရှင်းပါတယ်။ မိတ်ဆွေတို ရဲ့ မရှိမဖြစ် RDBMS မှာ မသုံးမဖြစ်သုံးနေရတဲ့ စကားလုံးတွေဖြစ်တဲ့ one to one relation, one to many, many to many, စတဲ့ စကားလုံးတွေဟာ အစုသီအိုရီ (Set Theory) က စကားလုံးတွေဆိုတာ ဆယ်တန်းကျောင်းသားတောင်အလွယ်တကူသိနိုင်ပါတယ်။ ဒါ့အပြင် union, intersection, set difference, cartesian product or cross product စတဲ့ စကားလုံးတွေကရော။ ဒါ့အပြင် programmer တိုင်း၊ software engineer တိုင်း၊ developer တိုင်း မတတ်မဖြစ် မသိမဖြစ် Structured Query Language (SQL) ဆိုတာလည်း relational algebra နဲ relational calculus ဆိုင်ရာ အတွေးအခေါ် အယူအဆ သဘောတရားတွေကို အခြေပြုတည်ဆောက်ထားတာပါ။ relational calculus ဆိုတာ သင်္ချာယုတ္တိ(mathematical logic) ပညာရပ်တခုဖြစ်တဲ့ first-order logic နဲ predicate calculus ကို အခြေခံထားတာပါ။
၄။ ကွန်ပြူတာသိပ္ပံနှင့်သင်္ချာ
ကွန်ပြူတာသိပ္ပံဟာ ပဿနာဖြေရှင်းပုံ နည်းလမ်းအဆင့်ဆင့် (algorithm) နဲ ဆိုင်တဲ့ ပညာရပ်တွေကို အသေးစိပ် သရုပ်ခွဲ ဆန်းစစ်လေ့လာတဲ့ ပညာရပ်ဖြစ်ပြီး၊ အဲဒီ algorithm နဲ နှီးနွယ်ပတ်သက် ဆက်စပ်တဲ့ ပညာရပ်တွေဟာ သင်္ချာပညာပေါ်မှာ အကြီးအကျယ်မှီခိုနေတာဖြစ်ပါတယ်။ အထူးသဖြင့် သဘောတရားရေးရာ ကွန်ပြူတာသိပ္ပံ (Theoretical Computer Science) ပညာရပ်မှာဆိုရင် discrete mathematics ဟာ ခိုင်ခိုင်မာမာ ပါ၀င် နရာယူထားတာကိုတွေ ရမှာဖြစ်ပါတယ်။ Discrete Maths ဆိုတာ တကယ်တော့ အစဉ်မပြတ် ဆက်တိုက်ဖြစ်ပျက်နေခြင်း သဘောတရားတွေထက်၊ အပိုင်းလိုက် အပိုင်းလိုက် သီးခြား ရှိနေတဲ့ ပတ်တောင်းဖြစ်စဉ်တွေ တန်ဘိုးတွေ ရလာဒ်တွေ ကို လ့လာတဲ့ သင်္ချာဖွဲ စည်းပုံတည်ဆောက်ပုံ တမျိုးပဲဖြစ်ပါတယ်။ Discrete Maths ရဲ့ အနှစ်သာရကို မိတ်ဆွေတို မင်သာအောင် ဥပမာပြရလျှင်၊ ကိန်းစဉ်တန်းတွေကို number line ပါ်မှာဖေါ်ပြတဲ့အခါ ကိန်းတခုကနေ နာက်တခုကို ချက်ခြင်းကြီး တိုက်ရိုက် ရာက်သွားတာ ပာင်းသွားတာမဟုတ်ဘူးဗျ။ ဆိုလိုတာကဗျာ 1 ကနေ 2 ကို သွားဖို ရာက်ဖို ဆိုရင်၊ 1.1, 1.2, 1.3, 1.4.. စသည်ဖြင့် တန်ဘိုးတွေ စဉ်ဆက်မပြတ် တဆင့်ခြင်း နဲနဲခြင်း တိုးတက်သွားပြီး မှ 2 ကိုရောက်လာတာ။ အဲဒီလို စဉ်ဆက်မပြတ်ဖြစ်ခြင်း သဘောတရားကို သုံးတဲ့သင်္ချာ (Continuous Maths) က calculus လို သင်္ချာမျိုး။ Discrete Maths က 1, 2, 3 ဆိုတဲ့ ကိန်းပြည့် (integer) တွကိုပဲ စိတ်၀င်စားတယ်။ ကြားတန်ဘိုးတွေကို စိတ်မ၀င်စားဘူး။ ခါင်းဆိုခေါင်း ပန်းဆိုပန်း ဒင်္ဂါးပြား ဒါင်လိုက်ဖြစ်နေမှာကို မစဉ်းစားဖူး၊ အမှန်ဆိုရင်လည်း အမှန် အမှားဆိုရင်လည်းအမှား နဲနဲမှန်တာတို များများမှန်တာတို ဆိုတဲ့ တဆင့်ခြင်း တိုးတက်ပြောင်းလဲလာတဲ့ ကြားသဘာ၀ တွကို မစဉ်းစားဘူး။ အဲဒီလို သီးသန် ပတ်တောင်း သဘောဆောင်လို သူ ကို Discrete Maths လို ခါ်တာ။ ကဲ ထားပါတော့။ ဒါကြောင့် သီအိုရီသဘောတရားရေးရာတွေကို အသားပေးလေ့လာတဲ့ အဲဒီ သီအိုရီကွန်ပြူတာသိပ္ပံ ပညာရပ်မှာဆိုရင် Discrete Maths ကိုင်းကွဲတွေဖြစ်တဲ့ Graph Theory, Set Theory, Probability Theory, Number Theory, Computational Geometry, Quantum Computation, Algebra နဲ တခြား အဆင့်မြင့် သင်္ချာဘာသာရပ်တွေ အများအပြားပါ၀င်နေတာဖြစ်ပါတယ်။
၅။ ကွန်ပြူတာသိပ္ပံ ရူပဗေဒ နှင့် သင်္ချာ
ကွန်ပြူတာတွေအလုပ်လုပ်တဲ့ ကျွန်တော်တို မျက်စိနဲ မမြင်ရတဲ့ binary system ဆိုတာလည်း တကယ်တော့ သင်္ချာ ပဲမဟုတ်လား။ အဲဒါကို တကယ့်လက်တွေ မှာ အကောင်အထည်ဖေါ်တဲ့ အခါ၊ ထရန်စ္စတာ (transitor) တွ ဆီလီကွန် (cilicon chip) ပားတွေအပေါ်မှာ လျှပ်စီးကြောင်း ရဲ့ အဖွင့် အပိတ် (on-off) သဘောတရားနဲ လုပ်ထားတာပဲ ဖစ်ပါတယ်။ အင်ဂျင်နီယာပညာရပ်အားလုံးရဲ့ ရသောက်မြစ်ဖြစ်တဲ့ အလင်း အသံ အပူ လျှပ်စစ် သံလိုက် မက္ကင်းနစ် အီလက်ထရွန်နစ် စတဲ့ ပညာရပ်တွေဟာ အားလုံးသိတဲ့အတိုင်း ရူပဗေဒပညာရပ်ရဲ့ ကိုင်းကွဲတွေပဲမဟုတ်ပါလား။ ဒါကြောင့် နာက်ထပ် အရေးကြီးတဲ့ အချက်တချက်ကတော့ ကွန်ပြူတာသိပ္ပံပညာရပ် ကိုင်းကွဲတချို မှာဆိုရင် ရူပဗေဒ (Physics) ပညာရပ်ဟာ အဓိက အခန်းကဏ္ဏက ပါ၀င်နေတယ် ဆိုတာ သိထားရပါမယ်။ ဥပမာ Computer Engineering, Computer Technology,
Hardware Engineering (processor, mother-board, memory, quantum memory ..စတာတွေ တည်ထွင် ထုတ်လုပ်ခြင်း)၊
System Engineering (ကွန်ပြူတာ network ပိုင်းသက်သက်ကို ပာတာမဟုတ်။ software, hardware, netware တွနဲ ပူးပေါင်းပါ၀င်ဖွဲ စည်းတည်ဆောက်ထားတဲ့၊ လယာဉ် ပျံသန်းမှု ထိမ်းချုပ်ရေးစနစ်တို ၊ ဘဏ်တွေနဲ ငွသွင်း ငွထုတ်စက် အကြွေး၀ယ် လက်ငင်း၀ယ် စနစ်တွေ ပါ၀င်ချိတ်ဆက်ထားတဲ့ Finicial Transaction System Management တို ၊ ကွန်ပြူတာနဲ ထိမ်းချုပ်ထားတဲ့ မို ပ သယ်ယူပို ဆာင်ရေးစနစ် ကား/ရထား..စသည်တို ကို ဆိုလိုတာ)၊
Networking Engineering (ဖြုတ်ရုံ တတ်ရုံ ၊ သူများရေးပြီးသား software တွ၊ သူများတည်ထွင်ပြီးသား netware တွကို ဟိုဟိုဒီဒီ configure လုပ်ရုံ အလုပ်မျိုးကို ဆိုလိုတာမဟုတ်ပါ။ controlling , signaling, data transmission စတဲ့ အဆင့်မြင့် စနစ်တွေကို တည်ဆောက်တဲ့ ပညာရပ်မျိုးကို ဆိုလိုတာ) စတဲ့ ကွန်ပြူတာသိပ္ပံရဲ့ တချို ကိုင်းကွဲ ပညာရပ်တွေမှာ ရူပဗေဒ ဟာ မရှိမဖြစ်ပညာရပ်တခုပေါ့။ တခါ ရူပဗေဒ နဲ သင်္ချာဆိုတာ အကြီးအကျယ် နှီးနွယ်ဆက်စပ် နတာဖြစ်ပါတယ်။ သင်္ချာမပါပဲ ရူပဗေဒကို ကုန်စင်ပြည့်စုံစွာ နားလည်အောင် လ့လာဖို ဆိုတာ ဘယ်လိုမှ မဖြစ်နိုင်ပါဘူး။ ဒါဆိုရင် ကွန်ပြူတာသိပ္ပံမှာ သင်္ချာပညာဟာ ဘယ်လောက်အထိ အရေးပါလှတယ်ဆိုတာ မိတ်ဆွေတို အနေနဲ ပိုပြီး ရှင်းရှင်းလင်းလင်း သိမြင်သွားပြီလို ယူဆပါတယ်။
လက်တွေ အခက်အခဲများ
သို သာ်.. အင်း..သို သာ်လည်းပေါ့ဗျာ။ မိတ်ဆွေတို ရဲ့ ပတ်၀န်းကျင်မှာ အမှန်တရား နဲ တကယ်ဖြစ်နေတာနဲ အမြဲတမ်း မတူနိုင်ဘူးဆိုတာကိုတော့ သတိထားမိမယ်ထင်ပါတယ်။ အဲဒီ သဘောပါပဲ။ ကွန်ပြူတာသိပ္ပံအတွက် သင်္ချာဟာ အဓိကနေရာက ပါ၀င်နေတယ်ဆိုတာက တကယ့်အမှန်တရားပါ ဒါပေမယ့် တကယ်ဖြစ်နေတာကတော့ တမျိုးဖြစ်ကောင်း ဖစ်နေနိုင်ပါတယ်။ “ပရိုဂရမ်မာ ဆာ့ဖ်၀ဲအင်ဂျင်နီယာဖြစ်ဖို သင်္ချာမလိုပါဘူးကွာ။ သင်္ချာက ဘာမှ သိသိသာသာ အထောက်အကူမဖြစ်ပါဘူး။” လို ပာသူတွေအတွက် ကျာထောက်နောက်ခံပြုလောက်စရာ လက်တွေ အခြေအနေတွေကလည်း အထင်အရှားရှိနေပြန်တာကိုး။ အကြောင်းရင်းတွေက အလွန်ပဲရှုပ်ထွေး ကျယ်ပြန် လှတဲ့ ပညာရေး စနစ်ရဲ့ အားနည်းချက်တွေမှာ မစ်ဖျားခံနေပါတယ်။
ပထမအချက်အနေနဲ ကတော့ ကျာင်းသူကျောင်းသားတွေကို သင်္ချာဘွဲ ဒီဂရီ ရအောင်ယူဖို ၊ သင်္ချာပညာရပ်ကို ထဲထဲ၀င်၀င် ထူးထူးချွန်ချွန်ဖြစ်အောင်လုပ်ဖို မက်လောက်တဲ့ တွန်းအားအနေနဲ ဘာမှထင်ထင်ရှားရှားမရှိတာက အကြောင်းတချက်ပဲဖြစ်ပါတယ်။ အဲဒီလို တွန်းအားမရှိတဲ့အတွက် ကျာင်းသားတွေဟာ သင်္ချာပညာရပ်ကို နက်နက်နဲနဲ လ့လာသင်ယူဖို လိုလိုလားလားမရှိတာ၊ လိုလိုလားလားမရှိခဲ့လို လုံလုံလောက်လောက် မပြင်ဆင်ခဲ့တာ၊ အဲဒီလို သင်္ချာပညာရပ်ကို အခြေခံကောင်းအောင် လုံလုံလောက်လောက် မပြင်ဆင်ခဲ့တာတွေရဲ့ နာက်ဆက်တွဲအကျိုးဆက်တွေအဖြစ်၊ ကျာင်းသူ ကျာင်းသားတွေရဲ့ တက္ကသိုလ် ဘာသာရပ် ရွးချယ်မှုပုံစံနဲ ၊ ရွးချယ်လိုက်တဲ့ ဘာသာရပ်အပေါ်မှာ နားလည်တတ်ကျွမ်းမှု အပေါ်မှာ သိသိသာသာ ရိုက်ခတ်လာပါတော့တယ်။
နောက်တချက်အနေနဲ ကျွန်တော်တို ရဲ့ အဆင့်မြင့်ပညာရေးစနစ်မှာ သင်္ချာကို သီးသန် ရပ်တည်နေတဲ့ ဘာသာရပ် (closed subject ) တခု အဖြစ်သင်ကြားပြီး၊ ကွန်ပြူတာသိပ္ပံကိုတော့ နည်းပညာဆိုင်ရာ ဘာသာရပ် (technical subject) တခုအဖြစ်သင်ကြားလာကြခြင်း ဖစ်ပါတယ်။ ဒါကြောင့် သင်္ချာဟာ တခြားပညာရပ်တွေနဲ ဆက်စပ်အသုံးချမရတဲ့ သီးသန် ထီးတည်း ပညာရပ်ကြီးအဖြစ် ရှုမြင်ခံရပြီး၊ ကွန်ပြူတာသိပ္ပံစစ်စစ် ဘွဲ ဒီဂရီတွေကျပြန်တော့ သိပ္ပံပညာရှင်(scientist)တို အင်ဂျင်နီယာ(engineer)တို လို အလုပ်မျိုးတွေအတွက် လိုအပ်တဲ့ တကယ့်အဆင့်မြင့်ပညာရေး (education) အဖြစ်ကနေ၊ နည်းပညာပိုင်း သက်သက်ကိုသာ လ့ကျင့်သင်ကြားပေးလိုက်တဲ့ (purely technical training) ဘွဲ တွအဖြစ် တဖြည်းဖြည်း တန်ဘိုး အသွင်ပြောင်းလာတာ တွ ရပါတယ်။ အကျိုးဆက်ကတော့ “သင်္ချာသမားက ကွန်ပြူတာသိပ္ပံကို ထဲထဲ၀င်၀င်မသိ၊ ကွန်ပြူတာသိပ္ပံသမားက သင်္ချာကို ခခြေမြစ်မြစ် မတတ်” ပဲ ပညာရပ်နှစ်ခုဟာ အစေးမကပ်ဖြစ်လာရပါတော့တယ်။ အဲဒီအခါမှာ ၀ိရောဓိတွေ ကြီးကြီးမားမား ဖစ်လာပြန်ပါတယ်။ တချို အလုပ်ရှင်တွေက “သင်္ချာသမားနဲ အင်ဂျင်နီယာတွေကိုပဲအလုပ်ခန် မယ်ဗျာ။ ကွန်ပြူတာသိပ္ပံနဲ ဘွဲ ရထားတဲ့သူတွေက ပဿနာကို ဘယ်လိုဖြေရှင်းရမလဲဆိုတာ မသိကြဘူးဗျ” လို ဆိုပါတယ်။ ဒါဟာဘာလို လဲဆိုတော့ အင်ဂျင်နီယာဘာသာရပ်တွေနဲ ၊ ရုပ်သိပ္ပံ(physical sciences) ဘာသာရပ်တွေမှာ သင်္ချာပညာကို ခိုင်ခိုင်မာမာ နာက်ခံထား သင်ကြားထားတဲ့အတွက်၊ သင်္ချာအခြေခံ အတွေးအခေါ် အားကောင်းတဲ့သူတွေဟာ ပဿနာကို ပိုပြီး ထိရောက်အောင်ဖြေရှင်းနိုင်တယ်လို ယူဆတာကိုး။ တခြားဖက်က ကြည့်ပြန်တော့လည်း တချို အလုပ်ရှင်တွေက “တကယ်တန်းကျတော့ သင်္ချာသမားတွေ ပဿနာဖြေရှင်းပြီဆိုရင် သူတို ဖရှင်းတဲ့ ပုံစံကို တခြားသူတွေ အလွယ်တကူ နားမလည်ကြဘူးဗျ။ သူတို ရဲ့ လုပ်ထုံးလုပ်နည်းတွေနဲ အဖြေတွေဟာ တခြား သင်္ချာသမားမဟုတ်သူတွေနဲ အဆင်ပြေပြေ မဆက်သွယ်နိုင်ဘူး (သင်္ချာသမားမဟုတ်သူတွေ နားမလည်နိုင်ဘူး)။ သူတို ရဲ့ဖြေရှင်းပုံတွေဟာ လက်တွေ လာကနဲ ကင်းကွာနေတယ်” လို ဆိုကြပြန်ပါတယ်။
အဲဒီ၀ိရောဓိတွေကြောင့်လည်း ဆန်းသစ်တည်ထွင်ဖန်တည်းမှု အားကောင်းတဲ့ သူတချို က သင်္ချာ နဲ ကွန်ပြူတာသိပ္ပံကို စာစောစီးစီး လမ်းခွဲလိုက်ကြတာ ဖစ်နိုင်ပါတယ်။ ဆိုလိုတာက တကယ့်အရည်အသွေးရှိတဲ့ သူတချို က ပုံမှန် ကွန်ပြူတာသိပ္ပံပညာရေးလမ်းကြောင်းကို အလေးအနက်မထားတော့ပဲ စွန် လွှတ်လိုက်တာ ကို ဆိုလိုတာပါ။ အထူးသဖြင့် ဆာ့ဖ်၀ဲသမားတွေပေါ့။ ဘာလို လဲဆိုတော့ အခုလက်ရှိအနေအထားအရ “ဆော့ဖ်၀ဲအင်ဂျင်နီယာဆိုတာ သီအိုရီတည်ဆောက်သူမဟုတ်ဘူး၊ နည်းလမ်းတွေကို အသုံးချသူသာဖြစ်တယ်..” လို ခံယူထားကြတဲ့့အပြင်၊ ဆာ့ဖ်၀ဲအင်ဂျင်နီယာလုပ်ငန်းမှာ နာက်ဆုံးအဆင့် ထွက်ကုန်(final product) ကိုသာ အဓိကထားပြီး၊ ဘယ်လိုသီအိုရီ ဘယ်လိုသဘောတရားရေးရာတွေကို အသုံးချခဲ့တယ် ဆိုတာကျတော့ များသောအားဖြင့် လျစ်လျူရှု ထားကြလို ပဲ ဖစ်ပါတယ်။ ဒါကြောင့် သင်္ချာကို အလေးအနက်မထားတဲ့ ဆာ့ဖ်၀ဲသမားတွေအနေနဲ ၊ လတ်တလော လုပ်ငန်းခွင်မှာ အဆင်ပြေပေမယ့်၊ ရရှည်မှာကျတော့ ဆာ့ဖ်၀ဲကျွမ်းကျင်လုပ်သား အဆင့်ကနေ ကွန်ပြူတာသိပ္ပံပညာရှင်အဆင့်ကို ဘယ်လိုမှ တက်မလာနိုင်တော့ပါဘူး။ တက်လာနိုင်ဖို လုံလောက်တဲ့ သီအိုရီ သဘောတရား နဲ နာက်ခံသင်္ချာပညာရပ်တွေမှ မရှိတာကိုး။ ပီးတော့လည်း သင်္ချာ ကွန်ပြူသိပ္ပံ နဲ တခြားပညာရပ်တွေ ကို ကိုယ်ပိုင်စိတ်ကူးစိတ်သန်းနဲ အချိုးညီညီ မပေါင်းစပ်နိုင်တဲ့အတွက် ဘယ်လိုအသစ်အဆန်းကိုမှ မယ်မယ်ရရ ထိထိရောက်ရောက် မတည်ထွင်နိုင်တော့ပါဘူး။
နိဂုံးအမှာ
ဆိုပါစို ဗျာ ကွန်ပြူတာသမားတွေအတွက် မန်မာစာအရေးကြီးသလားဆိုရင် အဖြေက “ကြံကြံ ဖန်ဖန်ဗျာ” အများစုက ဖကြမယ်ထင်ပါတယ်။ ဘယ်လိုမှ မဆက်စပ်ဘူးထင်ရတဲ့ အရာကိုပဲ ဆက်စပ်စဉ်းစားကြည့်ကြပါစို ။ နည်းပညာနဲ အထိအတွေ နည်းသူတွေကို အထောက်အကူပြုနိုင်ဖို (စေတနာကောင်း ရည်ရွယ်ချက်ကောင်းနဲ ) ရးသားထုတေ်၀တဲ့ တချို စာအုပ်တွေရဲ့ စာအုပ်မျက်နှာဖုံးမှာ software ဆိုတဲ့ အင်္ဂလိပ်စကားလုံးအတွက်(ထင်ပါရဲ့) မန်မာလို ‘ဆော့ဖ်၀ဲလ်’ ဆိုပြီး ရးသားထားတာတွေ မိတ်ဆွေတို တွ ဖူးမှာပါ။ ဒါကြောင့် ဒီ လို ရိုးရှင်းတွင်ကျယ်ပြီးသား software ဆိုတဲ့ စကားလုံးတလုံးကို တိုက်ရိုက်အသံဖလှယ်တာတောင် မူရင်းစကားလုံးနဲ နီးစပ်မှုမရှိဘူးဆိုရင်၊ ကျယ်ပြန် တဲ့ လးနက်တဲ့ ခက်ခဲတဲ့ ၀ါဟာရတွေကို မှန်ကန်အောင် ဖွင့်ဆိုရှင်းပြနိုင်လိမ့်မယ်လို တခြားနယ်ပယ်ကပုဂ္ဂိုလ်တွေ ပညာရှင်တွေက ဘယ် ကြည်ကြတော့မှာလဲ။ ........................................................................................
.................................
..........
............
ပညာသင်ကြားခြင်းရဲ့ ရည်ရွယ်ချက်က ကိုယ်ပိုင်ညာဏ်နဲ အမှန်အမှားကို စဉ်းစား ချင့်ချင် ၀ဖန် ပိုင်းခြားနိုင်ဖို ပဲ မဟုတ်ပါလား။
ရွှင်လန်းချမ်းမြေ့ပါစေ။
infoTherapy-2014
REF:
1. “Benefits and Advantages of an Integrated Mathematics and Computer Science Degree” By T.C. Hurley, Department of Mathematics, National University of Ireland, Galway, http://www.uiginn.com/maths/pstudents/benefits.shtml
2. "The Mathematics of Programming" By C.A.R Hoare, Inaugural Lecture, University of Oxford, Clarendon Press 1986 (The mathematics of programming: an inaugural lecture delivered before the University of Oxford on Oct. 17, 1985)
Friday, December 13, 2013
စံပြပရိုဂရမ်မာ
၂၀၀၃ ခုနှစ် ဇန်န၀ါရီလ၊ အမေရိကန်နိုင်ငံ အာ်ရီဂွန်ပြည်နယ်(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 ဒီဇင်ဘာလထုတ် ကွန်ပြူတာဂျာနယ်တွင် ဖါ်ပြပြီးသော ဆာင်းပါးဖြစ်ပါသည်။)
ဒီအာရ်ဝိုင် ရဲ့ အတိုချုပ်အနှစ်သာရကတော့ “လုပ်ကိုင်ဆောင်ရွက်ပုံခြင်း၊ 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 ဒီဇင်ဘာလထုတ် ကွန်ပြူတာဂျာနယ်တွင် ဖါ်ပြပြီးသော ဆာင်းပါးဖြစ်ပါသည်။)