“နောက်မှရှင်းမယ်” ဆိုတာ တကယ်ရောရှင်းဖြစ်ရဲ့လား?

“ဒီတစ်ခါတော့ ဒီလိုပဲရေးလိုက်မယ်။ နောက်မှ Refactor ပြန်လုပ်မယ်…” Developer တော်တော်များများ ပြောဖူးကြမယ့်စကားပါ။ Deadline ကပ်နေတယ်။ Feature က အမြန်ထွက်ဖို့လိုတယ်။ Requirement က မရှင်းသေးဘူး။ ဒါမှမဟုတ် ကိုယ်တိုင်ကလည်း “ဒီဟာက အခုအတွက်ပဲ” လို့ထင်တယ်။ ဆိုတော့ အခုအလုပ်ဖြစ်ရုံလောက်ရေးလိုက်တယ်။ ပြီးတော့ “နောက်မှရှင်းမယ်” လို့ထားလိုက်တယ်။ အဲ့ဒါကို Software Engineering မှာ Technical Debt လို့ခေါ်တယ်။

Technical Debt ဆိုတာ Code မကောင်းတာတိုင်းကို ပြောတာမဟုတ်ဘူး။ အခုအချိန်မှာ အမြန်ပြီးအောင် Short-term Solution တစ်ခုကို ရွေးလိုက်ပြီး၊ နောက်ပိုင်းမှာ အဲ့ဒီဆုံးဖြတ်ချက်ကြောင့် ထပ်ပြီးအချိန်၊ effort နဲ့ complexity ပေးဆပ်ရတာမျိုးကို Technical Debt လို့ပြောလို့ရတယ်။

တကယ်တော့ အကြွေးယူတာနဲ့တော်တော်တူတယ်။ အခု ငွေလိုလို့ ချေးလိုက်တယ်။ အခု ပြဿနာပြေလည်သွားတယ်။ ဒါပေမယ့် အကြွေးက ပျောက်မသွားဘူး။ အတိုးပါလာတယ်။ Software မှာလည်း အတူတူပဲ။

ထားပါတော့ Login System တစ်ခုရေးနေတယ်။ အခု requirement က ရိုးရိုး Username + Password Login ပဲ။ ဆိုတော့ ကိုယ်က User table ထဲမှာ username, password လောက်ထည့်ပြီး အမြန်ရေးလိုက်တယ်။ အလုပ်လည်းလုပ်တယ်။ Project ကလည်း ပြီးသွားတယ်။

နောက်သုံးလလောက်ကြာတော့ Requirement က ပြောင်းလာတယ်။ “Google Login ပါထည့်မယ်။” “Email နဲ့ Login လုပ်လို့ရရမယ်။” “User တစ်ယောက်မှာ Role တွေရှိမယ်။” “Admin, Manager, Staff ခွဲမယ်။” “Password Reset ပါရမယ်။”

အဲ့ဒီအချိန်ကျမှ အစက username/password နှစ်ခုလောက်နဲ့ စခဲ့တဲ့ Design ကို ပြန်ဖွင့်ကြည့်ရတယ်။ အခုတော့ Table တွေပြန်ပြင်ရတယ်။ Authentication Logic ပြန်ပြင်ရတယ်။ API တွေပြန်ပြင်ရတယ်။ Existing Code တွေပါ ထိသွားတယ်။

အစက ၁ ရက်နဲ့ပြီးမယ့် Feature က နောက်ပိုင်းမှာ ၃ ရက်၊ ၄ ရက်စာ အလုပ်ဖြစ်လာတတ်တယ်။ ဒါက Technical Debt ရဲ့ ပုံစံတစ်ခု။

နောက်တစ်ခုကတော့ Copy-Paste Debt။ အခု Feature တစ်ခုလုပ်ရင်း “ဒီ Logic က အပေါ်ကဟာနဲ့တူတယ်။ Copy လုပ်ပြီး နည်းနည်းပြင်လိုက်မယ်။” ဆိုပြီး ရေးလိုက်တယ်။ အခုအဆင်ပြေတယ်။ နောက်တစ်နေရာမှာလည်း အတူတူ Logic လိုလာတယ်။ ထပ် Copy လုပ်တယ်။

