Refactoring Tips ၄ ခု
ဒါကတော့ ကျနော့အတွေ့အကြုံအရ application တွေရေးရင်းသတိထားမိတဲ့ refactoring tips ၄ ခုလေးပါ။
- DRY ဖြစ်အောင်လုပ်ပါ
- KISS လုပ်ပါ 😁
- APIs များအနေနဲ့ခွဲဲဲရေးပါ
- Documentation ရေးပါ
DRY ဖြစ်အောင်လုပ်ပါ
ဒါကတော့ ကြားဖူးနေကျပဲနေမှာပါ don't repeat yourself ဆိုတဲ့အတိုကောက်လေးပေါ့ဗျာ application တစ်ခုလုံးမှာ တူသယောင်ယောင်ရှိတဲ့ methods တွေ variables တွေ အများကြီးရှိပါတယ်။ app ကအရမ်းကြီးလာရင် repeat ဖြစ်နေလို့ ဖြစ်နေမှန်းမသိတာတွေရှိပါတယ်။
တူသယောင်ရှိသောစာလုံးများ
ဥပမာ တချို့ developer တွေက product ဖျက်တာကို removeProduct လို့ရေးတယ် တချို့က deleteProduct လို့ရေးတယ် အဲဒါတွေတကယ်တမ်းသွားကြည့်ရင် အလုပ်လုပ်တာတွေချင်းကအတူတူပဲဖြစ်နေတာမျိုးရှိပါတယ်။
- image / photo / picture
- ajax / fetch / post
- get / retrieve
- save / store
- path / url / link
- remove / delete
- btn / button
- components / parts / sections
- data / info
- build / generate
ဒီထက်မက တူတတ်တာတွေရှိနိုင်ပေမယ့် အဓိကတူတတ်တာတွေပဲကျနော်ရေးထားတာဖြစ်ပါတယ်။
KISS လုပ်ပါ 😁
kiss ကတော့ keep it short and simple ဆိုတဲ့ အတိုကောက်လေးပေါ့ဗျာ ကျနော်ဖတ်ဖူးတဲ့စာအရ coding ရေးကောင်းတဲ့ developer ရဲ့ code ဟာနောက်လူတွေဖတ်ရအရမ်းလွယ်တယ်တဲ့ advanced code တွေဖြစ်နေစရာမလိုဘူးပေါ့ဗျာ
ဥပမာ upload form တစ်ခုကိုရေးရင် ဒီအတိုင်း ရိုးရိုး form လောက်နဲ့ပြီးလို့ရတဲ့ ကိစ္စမျိုးဆို ဒီအတိုင်းပဲထားသင့်ပါတယ် တချို့ developer တွေက upload form ကို ajax ပုံစံပြောင်းတာတို့ multiple upload ကို progress bar တွေနဲ့ပြတာတို့ ထည့်ပြီးလန်းသထက်လန်းအောင် လုပ်တတ်ကြပါတယ်
အဲဒါ မကောင်းဘူးလားဆိုတော့ ကောင်းတာတော့ကောင်းပါတယ် (အဲဒါတွေ တကယ်လိုအပ်လားဆိုတာတော့သေချာတွေးဖို့လိုပါတယ်)
ဒါပေမယ့် ရေရှည် maintain လုပ်ရတဲ့အပိုင်းမှာကြတော့ task တွေပိုလာမှာပဲဖြစ်ပါတယ် code တွေပိုလာမယ် test တွေပိုလုပ်ရမယ် upload process ရိုးရိုးရှင်းရှင်းကြီးကို ကိုယ်ကိုယ်တိုင် မရှုပ်ရှုပ်အောင်လုပ်သလိုဖြစ်သွားမှာပဲဖြစ်ပါတယ်။
APIs များအနေနဲ့ခွဲရေးပါ
သေးတဲ့ app တွေကပြဿနာမရှိပေမယ့် အရမ်းကြီးတဲ့ app တွေဆို backend logic တွေတော်တော်ရှုပ်ထွေးကုန်တာမျိုးရှိပါတယ် Sass (software as a service) လိုမျိုးလာပြီဆို client ပေါင်းမြှောက်များစွာကို setup လုပ်ပေးရတာတွေပါလာမယ် mobile app အတွက် desktop app တွေအတွက်စဥ်းစာလာရပြီဆို backend logic တစ်ခုလုံး စုပြုံပြီး တစ်နေရာတည်းကနေလုပ်ဖို့ အဆင်မပြေတော့ပါဘူး။ တစ်ခုပြင်ရင် ကျန်တာသွားထိတာမျိုး ဖြစ်လာတတ်ပါတယ်။ အဲဒါမျိုးဖြစ်ရင် sever တစ်ခုလုံး down သွားတာတို့ဖြစ်တတ်ပါတယ်။
ပြီးတော့ တစ်ခုခုကိုပြင််််ရင် app testing ကို အစ ကနေ အဆုံးပြန်လုပ်ရပါတယ် ဘာလို့လဲဆိုတော့ repo တစ်ခုတည်းဖြစ်နေတာကြောင့်ပါ။
repo တွေခွဲထုတ်ပြီး api တွေနဲ့သူဟာနဲ့သူခွဲထုတ်ထားရင် maintain လုပ်ရတဲ့ repos များလာပေမယ့် သပ်သပ်စီဖြစ်တဲ့အတွက် တစ်ခုထိရင် ကျန်တာသိပ်ဂရုစိုက်စရာမလိုပါဘူး အဲဒီထိထားတဲ့ repo ကိုပဲ testing လုပ်လို့ရပါတယ် ပြီးတော့ debugging လိုက်ရင်လည်းအရမ်းရိုးရှင်းသွားပါတယ်။
ဒါကြောင့် ကျနော်တို့ fontend မှာ component တွေခွဲသလိုပဲ backend တွေကိုလဲအတတ်နိုင်ဆုံး plug and play ဖြစ်အောင်ခွဲထုတ်သင့်ပါတယ်။ ဒီနေရာမှာ google ရဲ့ addons, trello ရဲ့ powerups စတာတွေ လိုမျိုး မသွားနိုင်သေးရင်တောင် app flow, logic စတာတွေကို သူ့အပိုင်းနဲ့သူခွဲထုတ်ပြီး api နဲ့ချိတ်ဆက်ယူသင့်ပါတယ်။
ဒါကတော့ https://www.clickittech.com/devops/microservices-vs-monolith/ ကစာလေးပေါ့ဗျာ
Due to its bulky size and higher dependencies, build and deploy mechanisms in monoliths are more complicated and time-consuming. Microservices are less resource-sensitive and are built to scale. Since the modules are decoupled from each other, it is easier to build and deploy.
ခြုံပြောရရင် Monolith လိုမျိုး တစ်နေရာတည်းပြုံပြီး ရှုပ်ရှုပ်ထွေးထွေးရေးတာထက် Microservices လိုမျိုး logic တွေ feature တွေသပ်သပ်ခွဲရေးရင် ပိုမိုလွယ်ကူစေပါတယ်။
Documentation ရေးပါ
Developer တွေသိပ်မကြိုက်ကြတာ documentation ရေးတာပဲဖြစ်ပါတယ်။ ကျနော်ကိုယ်တိုင်လည်းသိပ်မရေးဘူး ဒါပေမယ့် အပျင်းမကြီးပဲရတဲ့အချိန်လေးမှာရေးထားကြည့်လိုက်ပါ တချိန်ချိန်ကျရင် ကိုယ်ရေးခဲ့တဲ့ project ကိုပြန်လာဖတ်တိုင်းလွယ်လွယ်ကူကူနားလည်နေပါလိမ့်မယ်။
ကျနော်ပြောတဲ့ documentation ရေးတယ်ဆိုတာ ကိုယ်ရေးတဲ့ code ရဲ့အပေါ်မှာ comment block လိုမျိုးလိုက်ရေးတာမဟုတ်ပါဘူး appflow တစ်ခုလုံး ဘယ်လိုအလုပ်လုပ်တယ်ဆိုတာမျိုးကို documentation သပ်သပ်တစ်ခု ရေးတာမျိုးပဲဖြစ်ပါတယ်။
ဝင်ရောက်ဖတ်ရှုပေးတဲ့အတွက် ကျေးဇူးပါ ✌🏻