အခန်း ၁၅ :: Maintenance

Software project တစ်ခု ပြီးဆုံးသွားသည်နှင့် အလုပ်ပြီးသွားခြင်း မဟုတ်ပါ။ အမှန်တကယ်တွင် software lifecycle ၏ အရှည်ကြာဆုံးနှင့် ကုန်ကျစရိတ်/အလုပ်အင်အား အများဆုံး အပိုင်းမှာ maintenance နှင့် evolution ဖြစ်တတ်သည်။ Software system ၏ စုစုပေါင်းကုန်ကျစရိတ် (cost) သို့မဟုတ် အလုပ်အင်အား (effort) ၏ ၆၀% မှ ၈၀% အထိကို maintenance/evolution အတွက် သုံးစွဲရတတ်သည် (TCO သတ်မှတ်ပုံပေါ်မူတည်၍ ဤရာခိုင်နှုန်း ကွာခြားနိုင်သည်)။ ဤအခန်းတွင် maintenance (post-deployment change) ကို အဓိပ္ပါယ်ကျယ်ပြန့်စွာသုံး၍ evolution (feature growth) ကိုလည်း ထည့်သွင်းစဉ်းစားကာ၊ maintenance အမျိုးအစားများ၊ legacy system များကို ကိုင်တွယ်ပုံနှင့် software ၏ သက်တမ်းကို စီမံခန့်ခွဲပုံတို့ အကြောင်း ဖော်ပြသွားပါမယ်။

၁၅.၁ Maintenance ကုန်ကျစရိတ်

Software တစ်ခုကို ရေးပြီးသွားရင် "ပြီးပြီ" လို့ ထင်တတ်ကြပါတယ်။ တကယ်တမ်းက အခုမှ စ တာပါ။ "Build Once, Run Forever" ဆိုတာ မရှိပါဘူး။

Software Lifecycle တစ်ခုလုံးရဲ့ ကုန်ကျစရိတ် (Total Cost of Ownership - TCO) ကို တွက်ကြည့်လိုက်ရင်

ကားတစ်စီး ဝယ်လိုက်သလိုပါပဲ။ ဝယ်တုန်းက သိန်း ၁၀၀၀ ပေးရပေမယ့်၊ ဆီဖိုး၊ ပြင်ဖိုး၊ ဝပ်ရှော့ပို့ခ တွေက နှစ်နဲ့ချီပြီး သုံးလိုက်ရင် ဝယ်ဈေးထက် ပိုများသွားတတ်ပါတယ်။

ဘာကြောင့် Maintenance စရိတ်တွေ ဒီလောက် ကြီးနေရတာလဲ။

1. Technical Debt (နည်းပညာဆိုင်ရာ အကြွေး)

Code ရေးတုန်းက "မြန်ရင် ပြီးရော" ဆိုပြီး ဖြတ်လမ်းနည်းတွေ သုံးခဲ့တာတွေ၊ Variable Name တွေကို တွေ့ကရာ ပေးခဲ့တာတွေ၊ Test တွေ မရေးခဲ့တာတွေဟာ "အကြွေး" ယူထားတာနဲ့ တူပါတယ်။

နောက်ပိုင်း ပြန်ပြင်တဲ့အခါ အဲဒီ အကြွေးတွေကို အတိုးနဲ့ အရင်း ပေါင်းဆပ်ရသလိုပါပဲ။ သာမန် ၁ နာရီနဲ့ ပြီးမယ့် အလုပ်က Code တွေ ရှုပ်နေတဲ့အတွက် ၅ နာရီလောက် ကြာသွားနိုင်ပါတယ်။

2. Staff Turnover (လူအပြောင်းအလဲ)

မူရင်း ရေးခဲ့တဲ့ Developer တွေ ထွက်သွားပြီး လူသစ်တွေ ရောက်လာတဲ့အခါ System ကို နားလည်ဖို့ အချိန်ပေးရပါတယ်။

Bus Factor လို့ ခေါ်ပါတယ်။ Team ထဲက Key Person တစ်ယောက် ကားတိုက်ခံရရင် (Bus)၊ Project ရပ်သွားမလား ဆိုတာ စဉ်းစားရပါမယ်။ Documentation သေချာ မရှိရင် လူသစ်တွေ အတွက် ငရဲပါပဲ။

3. Software Aging (Erosion)

Software တွေက သက်မဲ့ ဖြစ်ပေမယ့် ဟောင်းနွမ်းသွားတတ်ပါတယ်။

