၆၃ မက်တဲ႔သူမျဖစ္ေစနဲ႔။

၆၃ မက်တဲ႔သူမျဖစ္ေစနဲ႔။

မေန႕က Aဂ်ိဳင္း စာအုပ္တစ္အုပ္ကို ျမည္းရင္း ဘာေတြ႕လည္းဆိုေတာ႔ မျပီးႏုိင္တဲ႔ ကိစၥကိုျပီးေအာင္လုပ္ခိုင္းရင္ အခိုင္အမာကာကြယ္ဖုိ႕ေျပာထားတာဖတ္လိုက္ရတယ္။

Aဂ်ိဳင္းဆိုတာ Agile ကိုေျပာတာပါ။

ဒီႏွစ္ထဲမွာ Target လုပ္ထားတာက SCJA ေျဖဖို႕ျဖစ္တဲ႔အတြက္ စာမ်ားမ်ားဖတ္ျဖစ္ပါတယ္။ အထူးသျဖင္႔ Agile နဲ႕ Spring ကို အမ်ားဆံုးဖတ္ပါတယ္။

Singapore မွာ Software Engineering ကိုေကာင္းေကာင္းနားလည္တဲ႔သူ အနည္းငယ္ပဲရိွတယ္ဆုိတာကိုေျပာရင္ ယံုၾကပါ႔မလားမသိဘူး။ စလံုးေတြ စျပားေတြသိပ္ေတာ္တာပဲဆိုတာကို မၾကာမၾကာၾကားရပါတယ္။ ေတာ္တာလည္းရိွေပမယ္႔ ေရွာ္တာေတြက ပိုမ်ားပါတယ္။

သူတို႕ရဲ႕ Life မွာ စာမ်ားမ်ားဖတ္ခ်ိန္မရေတာ႔တာလည္းပါပါတယ္။ အခုေခတ္မွာ ဘယ္ႏိုင္ငံသားပဲျဖစ္ျဖစ္ မ်ားမ်ားေလ႔လာတဲ႔သူက မေလ႔လာတဲ႔သူထက္ သာသြားတာပါပဲ။ သိပ္အထင္မၾကီးနဲ႕။ အေတြ႕အၾကံဳအရလုပ္ေနၾကေပမယ္႔ တကယ္တမ္း သီအုိရီကို ေသြဖယ္တာေတြေၾကာင္႔ ထြင္ျပီးသားဘီးျပန္ထြင္ေနရတဲ႔ ပေရာဂ်တ္ေတြအမ်ားၾကီးပါပဲ။ reinventing the wheel ျဖစ္ရင္ ေသခ်ာေပါက္ ဒုကၡနဲ႕လွလွေတြ႕ပါျပီ။

Singapore မွာ ဘာေတြကိုအျဖစ္လုပ္လဲဆိုတာေတြကိုခ်ည္းပဲေရးရင္ေတာင္ ေတာ္ေတာ္မ်ားမ်ားရပါမယ္။ Team Lead ေတြဟာ စာမဖတ္တာၾကာတဲ႔အခါ Failed ျဖစ္မယ္႔ Project ကို လူႏွစ္ဆထည္႕ေနတုန္းပဲရိွပါေသးတယ္။ အဲဒါဆို သီအုိရီအရ ပိုျပီးေသခ်ာေပါက္ Failed ျဖစ္ပါတယ္။ မသိလုို႕ ေရးေနတဲ႔သူေတြကို လူသစ္ေတြက လာလာေမးတဲ႔ interactions ကမ်ားလုိ႕ပါ။ သိပ္ေတာ္တဲ႔လူေတြကိုလည္း လြယ္လြယ္နဲ႕ငွားလို႕မရပါဘူး။ ေပါေခ်ာင္ မေကာင္းပဲရိွပါတယ္။ ေပါေခ်ာင္ေကာင္းဆိုတာ software engineer ေတာ႔မရပါဘူး။ အဲဒါကို သီအိုရီကဘယ္လုိေရးထားလဲဆိုရင္ မိန္းမတစ္ေယာက္က ၉ လမွာ ကေလးတစ္ေယာက္ေမြးလုိ႕ရရံုနဲ႕ မိန္းမကိုးေယာက္ေပါင္းျပီးတစ္လတစ္ေယာက္ေမြးလုိ႕မရသလုိပဲတဲ႔ .....။ အဲဒါေလးကိုေတာ႔ဖတ္ထားဖုိ႕လိုပါတယ္ ... Team lead လုပ္မယ္႔သူေတြေပါ႔ေလ။

