DEV Community

Aung Myat Moe
Aung Myat Moe

Posted on • Originally published at aungmyatmoe.me on

Software Design and Analysis in Nutshell

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)