Code တွေက မပြောင်းပေမယ့်၊ သူနဲ့ တွဲသုံးထားတဲ့ OS တွေ၊ Library တွေ၊ Third-party API တွေက ပြောင်းသွားတတ်ပါတယ်။ ဒါတွေကို လိုက်မပြင်ရင် (Upgrade မလုပ်ရင်) Security ပြဿနာတွေ တက်လာပြီး နောက်ဆုံးမှာ သုံးမရတော့တဲ့ အထိ ဖြစ်သွားနိုင်ပါတယ်။

၁၅.၂ Types of Maintenance

Maintenance ဆိုတာ ပျက်မှ ပြင်တာ (Bug Fix) တစ်ခုတည်း မဟုတ်ပါဘူး။ အမျိုးအစား ၄ မျိုး ရှိပါတယ်။

1. Corrective Maintenance (အမှား ပြင်ဆင်ခြင်း)

System မှာ Bug တွေ့လို့၊ ဒါမှမဟုတ် Error တက်လို့ ဝင်ပြင်တာပါ။

ဒီအပိုင်းက များနေတယ် ဆိုရင်တော့ Code Quality မကောင်းလို့ ဖြစ်ဖို့ များပါတယ်။

2. Adaptive Maintenance (လိုက်လျောညီထွေ ဖြစ်အောင် ပြင်ခြင်း)

Software မှာ အမှား မရှိပါဘူး။ ဒါပေမယ့် ပတ်ဝန်းကျင် (Environment) ပြောင်းသွားလို့ လိုက်ပြင်ရတာပါ။

ဥပမာ -

3. Perfective Maintenance (ပိုကောင်းအောင် မွမ်းမံခြင်း)

ဒါက အလုပ် အများဆုံး (50% ကျော်) ဖြစ်တတ်ပါတယ်။ User တွေက Feature အသစ် လိုချင်လို့၊ ဒါမှမဟုတ် Performance ပိုမြန်ချင်လို့၊ UI ပိုလှချင်လို့ ပြင်ရတာတွေပါ။

"Software က မသေမချင်း ပြောင်းလဲနေရမယ်" (Software must evolve) ဆိုတဲ့ သဘောတရားပါပဲ။

4. Preventive Maintenance (ကြိုတင် ကာကွယ်ခြင်း)

အခု လောလောဆယ် ဘာပြဿနာမှ မရှိပေမယ့်၊ နောင်တစ်ချိန် ဒုက္ခ မရောက်အောင် ကြိုလုပ်ထားတာပါ။

ဒါမျိုးတွေက လုပ်နေတုန်းမှာ User အတွက် ဘာမှ ထူးခြားမှု မရှိပေမယ့်၊ ရေရှည်မှာ System ကို ကျန်းမာစေ (Healthy) ပါတယ်။


pie title Maintenance အလုပ် ခွဲဝေမှု (ခန့်မှန်းခြေ)

    "Perfective (Feature အသစ်/Performance)" : 55

    "Adaptive (Environment အပြောင်းအလဲ)" : 20

    "Corrective (Bug ဖာထေးခြင်း)" : 20

    "Preventive (Refactoring)" : 5

၁၅.၃ Legacy Systems: Strategies for Re-engineering and Migration

Legacy System ဆိုတာ နည်းပညာဟောင်းတွေနဲ့ ရေးထားပြီး၊ ပြင်ရခက်ပေမယ့် ကုမ္ပဏီအတွက် အရမ်းအရေးပါလို့ ဖျက်ပစ်လို့ မရတဲ့ System ကြီးတွေကို ခေါ်ပါတယ်။

"မထူးဇာတ်ခင်းနေရတဲ့ စနစ်ကြီး" ပေါ့။ Documentation မရှိ၊ ရေးတဲ့လူ မရှိတော့၊ Code က ဘာလုပ်မှန်း မသိတော့တဲ့ အခြေအနေမျိုးပါ။

Legacy System တွေကို ကိုင်တွယ်ဖို့ နည်းလမ်း (Strategies) တွေ ရှိပါတယ်။

1. Encapsulate (ဖုံးထားလိုက်ခြင်း)

အထဲက Code တွေ ဘယ်လောက် ရှုပ်ရှုပ်၊ မပြင်တော့ပဲ သူ့အပေါ်ကနေ API အသစ် တစ်ခု ခံပြီး ဖုံးလိုက်တာပါ။