Agile Development မွာ User ကို Development Process မွာ အဓိကထားပါတယ္။ တစ္ခုေရးျပီးတာနဲ႕ Userကိုျပ၊ မၾကိဳက္ရင္ျပင္ ၊ ျပန္ျပ၊ ေက်နပ္တဲ႔အထိျဖစ္ရင္ ေက်နပ္ေၾကာင္းကို တစ္ခါတည္း confirm လုပ္၊ ဆက္ေရး။ အဲဒီလိုသြားရပါတယ္။ စင္ကာပူမွေတာ႔ Change Request လုိခ်င္ေလာဘက မ်ားေလေတာ႔ user ကို milestone ေရာက္မွျပ၊ မၾကိဳက္ရင္လည္းပုိ႕ထားတဲ႔ User Requirement ေတြနဲ႕ ကိုင္ေပါက္၊ ညာခ်၊ အဲဒါေတြဟာ လူၾကီးလူေကာင္းမဆန္ဘူး။ ပိုက္ဆံအေခ်ာင္လုိခ်င္တဲ႔ အေခ်ာင္သမားပဲဆန္တယ္။ ႏိုင္ငံတကာမွာ Agile ကို တြင္တြင္က်ယ္က်ယ္လုပ္လာလို႕ software ေတြ quality ပိုေကာင္းလာတယ္။ User satisfaction ရတယ္။ ပိုက္ဆံအမ်ားၾကီးရၾကတယ္။ ဒီမွာေတာ႔ Deadline သာအမိ၊ Deadline သာအဖ၊ Quality သည္ ဒုတိယဆိုတဲ႔စကားကို ဥံဳခံရြတ္ေနတုန္းပဲရိွေသးတယ္။ Budget ကိုတြက္တဲ႔ေနရာမွာ စစ္တမ္းေကာက္ရင္ စင္ကာပူဟာ Software Engineering မွာေရွ႕ကေျပးပါတယ္။ ရိွတဲ႔လူနဲ႕ ျ႔ပီးေအာင္လုပ္မယ္ဆုိတဲ႔ မျဖစ္ညစ္က်ယ္ တစ္ထြာတစ္မိုက္ဥာဏ္ကလည္း မ်ားပါတယ္။Software ျပီးသြားရင္ External QA ျဖတ္ရမယ္ဆုိတာကိုလည္း ေမ႔ထားတာ ႏွစ္ေပါင္းမနည္းေတာ႔ပါဘူး။

အဲဒီလိုေလာကမ်ိဳးမွာ ရွင္သန္ဖို႕ ဘာမွသိပ္မ်ားမ်ားသိဖုိ႕မလိုပါဘူး Skills က knowledge ထက္ပိုအေရးၾကီးတယ္လို႕ေျပာလုိ႕ရပါတယ္။ စင္ကာပူမွာ သိပ္ျမန္တဲ႔ေကာင္ေတြအမ်ားၾကီးပဲ။ ဘာခိုင္းခိုင္း အေသအေၾကျျမန္တယ္။ Analysis ကို အခ်ိ္န္မေပးႏိုင္ဘူး။ ေရးတာပဲ။ ေရးျပီးရင္းေရးေနတာပဲ။ Framework ကဘာလုိ႕ Bean ကို Inject လုပ္တာလည္းမေမးနဲ႕။ သိဘူး။ ေရးေတာ႔ေရးေနတာပဲ။ ကိုယ္ဘာေရးေနမွန္းနားမလည္တဲ႔ေကာင္ေတြ အမ်ားၾကီးပဲ။ အဲဒါေတြဘယ္ကေရာက္လာတာလဲ။ ဘာလို႕ေရာက္တာလဲအထိ မသြားေတာ႔ဘူး။ ေရးလုိ႕ရရင္ေတာ္ျပီ။ Configure ဒီလိုလုပ္၊ ဒီလိုေလးေရး။ ဒါပဲ။ ဒီေလာက္ဆို ရပ္တည္လုိ႕ရျပီ။ တကယ္တမ္း Struts နဲ႕ Spring ဘာကြာလဲ၊ ဘာလုိ႕ကြာလဲ။ Lightweight framework ေတြက Modern Software Industry မွာ ဘာလုိ႕လြမ္းမႈိးသြားလဲ ...အဲဒါေတြမေျပာနဲ႕ေတာ႔ ...ေရးျ႔ပီးရင္းေရး ... Quality အသင္႔အတင္႔ေလာက္ေရးတတ္ရင္ရျပီ။