တစ်နေရာမှာ Bug တက်တယ်။ အဲ့ဒီ Logic ကို သုံးထားတဲ့နေရာတွေ ဘယ်နှစ်ခုရှိလဲ လိုက်ရှာရတယ်။ တစ်နေရာပြင်ပြီး တစ်နေရာမပြင်မိဘူး။ နောက်တစ်နေရာမှာ Bug ထပ်တက်တယ်။ အခုတော့ Code ရေးတာထက် “ဒီ Logic ကို ဘယ်နေရာတွေမှာ Copy လုပ်ထားလဲ” လိုက်ရှာနေရပြီ။ အဲ့ဒါကလည်း Debt ပဲ။

Database ပိုင်းမှာလည်း ဒီလိုပဲ။ အစက Project သေးသေးလေးဆိုတော့ “ဒီ Field တစ်ခုကို ဒီ Table ထဲမှာပဲ ထည့်ထားလိုက်မယ်။” “Data နည်းနည်းပဲရှိတာ၊ Index မလိုသေးပါဘူး။” “ဒီ Query လေးပဲသုံးလိုက်မယ်။” ဆိုပြီးသွားလို့ရတယ်။ Data က rows ၁,၀၀၀ လောက်ဆို ဘာမှမဖြစ်ဘူး။

နောက်ပိုင်း Data က ၁၀ သန်း၊ သန်း ၂၀ မျိုး ဖြစ်လာတဲ့အခါမှ Query တစ်ခု Run တာကို စောင့်နေရပြီ။ အဲ့ဒီအချိန်မှာ Index ပြန်စဉ်းစားရတယ်။ Query ပြန် Optimize လုပ်ရတယ်။ Database Structure ပြန်စဉ်းစားရတယ်။ အစက “အခုတော့ အလုပ်ဖြစ်တယ်” ဆိုတဲ့ ဆုံးဖြတ်ချက်က နောက်ပိုင်းမှာ Performance Debt ဖြစ်လာတယ်။

တစ်ခါတလေ Technical Debt က Developer တစ်ယောက်ရဲ့ Code ထဲမှာပဲ ရှိတာမဟုတ်ဘူး။ Architecture ထဲမှာလည်း ရှိတယ်။ ဥပမာ Project စစချင်းမှာ “Service Layer မလိုသေးပါဘူး။ Controller ထဲမှာပဲ Logic ရေးလိုက်မယ်။ Project က သေးသေးလေးပဲ။” ဆိုပြီး စလိုက်တယ်။

Project ကြီးလာတယ်။ Controller ထဲမှာ Business Logic တွေများလာတယ်။ File တစ်ဖိုင်ထဲမှာ Code 2,000 lines ဖြစ်လာတယ်။ နောက် Developer အသစ်ဝင်လာတယ်။ သူ့ကိုရှင်းပြရတာက “ဒီ Function က ဒီနေရာကနေ Call လာတာ…” “ဒီ Variable ကို ဒီနေရာမှာ ပြောင်းရင် ဒီ API ပျက်မယ်…” “ဒီ Code ကို မထိနဲ့…” ဆိုတာတွေပဲ ဖြစ်လာတယ်။

အဲ့ဒီအချိန်မှာ Code က အလုပ်လုပ်နေသေးတယ်။ ဒါပေမယ့် ပြင်ရတာကြောက်လာပြီ။ အလုပ်လုပ်နေတယ်ဆိုတာ Healthy ဖြစ်နေတယ်လို့ မဆိုလိုဘူး။