အပြင်လူ (Client) က API အသစ်နဲ့ပဲ ဆက်သွယ်တဲ့အတွက် အထဲက ရှုပ်နေတာကို မသိတော့ပါဘူး။

2. Rehosting (Lift and Shift)

Code ကို မပြင်ပါဘူး။ ဒါပေမယ့် Server အဟောင်းကြီး ပေါ်ကနေ Cloud (AWS, Azure) ပေါ် ရွှေ့လိုက်တာပါ။

3. Strangler Fig Pattern (သဖန်းပင် နည်းဗျူဟာ)

သဖန်းပင်က သစ်ပင်ကြီးတစ်ပင်ကို နွယ်တွေနဲ့ ရစ်ပတ်ပြီး တဖြည်းဖြည်း ကြီးထွားလာသလိုမျိုးပါ။

System အဟောင်းကြီးကို ချက်ချင်း ဖျက်မပစ်ပဲ၊ Feature အသစ်တွေကို System အသစ် (Microservices) အနေနဲ့ ဘေးကနေ တစ်ခုချင်း စဆောက်ပါတယ်။ ကြာလာတော့ System အဟောင်းမှာ လုပ်စရာ မကျန်တော့တဲ့ အချိန်ကျမှ အပြီးသတ် ဖျက်ပစ်လိုက်တာပါ။

Risk အနည်းဆုံးနဲ့ အအောင်မြင်ဆုံး နည်းလမ်း ဖြစ်ပါတယ်။

4. Full Replacement (Big Bang)

အဟောင်းကို လုံးဝ ဖျက်ပစ်ပြီး အသစ် ပြန်ရေးတာပါ။

၁၅.၄ Software Reuse and Component-Based Development

Software ရေးတယ် ဆိုတာ အသစ် တီထွင်နေတာ မဟုတ်ပါဘူး။ သူများ ရေးပြီးသားတွေ (Libraries, Frameworks, Components) ကို ပြန်လည် တပ်ဆင်တာ (Assemble) နဲ့ ပိုတူပါတယ်။

Software Reuse ဆိုတာ အဲဒါပါပဲ။ "ဘီး ကို အသစ် ပြန်မထွင်နဲ့" (Don't Reinvent the Wheel) ဆိုတဲ့ စကားလိုပါပဲ။

Pros (အားသာချက်)

Cons (အားနည်းချက် - The Price of Reuse)

သူများဟာ ယူသုံးရတာ ကောင်းပေမယ့် Dependency Hell နဲ့ Supply Chain Risk ကို သတိထားရပါမယ်။

Component-Based Development (CBD)

Lego တုံးလေးတွေ ဆက်သလိုပါပဲ။ Function တစ်ခုချင်းစီကို သီးသန့် Component (e.g., PaymentComponent, LoginModal) တွေ အနေနဲ့ ရေး၊ ပြီးမှ ပြန်ဆက်သုံးတာပါ။

Microservices Architecture ဆိုတာ CBD ရဲ့ အကြီးစား ပုံစံပါပဲ။

၁၅.၅ Version Management and Release Planning

Version Management (SemVer)

Software Version တပ်တဲ့အခါ v1.0 လို့ လျှောက်ပေးလို့ မရပါဘူး။ Semantic Versioning (SemVer) စနစ်ကို အခုနောက်ပိုင်း သုံးကြပါတယ်။

Format: Major.Minor.Patch (e.g., 1.5.2)

  1. Major (Breaking Change): 1.x.x -> 2.0.0

    API အဟောင်းတွေ ဖျက်လိုက်လို့၊ ဒါမှမဟုတ် လုံးဝ ပုံစံပြောင်းသွားလို့ အဟောင်းသုံးနေတဲ့ သူတွေ Error တက်နိုင်တဲ့ အခြေအနေမျိုးပါ။

  2. Minor (New Feature): 1.5.x -> 1.6.0

    Feature အသစ် ပါလာတယ်။ ဒါပေမယ့် အဟောင်းသုံးနေတဲ့ သူတွေ ဘာမှ မဖြစ်ဘူး (Backward Compatible)။

  3. Patch (Bug Fix): 1.5.2 -> 1.5.3

    Code လွဲနေတာလေးတွေ ပြင်လိုက်တာ။ Feature အသစ် မပါဘူး။

Release Strategies

User ဆီကို Version အသစ် ဘယ်လို ပို့မလဲ။