တကယ္တမ္း ... သိေအာင္ၾကိဳးစားၾကည္႕ျပီး အေပၚစီးက ျမင္ႏိုင္ရင္ ေလ႔လာတဲ႔ေနရာမွာ အမ်ားၾကီးလြယ္ကူပါတယ္။ Java မွမဟုတ္ပါဘူး OO concept က ဒါေတြပဲရိွတယ္။ ဘယ္လို implements လုပ္သလဲေလာက္ေလ႔လာလိုက္ရင္ Java ရဲ႕ Branch ေတြကို ေလ႔လာတဲ႔အခါ အမ်ားၾကီး အက်ိဳးရိွပါတယ္။ ပိုေကာင္းတဲ႔ Code ေတြကို လြယ္လြယ္နဲ႕ေရးႏုိင္လာပါမယ္။ ပိုျပီးေထာင္႔ေစ႔တဲ႔အျမင္ရလာပါမယ္။ အေျခခံေလးေတြဆိုျပီး အဆင္႔မေက်ာ္လုိက္ပါနဲ႕။ အဆင္႔ေက်ာ္ထားရင္ ဘာျဖစ္မလဲ .....။ ၆၃ မက်တဲ႔သူျဖစ္သြားပါမယ္။

Design Pattern စာအုပ္ထဲမွာေျပာထားတာတစ္ခုကို မွတ္မိလို႕ျပန္ေျပာရရင္ Inheritance သိပ္ေကာင္းတယ္ဆိုျပီး မလုိဘဲေလွ်ာက္သံုးတာကိုေရးထားတာပါ။ ဘဲေတြက ပ်ံတယ္ဆိုတဲ႔ ဘဲ class ကို extends လုပ္တာမ်ားသြားေတာ႔ plastics ဘဲဆိုလည္း super class ကဘဲလိုပဲ ပ်ံေနေတာ႔တာပဲ။ အဲဒီလုိေတြျဖစ္လာေတာ႔မွ interface သံုးျပီး implements ၾကတာေတြျဖစ္လာတာပါ။ OO Concept ေတြဘယ္ေလာက္ေက်လဲသိေအာင္ Design Pattern နည္းနည္းေလာက္ေတာ႔ျပန္ဖတ္ပါ။ ကိုယ္က မ်ားမ်ားသိတယ္ဆိုရင္ ပူစရာမလိုပါဘူး။ ဖတ္လုိက္မွ ေအာ္ ဒီလိုၾကီးလားဆိုရင္ေတာ႔ ျပန္စဥ္းစားပါ။ ကိုယ္႔ေၾကာင္႔ Software ထဲမွာ plastic ဘဲ ဘယ္ႏွစ္ေကာင္ပ်ံကုန္ျပီလဲဆိုတာကိုေပါ႔ေလ။

