Software ရေးတယ်ဆိုတာက Code တွေကိုချက်ချင်းတန်းရေးလိုက်တာမျိုးမဟုတ်ဘူး။ အဲ့လိုလုပ်တာကတော်တော်ကိုမှားတယ်။ Analysis နဲ့ Software Design ကိုသိဖို့လိုသေးတယ်။ ကျော်လို့မရဘူး။ အဲ့လိုမလုပ်ဘူးဆိုရင် Enterprise Software ရေးရင်ခွေးအကြီးလှည်းနင်းသလိုပဲဖြစ်မှာ။ အဲ့လိုမဖြစ်ဖို့က Architect တွေခန့်ထားဖို့လိုတယ်။ အဲ့လိုမခန့်နိုင်ရင် အတွေ့အကြုံများတဲ့သူကို Software Design အတွက် Decision Making ချခိုင်းဖို့လိုတယ်။ အဲ့လိုမလုပ်ရင်ခွေးဖြစ်မှာပဲ။
Software က Enterprise Level ရောက်လာပြီတဲ့။ Code တွေကလူဖတ်ရနားမလည်ဘူး။ Rapid Development လုပ်ထားတယ်ပေါ့။ Rapid Development ကမြန်မြန် Delivery လုပ်ချင်တာမျိုးကိုပြောတာ။ ဒီလိုမျိုးလုပ်ရင် ပိုက်ဆံတော့ရမယ်။ Maintainability က အောက်ကိုထိုးကျသွားရော။
Project ကိုမနိုင်တော့ Software Engineer တွေထပ်ထည့်၊ ထပ်ထည့်။ လူတွေသာများသွားတယ် Code တွေက လူဖတ်ရနားမလည်ဘူး။ Bloated ဖြစ်နေတယ်ပေါ့။ အလုပ်လုပ်ရင်ပြီးရောဆိုပြီးရေးထားတာမျိုး။ Code တွေကတန်းကြည့်တာနဲ့နားမလည်ဘူး။ Iteration တစ်ခုစာလောက်ယူပြီးရှင်းပြဖို့လိုတာမျိုးရှိနေပြီဆိုရင်အဲ့ Code Base က Software Design မရှိဘူးဆိုတာကိုပြတာပဲ။
Software Design ချဖို့အတွက် အလွယ်ဆုံး Step က Clean Code ပဲ။ ဘယ်လိုလူနားလည်အောင်ရေးမလဲပေါ့။ ဒါ့အပြင် Naming Convention တွေ၊ API Documentation တွေရေးထားဖို့လိုသေးတယ်။ အပျင်းတက်နေလို့မဖြစ်ဘူး။ ဒီလိုပျင်းမှုတွေရဲ့ Consequences က Scalable မဖြစ်တာကိုပြတာပဲ။
Naming Convention တွေထားပြီးပါပြီတဲ့။ Architecture ပိုင်းကို Design ချဖို့လိုသေးတယ်။ Architecture ဆိုတာက Folder Structure ကိုနာမည်ဘယ်လိုပေးရမလဲဆိုတာမဟုတ်ဘူး။ ဒီ Code က ဘယ်နေရာဘယ်လို Behave တယ်ဆိုတာကိုပြောတာပဲ။ ဒီနေရာမှာဒါဖြစ်ရမယ်၊ ဒါကို Refactoring လုပ်ရင်ဒါဖြစ်ရမယ်ဆိုတာမျိုးကိုပြောတာ။ Design ချပြီးပါတဲ့ Code စရေးမယ်ဆိုပါတော့။ ချပေးထားတဲ့ Design အတိုင်း Follow လို့မရတာမျိုးတွေရှိလာမယ်။ ဒါဆိုဘယ်လိုလုပ်မလဲ။ ဒီလိုမျိုးအစကတည်းက Projects Analysis and Planning တွေလုပ်ဖို့ကလိုတယ်။ အဲ့လိုမလုပ်တော့ Code တွေကကြည့်လိုက်တာနဲ့ တောသားလိုရေးထားတယ်ဆိုတာမျိုးမဖြစ်အောင်ရေးဖို့လိုတယ်။
Top comments (0)