Dry code အကြောင်းသိကောင်းစရာများ

Don’t Repeat Yourself (DRY) ကတော့ development principle တစ်ခုပဲဖြစ်ပါတယ်။ အဓိက ကတော့ ထပ်နေတဲ့ code တွေကို လျော့ချနိုင်အောင် စနစ်တကျပြန်ခွဲရေးလိုက်တာပါ။

ပုံမှန် Medium Size လောက်ရှိတဲ့ application တစ်ခုရေးပြီဆိုရင်တောင် မှ အနေအထားတစ်ခုရောက်တဲ့ အခါမှာ Code တွေကရှုတ်ထွေးလာစမြဲပါ။ ပွင့်ပွင့်လင်းလင်းပြောရင်ကျနော်တို့ကရှုတ်ထွေးတဲ့ အရာတွေကို manage လုပ်ရတဲ့အရာတွေမှာအားနည်းပါတယ်။ အဲ့အတွက်ကြောင့်ရှင်းရှင်းလင်းလင်းနဲ့ဖြေရှင်းလို့လွယ်မယ့်နည်းလမ်းတွေကို စဉ်းစားတတ်လာကြတာပါ၊ Code complexity ကို ထိန်းချုပ်နိုင်ဖို့က အခြေခံအားဖြင့် ပုံနေတဲ့ code တွေကို Handle လုပ်နိုင်တဲ့ အဆင့်တစ်ခုထိရောက်အောင် managable units(ဘယ် components က ဘယ် sub features ကိုထိန်းတယ်) လေးတွေ ခွဲလိုက်တဲ့သဘောပါပဲ။ CMS တစ်ခုဆောက်တယ်ဆိုပါစို့၊ User management , Content Management.etc. အဲ့လို component တွေခွဲထားလို့ရပါတယ်။ ဒီထက် ထပ်ပြီး Dry ချင်တယ်ဆိုရင် component တွေကို sub component အဖြစ်ထပ်ခွဲလို့ရပါသေးတယ်။

code တွေကိုတော့ dry လိုက်ရင်ဘာတွေကောင်းလာမလဲ၊

Dry လိုက်ခြင်းအားဖြင့် ရလာမယ့် အကောင်းဆုံး အချက်က Maintainability ပါ ၊ ဥပမာအားဖြင့် Mail ပို့တဲ့ function က break down ဖြစ်သွားတယ်ဆိုပါစို့၊ repeated ဖြစ်နေတဲ့ code တွေဆို debug & trace လုပ်ရတာ အချိန်ကုန်လူပင်ပန်းပါတယ်။ Dry လုပ်ထားတယ်ဆိုရင်တော့ ဒိုင်း ဒိုင်း ဒိုင်း ပါပဲ။ Mail နဲ့ပတ်သတ်ပြီး ခွဲထားတယ့် component ကိုသွားကြည့်ပြီး ပြင်လိုက်ရုံပါပဲ။ Dry လုပ်ထားတယ့် code ကဖတ်ရလည်းပိုမြန်/လွယ်မယ်ဆိုတာတော့ပြောစရာမလိုတော့ပါဘူး။

Repeated code တွေများနေတဲ့ Project တစ်ခုကို Handle လုပ်ဖို့နဲ့ bugsတွေကို ရှင်းဖို့ဆိုရင် resources တွေကလိုတာထက်ပိုကုန်ကျတတ်ပါတယ်။ Develop လုပ်ရတာလဲပိုကြာ၊ တစ်ဖတ်ကလဲ bugs တွေ နဲ့ဆိုရင်တော့ဖြင့် customer ဆီက complain တွေမကြာခဏ ကြားရတော့မှာပါ။ နောက်တစ်ခုကတော့ dry code လုပ်လိုက်ပြီးဆို code တွေ စနစ်တကျလျော့ကျသွားတဲ့အတွက်Testing စစ်ရတာလွယ်သွားမှာပါ (Unit/Integration Testing).

အခုပြောမှာကတော့ သတိထားစရာအချက်လေးတွေပါ။

code တွေအကုန်လုံးကိုမရမကလိုက် merge & dry လုပ်နေစရာမလိုပါဘူး။ တစ်ခါတစ်ရံမှာ ဆင်သယောင်ထင်ရပြီး Logic ကွဲနေတဲ့code တွေလဲရှိနေနိုင်တဲ့အတွက် သတိထားရမှာဖြစ်ပါတယ်။
နောက်တစ်ခုကတော့ over dried ဖြစ်တဲ့ case ပါ။Logic တစ်ခု Instance တစ်ခုတည်း ရှိတဲ့ code တွေကို လိုက် dry နေစရာမလိုပါဘူး။
ဒီတစ်ခုကတော့ suggestion ပါ။ dry principle ကို code တစ်ခုတည်းမှာသုံးရတာမဟုတ်ပါဘူး၊ ကျန်တဲ့ database design, documentation, testing code အစရှိတဲ့နေရာတွေမှာလည်း apply လုပ်လို့ရပါတယ်။

နောက်ဆုံးအနေနဲ့ပြောချင်တာကတော့ bad code တွေကို bad coders တွေချည်းကပဲရေးလိုက်တာမဟုတ်ပါဘူး။ Management level ကရေးလိုက်တာတွေလည်းပါပါတယ်၊ ဆိုလိုချင်တာက project တစ်ခုစရေးပြီဆို code quality & maintainablity ကိုပါထည့်ပြီးစဉ်းစားထားရမှာပါ။ အခုလက်ရှိ bad quality ဖြစ်တဲ့ project တွေရဲ့ version control ကို ကြည့်လိုက်ပြီဆို codeတွေက deadline နဲ့ တိုက်ပြီးတင်ထားတာကိုတော်တော်များများတွေ့ရမှာပါ။ Dry Principle အောင်မြင်ဖို့ဆို မူလအစတည်းက good planning ဖြစ်ဖို့လိုပါတယ်။ ကိုယ့်code ကြီး bad ဖြစ်နေတာကို ကြည့်နေနိုင်တဲ့ developer မရှိပါဘူး (ရှိကောင်းလည်းရှိနိုင်ပါတယ်)။ Anyway Force changes & tough deadline တွေက developer တွေရဲ့ code quality ကိုကျဆင်းစေနိုင်ပါတယ်။

အခုမှစရေးတာဖြစ်တဲ့အတွက်အမှားတွေပါသွားရင်လည်း sorry ပါဗျာ။

See Ya
13 April 2019
HlaingTinHtun