စာမ်ားမ်ားဖတ္ပါ။ ၆၃ က်ခ်င္ရင္ စာဖတ္ပါ။ စင္ကာပူက ညီေလးေတြကို ေျပာခ်င္ပါတယ္။ Library မွာ ဖတ္ပါ။ ဖတ္လုိ႕ၾကိဳက္မွ၀ယ္ပါ။ ၀ယ္တဲ႔အခါ ကိုယ္နဲ႕အဆင္ေျပတဲ႔စာအုပ္တုိက္ကို မွတ္ထားပါ။ ဥပမာ ... တစ္ခ်ိဳ႕က Manning ကရွင္းတာေတြကို သေဘာက်တယ္။ In action series ေတြ သိပ္ရွင္းတယ္။ေကာင္းတယ္။ ဒါေပမယ္႔ တစ္ခ်ိဳ႕ကမၾကိဳက္ဘူး။ ၾကာတယ္လုိ႕ထင္တယ္။ Apress ကိုတစ္ခ်ုိဳ႕ကၾကိဳက္တယ္။ တစ္ခ်ို႕ကHead First ေတြၾကိဳက္တယ္။ တစ္ခ်ိဳ႕က Packet ကိုၾကိဳက္တယ္။ ကို္ယ္ၾကိဳက္တာကိုယ္ဖတ္ပါ။ အဓိကကဖတ္ေနဖို႕နဲ႕ သံုးၾကည္႕ဖုိ႕ပါပဲ။

သံုးၾကည္႕ဖုိ႕ဆိုတာကို နည္းနည္းခ်ဲ႕ေျပာခ်င္ပါတယ္။ သံုးတယ္ဆိုတာက သံုးတတ္ရင္ေတာ္ပါျပီ။ တစ္ခ်ိဳ႕ကိစၥေတြမွာ နားလည္ဖုိ႕ ေရးၾကည္႕ရပါတယ္။ ကြ်န္ေတာ္တို႕လုိ Academic ပိုင္းကလာတဲ႔သူေတြက လက္ေတြ႕လုပ္ရမွာ အေတာ္ေလးပ်င္းပါတယ္။ ဒီလိုလုပ္ရင္ ရတယ္ဆုိတာကို သိရင္ ရပ္ထားတာမ်ားပါတယ္။ တကယ္လုပ္ၾကည္႕မွ Tips and Tricks ေလးေတြကိုသိရပါတယ္။ အဲဒီလိုသိေအာင္ေတာ႔ အနည္းနဲ႕အမ်ားတကယ္လုပ္ၾကည္႕ဖုိ႕လုိပါမယ္။

အခု လုပ္ေနတာက Insurance company တစ္ခုရဲ႕ software ကို maintain လုပ္ၾကတာပါ။ ဘယ္ေလာက္တလြဲေတြလုပ္ထားလည္းဆိုတာကိုေရးလုိက္ရင္ Insurance system ၾကီးဒီေလာက္သက္ဆိုးရွည္ေနတာကိုေတာင္ အံ႔ၾသမိပါတယ္။ အဲဒီလို ၆၃ မက်တဲ႔ေကာင္ေတြ ေရးသြားလုိ႕လည္း ငါတုိ႕အလုပ္ေတြေပါေနေသးတာလုိ႕ ၾကံဖန္ေက်းဇူးတင္မိပါတယ္။

Problem Solving Skills တိုးတက္ဖုိ႕ အေသခ်ာဆံုးနည္းက Systematic ျဖစ္ဖုိ႕သတိထားပါ။ ဘယ္သူေျပာတာကုိမွမယံုနဲ႕။ Codes ေျပာတာကိုယံု။ ကိုယ္႔ဘာသာကိုယ္ source code ၾကည္႕။ ဘယ္သူဘာေျပာေျပာ source code ေလာက္မေသခ်ာဘူး။ Right Track ကို သြားဖုိ႕ အျမန္ဆံုးနဲ႕ ျပႆနာကိုေဖာ္ထုတ္ႏုိင္ဖုိ႕ အတြက္ အျမဲေလ႔က်င္႔ေနပါ။

အျမဲသံုးေနရတဲ႔ folder ေတြ software ေတြဆီကို click သံုးခ်က္ထက္ပိုႏွိပ္ျ႔ပီးသြားေနရရင္ ငေပါ Developer ပါပဲ။ အဲဒီလို Efficient မျဖစ္တာေတြကိုေရွာင္ပါ။ ကိုယ္႔စက္ထဲမွာ ဘာပဲသိမ္းသိမ္း structure က်က်သိမ္းပါ။ Mail ကို Archive လုပ္ရင္လည္း ျဖစ္ကတတ္ဆန္းမလုပ္ပါနဲ႕။ စနစ္က်ပါ။

