Legacy system အေၾကာင္းနည္းနည္းေျပာမလို႕။ တကယ္႔ကိုနည္းနည္းပါပဲ။
Legacy system ဆိုတာ ေရွးကတည္းက မပစ္ရက္ဘဲ သိမ္းထားတဲ႔ ဘိုးဘြားပိုင္ ဗီရိုၾကီးလို၊ ေနရရွဳပ္သေလာက္ အသံုးမက်တဲ႔ software ေတြပါ။ အဲဒီလို sytems ေတြကို စင္ကာပူ အႏွံ႕မွာေတြ႕ရပါတယ္။
အဲဒီေတာ႔ ဘယ္လို Maintain လုပ္မလဲ။
(ျဖစ္ႏုိင္ရင္ အလြယ္ဆံုးက အလုပ္ေျပာင္းလိုက္)။
အဲဒီလိုမွ မျဖစ္ႏုိင္ရင္ မရိွဖို႕မ်ားတဲ႔ documentation ေတာင္းၾကည္႕။
Database design ကို ၾကည္႕။ ဘယ္ေလာက္အသံုးမက်လဲဆိုတာကို duplicate columns ေတြ table တစ္မ်ိဳးမွာ နာမည္တစ္မ်ိဳးျဖစ္ေနတဲ႔ Column name ေတြကို အကဲခတ္လိုက္။ ဒါဆို ဘယ္ေလာက္ ခ်ီးထုပ္က်တဲ႔ system လည္းသိလာမယ္။
Source Code က compile ေတာင္လုပ္လုိ႕ရခ်င္မွရမယ္။ ဒါေပမယ္႔ ဘုရားစာဆိုထား။ ကံေကာင္းေအာင္။ ဖြင္႔ခါနီးမွာ အရဟံေလးဘာေလးရြတ္၊ ဥံဳ ဆိုျပီး ဖြင္႔ၾကည္႕လုိက္ရင္ ... အဲဒီမွာ အံ႕အားသင္႔စရာေကာင္းေလာက္ေအာင္ ျဖစ္သလိုေလးလုပ္သြားတဲ႔ေကာင္ေတြရဲ႕ codes ေတြကို ေတြ႕ရမယ္။ အဲဒါဆို သတ္ေသလိုက္ရမလား။ .... မဟုတ္ေသးဘူး။ မလုိဘူး။ ကိုယ္႔ကိုယ္ကို တစ္ခုပဲယံုၾကည္။ ေရွ႕ကေကာင္ေတြထက္ ေတာ္လုိ႕ ငါ္႔လက္ထဲေရာက္လာတာလုိ႕ပဲေတြးလုိက္။ ဟုတ္ဟုတ္မဟုတ္ဟုတ္။
စိတ္ထဲမွာတစ္ခုပဲထား။ ေရွ႕ကကိစၥေတြမွာ မွားရင္ တတ္ႏိုင္သမွ်ျပင္မယ္။ ငါျပင္သမွ်ကိုေတာ႔ ငါတာ၀န္ယူတယ္။ အဲဒါကို နည္းနည္း လူသိေအာင္လုပ္ထားပါ။ အရင္က ႏွစ္ေပါင္းမ်ားစြာ ဘာမွမျဖစ္ဘဲ run လာတယ္လို႕ေျပာရင္ Are U sure, dude? လုိ႕ေသခ်ာေမးထားပါ။ ဘာမွမျဖစ္ဘဲ run ေနတာနဲ႕ ဘာျဖစ္ေနမွန္းမသိဘဲ run ေနတာနဲ႕ဟာ ငတံုးေတြအတြက္ေတာ႔ အတူတူပဲ။
စိတ္ပိုင္းဆုိင္ရာမွာ အဲဒီလို ျပင္မဟဲ႕လို႕ပိုင္းျဖတ္ျပီးရင္ တစ္ခုကို အေသမွတ္ပါ။ ျမင္ေနရတဲ႔ source code ဟာ ကိုယ္တစ္ေယာက္တည္းသံုးေနတာမဟုတ္ဘူးဆိုတာကို သံုးခါေလာက္ ႏွလံုးသြင္းပါ။ Legacy မွာ ဒီ codes ေတြကို တျခား system ေတြက share သံုးေနတာ ၊ interface ေတြက တစ္ဆင္႔ သံုးေနတာ၊ web service share ထားတာ အကုန္ျဖစ္ႏုိင္တယ္။ လံုး၀မထင္မွတ္ေလာက္ေအာင္ အသံုးမက်တဲ႔ ေနာက္တစ္ခုခုေတာင္မွ ျဖစ္ႏုိင္တယ္။
ေနာက္ျပီး တစ္ခုသိထားဖုိ႕က Obama ဘယ္ေလာက္ေတာ္ေတာ္ အေမရိကန္မြဲတာမကယ္ႏုိင္ဘူး .. ဆိုတာေလးကို သတိျပဳပါ။ ဆိုလိုတာက revamp လုပ္ထည္႕လုိက္မယ္လို႕ သိပ္ျပီး မစဥ္းစားေစခ်င္ဘူး။ ေလာေလာဆယ္ ဘယ္လို architecture မွာ သံုးထားလဲ။ အဲဒီ architecture ရဲ႕ limitation ေတြကို နားလည္သင္႔သေလာက္နားလည္ဖုိ႕လုပ္ပါ။ ျပင္တဲ႔အခါၾကရင္ function ေသးေသးေလးတစ္ခုပဲျဖစ္ျဖစ္ျပင္တာနဲ႕ ဘယ္ေနရာမွာ သံုးထားေသးလဲ ေသခ်ာေအာင္ လုပ္ပါ။ java သမားေတြဆို eclipse မွာ reference->workspace or reference-->project ေတြ ၾကည္႕ပါ။ source code control ေတြဘာေတြ ေသခ်ာသံုးပါ။ တကယ္လုိ႕ ကိုယ္ျပင္လုိက္တာၾကီးမွားသြားရင္ေတာင္ ခ်က္ခ်င္း rollback ျပန္လုပ္ႏုိင္ေအာင္လုပ္ထားပါ။
ျပင္တဲ႔အခါ Java မွာဆိုရင္ ကိုယ္ျပင္လုိက္တဲ႔ class ကို အတတ္ႏိုင္ဆံုး သပ္ရပ္သြားေအာင္လုပ္ပါ။ warning ေတြရိွရင္လည္း တတ္ႏိုင္သမွ်ရွင္းပါ။ Clean Code ျဖစ္ဖုိ႕ ၾကိဳးစားပါ။ ကိုယ္ေရးတာေတြဆိုရင္ေတာ႔ ပိုေတာင္ ဂရုစိုက္ပါ။ အလြယ္ဆံုး နည္းက One function once class ဆိုတာပါ။ အဲဒီလိုေျပာရင္ တစ္ခ်ိဳ႕ေတြကလည္း ပ်င္းၾကတယ္။ မပ်င္းပါနဲ႕။ Java ကို resuable ရေအာင္ ေရးႏုိင္ဖုိ႕ဆိုတာ အေျခခံ design pattern ေတြေက်ညက္ဖုိ႕ အမ်ားၾကီးလိုပါတယ္။
ကြ်န္ေတာ္ လြန္ခဲ႔တဲ႔ တစ္ႏွစ္ခြဲတုန္းက လုိင္း ၃၀၀၀ ရိွတဲ႔ class ေတြ ေရးခဲ႔တဲ႔ နေမာ္နမဲ႕ developer ပါ။ အခုအခ်ိန္မွာေတာ႔ ကိုယ္႔ေနာက္မွာ ကိုယ္ေရးတာကို ျပင္ရမယ္႔လူေတြအတြက္ပါၾကည္႕ပါတယ္။ common method ေတြကို helper class ေတြေရးသလို ဘံုထုတ္ထားလုိက္ပါ။ ေနာက္သံုးခ်င္တဲ႔ေနရာကလည္း ယူသံုးႏုိင္တာေပါ႔။ သိပ္ရွဳပ္ရွဳပ္ေထြးေထြး ျဖစ္လာရင္ တျခား class တစ္ခုမွာ business logic ေတြ ေျဖရွင္းဖုိ႕ helper တစ္ခုေရးလုိက္ပါ။ Action class ေတြမွာ အားလံုးစုေရးတာဟာ အသံုးမက်တဲ႔သူေတြလုပ္ေနၾကပါ။ အဲဒါမ်ိဳးဘယ္ေတာ႔မွ မလုပ္ပါနဲ႕။ Program ရဲ႕ readibilty က်သလို၊ အားလံုးက tightly coupled ျဖစ္ေနလိမ္႔မယ္။ သပ္သပ္ရပ္ရပ္ မေရးတတ္ေသးတဲ႔သူေတြအေနနဲ႕ flow diagram ေလး အၾကမ္းေလာက္ျခစ္လုိက္ဖုိ႕ ၀င္မေလးေစခ်င္ဘူး။ အဲဒီလို ေသေသခ်ာခ်ာေရးၾကည္႕မယ္ဆုိရင္ အပိုအလိုမရိွတဲ႔ clean code ေတြရလာမယ္။ method ေတြ ေဖာင္းပြမႈမရိွေတာ႔ပါဘူး။
method တစ္ခုကို တတ္ႏိုင္ရင္ duplicates ဘယ္ေတာ႔မွမလုပ္ပါနဲ႕။ ကြ်န္ေတာ္နမူနာတစ္ခုေပးပါမယ္။ ကြ်န္ေတာ္သာ ဘံုသံုးလုိ႕ရႏိုင္တဲ႔ method တစ္ခုကို ေနရာတုိင္းမွာ copy ။ paste လုပ္ထားတဲ႔ codes ကို တစ္နာရီေလာက္ျပင္ရျပီဆိုရင္ ေရွ႕က ေရးသြားတဲ႔ေကာင္ကို အယုတၱ အနတၱေတြ စျပီး ေရရြတ္ပါျပီ။ တကယ္႔ကို tedius ျဖစ္စရာမဟုတ္လား။ ေနာက္တစ္ခုက တစ္ေနရာမွာ ကိုယ္ျပင္ဖုိ႕က်န္ခဲ႔ရင္ အဲဒီကလည္းျပႆနာျဖစ္ႏုိင္တယ္။ အထူးသျဖင္႔ calculations ေတြအမ်ားၾကီးပါတဲ႔ method ေတြကို ဘယ္ေတာ႔မွ duplicates မလုပ္မိဖုိ႕ ၊ တတ္ႏိုင္သမွ် share သံုးဖုိ႕ၾကိဳးစားပါ။ တစ္ေနရာမွာ ျပင္လုိက္ရံုနဲ႕ အားလံုးမွာ အိုေကသြားတယ္ဆိုရင္ ေနာက္လူရဲ႕ အဆဲအဆို အေတာ္ေလးသက္သာသြားႏုိင္ပါတယ္။
ေနာက္တစ္ခုက testing ပါ။ ကုိယ္ျပင္လိုက္တာဟာ ေရွ႕က flow ကို ထိခုိက္လားမထိခိုက္လား ဘယ္လိုသိမွာလဲ။ Unit Testing မရိွရင္ေတာ႔ sorry ပဲေျပာရမွာပဲ။ ကိုယ္႔အပိုင္းကိုေတာ႔ ေသခ်ာစစ္ပါ။ တတ္ႏုိင္သမွ် extreme test ေတြလုပ္ပါ။
အားလံုးေရးျပီးရင္ အခ်ိန္နည္းနည္းေလးပိုယူျပီး system document လုပ္ဖုိ႕ၾကိဳးစားပါ။ ဘယ္သူ႕အတြက္မွ မဟုတ္ပါဘူး။ ကိုယ္႔ဘာသာကိုယ္ ပိုနားလည္ဖုိ႕ၾကိဳးစားတဲ႔သေဘာပါပဲ။ ေနာက္ေတာ႔ source code ကို Version Control System ထဲ check in ျပန္လုပ္ပါ။
တတ္ႏိုင္သမွ် ေရွ႕မွာ ေရးထားတဲ႔ codes ေတြကို ျပင္ဖုိ႕မၾကိဳးစားပါနဲ႕။ တကယ္ျပင္ရမယ္႔အခ်ိန္ၾကရင္သာ ေသခ်ာနားလည္ေအာင္လုပ္ျပီး ျပင္သင္႔သေလာက္ပဲျပင္ပါ။ တျဖည္းျဖည္းခ်င္း ပိုေကာင္းျပီး ပို stable ျဖစ္လာတဲ႔ sytem ျဖစ္ေအာင္ ေရရွည္လုပ္သြားၾကပါ။
Source code is the best documentation ဆိုတာေလးကိုလည္း သတိေပးလိုက္ပါတယ္။ Functional Spec: ေတြ၊ documentation ေတြထဲမွာ ဘာေတြေရးထားေရးထား source code မွာမပါရင္ အလကားပါပဲ။ တကယ္တမ္း လက္ေတြ႕ေလာကမွာ ျပည္႕စံုတဲ႔ documentation ကို ေတြ႕ရဖုိ႕ဆိုတာ ဘုရားပြင္႔တာကို ၾကံဳရသလို ၾကံဳေတာင္႔ၾကံဳခဲျဖစ္ေနတတ္ပါတယ္။ common sense နဲ႕ အာရံုေတြဖ်တ္လတ္ေအာင္ထားျပီး အေကာင္းဆံုးၾကိဳးစားဖုိ႕ပဲရိွပါတယ္။
Legacy Systems ေတြဟာ developers ေတြရဲ႕ အေကာင္းဆံုးေလ႔က်င္႔ေရးကြင္းပါပဲ။
Regards,
Zero
No comments:
Post a Comment