ဒါပေမယ့် Technical Debt ဆိုတာ မကောင်းတဲ့အရာတစ်ခုလုံးတော့ မဟုတ်ဘူး။ တစ်ခါတလေ Debt ယူတာက မှန်တယ်။ Startup တစ်ခုက Product Idea တစ်ခုကို Market ထဲအမြန်စမ်းချင်တယ်ဆိုပါစို့။ Perfect Architecture တစ်ခုဆောက်ဖို့ ၃ လကြာအောင် စောင့်မယ့်အစား MVP ကို ၂ ပတ်နဲ့ ထုတ်ပြီး User တွေဆီက Feedback ယူလိုက်တာက ပိုတန်ဖိုးရှိနိုင်တယ်။ အဲ့ဒီအချိန်မှာ Technical Debt ယူထားတာဟာ Strategic Decision ဖြစ်နိုင်တယ်။

ပြဿနာက Debt ယူတာမဟုတ်ဘူး။ Debt ယူထားတာကို မေ့သွားတာ။

“ဒီဟာကို နောက်မှ Refactor လုပ်မယ်” ဆိုရင် အဲ့ဒီ “နောက်မှ” က ဘယ်တော့လဲ? Next Sprint လား။ Next Month လား။ Next Release လား။ ဒါမှမဟုတ် Project ထဲမှာ ဘယ်သူမှမသိတော့တဲ့ Future Archaeology တစ်ခုဖြစ်သွားပြီလား။

Technical Debt ရဲ့ အန္တရာယ်က တစ်နေ့တည်းနဲ့ Project ကို မဖျက်ဘူး။ နည်းနည်းစီ စုလာတယ်။ ဒီနေ့ Shortcut တစ်ခု။ မနက်ဖြန် Copy-Paste တစ်ခု။ နောက်တစ်ပတ် Quick Fix တစ်ခု။ ပြီးတော့ နောက်ဆုံးမှာ Feature အသစ်တစ်ခုရေးတိုင်း အရင် Code တွေကို ရှောင်ပြီး ရှောင်ပြီး ရေးနေရတယ်။ Project က ကြီးလာတာနဲ့အမျှ Development Speed က တဖြည်းဖြည်းကျလာတယ်။ ဒါကို Technical Debt ရဲ့ Interest လို့ တွေးလို့ရတယ်။

ဒါဆို Developer တစ်ယောက်အနေနဲ့ ဘာလုပ်သင့်လဲ? အရာအားလုံးကို Perfect ဖြစ်အောင်လုပ်ဖို့ မလိုပါဘူး။ Shortcut ယူရင် Shortcut ယူထားတယ်ဆိုတာ သိထားဖို့ ပိုအရေးကြီးတယ်။

“ဒီ Code က အခုအတွက်ပဲ။ နောက်ပိုင်း Refactor လုပ်ရမယ်” ဆိုရင် Issue တစ်ခုဖွင့်ထား။ TODO ထား။ Ticket ထဲမှာ မှတ်ထား။ Technical Debt ကို Visible ဖြစ်အောင်လုပ်ထား။ ပြီးတော့ Sprint Planning လုပ်တဲ့အချိန်မှာ Feature အသစ်တွေနဲ့အတူ Debt ပြန်ဆပ်ဖို့လည်း အချိန်ထည့်စဉ်းစား။

အရေးကြီးဆုံးကတော့— Technical Debt မယူဘူးဆိုတာနဲ့ Developer ကောင်းဖြစ်နေပြီ မဟုတ်ဘူး။ ဘယ်အချိန်မှာ Debt ယူသင့်တယ်၊ ဘယ်အချိန်မှာ ပြန်ဆပ်သင့်တယ်ဆိုတာ သိတာက Software Engineering ပိုဆန်တယ်။

“နောက်မှရှင်းမယ်” ဆိုတာ ပြဿနာမဟုတ်ဘူး။ “နောက်မှ” ဆိုတာ ဘယ်တော့လဲ မသိတော့တာက ပြဿနာ။

Code က အကြွေးတင်ထားရင် ဘဏ်က ဖုန်းမဆက်ဘူး။ ဒါပေမယ့် နောက် Feature တစ်ခုရေးတိုင်း ကိုယ်ကပဲ အတိုးပြန်ပေးနေရမှာ။