အထက္လူၾကီးကိုေျပာရင္ ေယာင္၀ါး၀ါးမလုပ္ပါနဲ႕။ ျပတ္ျပတ္သားသား တိတိက်က်ေျပာပါ။ အလုပ္ကို အခ်ိ္န္မဆြဲပါနဲ႕။ ျပီးမွနားပါ။ ျမန္ျမန္မလုပ္တာၾကာရင္ လူက ေႏွးသြားတတ္ပါတယ္။ အဲဒီလိုျဖစ္လာရင္ တစ္ျခားတစ္ခုခုကို ေလ႔လာပါ။ ကိုယ္႔အစြမ္းအစကို မတံုးသြားေစပါနဲ႕ သက္သက္သာသာေနရာမွာ ၾကာၾကာေနေလေလ ညံ႕ေလပါပဲ။ တစ္ခ်ိန္ၾကရင္ အရင္က အတူတူဆိုတဲ႔လူေတြနဲ႕ ကိုယ္နဲ႕ သိပ္ကြာသြားမယ္။ အဲဒီလိုျဖစ္ခ်င္သလားကိုယ္႔ကိုယ္ကိုေမးပါ။

Java မွာ စိတ္ေလေလာက္စရာ Dependency Issues ေတြရိွပါတယ္။ အဲဒါေတြၾကံဳရင္ Forum ေတြဖတ္ပါ။ လူမ်ားေတြဘယ္လုိေျဖရွင္းသလဲ စိတ္ေအးေအးနဲ႕ေလ႔လာပါ။ စိတ္ဘယ္ေတာ႔မွမပူနဲ႕။ စိတ္ပူေနစရာမလိုဘူး။ ဒီအလုပ္က ကမာၻမွာအခက္ဆံုးမဟုတ္ဘူး။ ကိုယ္႔ထက္ေတာ္တဲ႔သူေတြ ရွာထားလိမ္႔မယ္။ မေတြ႕ရင္လည္းကိုယ္႔ထက္ညံ႕တဲ႔ေကာင္ေတြမေတြ႕ေသးဘူးလုိ႕မွတ္ပါ။ နားလည္ေအာင္ၾကည္႕ျပီးမွ ေျဖရွင္းပါ။ ရမ္းကစ္တာေတြမလုပ္ပါနဲ႕။အခ်ိန္ကုန္ပါတယ္။

API ေတြကိုဖတ္ပါ။ အဲဒီလိုေျပာရင္ ရယ္စရာတစ္ခုကိုသတိရပါတယ္။ ထမင္းစားေနုတုနု္း ကြ်န္ေတာ္တို႕ Java သမားႏွစ္ေယာက္က API အေၾကာင္းေျပာေနတာကုိ တစ္ျခား Language ေရးတဲ႔သူငယ္ခ်င္းက dot ေလးခ်လိုက္ရံုနဲ႕မရဘူးလားဆိုျပီး အေရးထဲ IDE ရဲ႕ auto completion (intellisense) နဲ႕လာယွဥ္ေျပာေနလုိ႕ အေတာ္ေလးစိတ္ေလရပါတယ္။ Eclipse ကလည္း Auto Completion မွာ ထိပ္တန္းကရိွပါတယ္။ ေရးထားတဲ႔သူေတြကလည္း ကမာၻမွာ အေတာ္ဆံုးေတြပါ။ API ကေတာ႔ Java သမားေတြ အတြက္ အေကာင္းဆံုးေလ႔လာစရာပါပဲ။ API ထဲမွာ ဘာေတြလုပ္လုိ႕ရသလဲဆိုတာၾကည္႕လုိက္ရင္ အေတာ္ေလးအိုေကသြားပါတယ္။

Java သမားတစ္ေယာက္ဟာ တကယ္ေရးတဲ႔ေနရာမွာ ၾကာၾကာေလးေနဖုိ႕လိုပါတယ္။မဟုတ္ရင္ Training ground မျဖတ္သန္းခဲ႔တဲ႔ စစ္သားေတြလုိပဲ။တကယ္တမ္းၾကေတာ႔ ၆၃ မက်ေတာ႔ဘူး။

ျမန္မာေတြက မညံ႕ပါဘူး။ အခု ဖိလစ္ပင္းေတြနဲ႕ အိႏၵိယေတြ၊ တရုတ္ေတြ စင္ကာပူကို Mass Export လုပ္ေနခ်ိန္မွာ Software သမားေတြအေနနဲ႕ အမ်ားၾကီးေလ႔လာဖုိ႕လိုပါတယ္။ အထူးသျဖင္႔ ကုလားေတြက စာဖတ္ပါတယ္။ က်န္တဲ႔ ဖဦးထုပ္နဲ႕ တရုတ္ကေတာ႔ ထင္သေလာက္မဟုတ္တာမ်ားပါတယ္။ အဲဒီလုိ အျပိဳင္အဆိုင္ပိုမ်ားလာတဲ႔အခ်ိန္မွာ တပမ္းသာဖုိ႕က တကယ္ေတာ္တဲ႔လူျဖစ္ဖုိ႕နဲ႕ Flexibility ေကာင္းဖုိ႕၊ ၆၃ က်ဖုိ႕လိုပါတယ္။ ကိုယ္႔မွာ အားနည္းေနတဲ႔အပိုင္းကိုရွာပါ။ ျဖည္႕ဆည္းပါ။ တစ္ႏွစ္ေလာက္အတြင္းမွာ ဒီက ေရးေနတဲ႔ သာမန္ Developer ေတြကို ေက်ာ္တက္ႏိုင္ပါတယ္။ ဘာမွမပူပါနဲ႕။ ျမန္မာေတြေလာက္ဘယ္သူမွ အားအားယားယား ေလ႔လာဖုိ႕ အခ်ိ္န္မရိွပါဘူး။ ဒီကို ေရာက္ေနတဲ႔ Computer ကညီငယ္ေတြ၊ IT ကညီငယ္ေတြ၊ညီမငယ္ေတြအားလံုး ေက်ာင္းမွာ ဖတ္ခဲ႔တဲ႔စာေတြကိုျပန္ေတြးလုိက္ပါ။ အဲဒီဖတ္ခဲ႔တာေတြရဲ႕တစ္၀က္ေလာက္ကိုပံုမွန္ဖတ္ပါ။ စင္ကာပူမွာ ျမန္မာေတြေတာ္တာကို လက္ခံလာတဲ႔ ကုမၸဏီေတြအမ်ားၾကီးရိွပါတယ္။ ထပ္ျပီးသက္ေသျပၾကပါ။ ေနာက္လူေတြအတြက္ အေကာင္းဆံုးကူညီေပးလုိက္ဖုိ႕က ကိုယ္႔ေနရာမွာ ကိုယ္ဟာ အေကာင္းဆံုးလူျဖစ္ေနဖုိ႕ပါပဲ။

ညံ႕ေနတာကို ညံ႕ေနမွန္းမသိတဲ႔သူကေတာ႔ ဆက္ျပီးညံ႕ေနဦးမွာပါ။

စိတ္ဓာတ္ကေနစရပါမယ္။ တကယ္သိခ်င္ရင္ သိဖုိ႕ အမ်ားၾကီးအခြင္႔အလမ္းေပၚပါတယ္။ သိခ်င္စိတ္မရိွတဲ႔သူကေတာ႔ အခြင္႔အလမ္းေပၚရင္လည္း မေလ႔လာတဲ႔အတြက္ ဘာမွ အက်ိဳးမရိွပါဘူး။

ဒီေဆာင္းပါးက နည္းနည္းေတာ႔ လုိရင္းမေရာက္သလုိျဖစ္ေနပါတယ္။

တကယ္႔ Main Theme ကေတာ႔တစ္ခုတည္းပါ။ Let's prove we are the best !!!!!!!!!!!!!!!!!!!

regards_zeroDividedByZeroIsZerO

Dedicated to all young Software Engineers ..., Coders, Debuggers,Deployers,DBAs,BAs and QAs.