Code တွေ ဘယ်လို ရှုပ်ကြသလဲ
ဒီရက်ပိုင်း ဖတ်ဖြစ်နေတဲ့ စာအုပ်ကအကြောင်းအရာတွေကို ကြိုက်လို့ ဖောက်သည်လာချတာ။ တော်တော်များများ ပြောကြတယ် code တွေက ရှုပ်နေတယ်တဲ့ code က ဘယ်လိုရှုပ်တာလဲ complex ဖြစ်တယ်ဆိုတာ ဘယ်လိုဟာမျိုးကို ခေါ်တာလဲ။ John Ousterhout ကတော့ complex ဖြစ်နေပြီဆိုတာကို symptom သုံးခုနဲ့ သတ်မှတ်ပါတယ်တဲ့။
1. Change amplification
Logic တစ်ခုကိုပြင်ဖို့ရာ code တွေ နေရာအများကြီးကို လိုက်ပြင်နေရပြီဆိုရင် ဒါ complex ဖြစ်တာပါဘဲတဲ့။ အဲ့တာက Don’t repeat yourself ဆိုတဲ့ DRY ကို မလိုက်နာခဲ့လို့လည်းဖြစ်နိုင်တယ်။ ဒါမှမဟုတ် ကိုယ့် software architecture က flexible မဖြစ်လို့ design ချကတည်းက လွဲခဲ့လို့လည်း ဖြစ်နိုင်တယ်။ ဘယ်လိုဖြစ်ဖြစ် တစ်ခုထိတာနဲ့ နေရာပေါင်းစုံလိုက်ပြသနာတက်နေပြီ အဲ့ code ကို ရှုပ်တယ်လို့ ပြောနိုင်ပါတယ်။
2. Cognitive load
Assign ချလိုက်တဲ့ task တစ်ခုကိုပြီးမြောက်ဖို့ အဲ့ developer သိရမယ့်အရာတွေက တအားများနေရင်လည်း ဒါ complex ဖြစ်တာပါဘဲတဲ့။ သူ့ကိုခိုင်းလိုက်တာက module တစ်ခုပဲထိရမယ်။ ဒါပေမယ့် အဲ့ module ကိုထိဖို့ဆို ကျန်တဲ့ module သုံးခုလောက်ကိုပါ သိရမယ်ဆိုရင် ဒါက complex ဖြစ်တယ်လို့ ဆိုနိုင်ပါတယ်။ ဒါမျိုးဘာကြောင့်ဖြစ်သလဲဆိုတော့ တအားတော်တဲ့ developer ရေးထားတဲ့ code ကိုဖြစ်စေ တအားညံ့တဲ့ developer ရေးထားတဲ့ code ကိုဖြစ်စေ ဖတ်ရတဲ့အခါ တွေ့ရတတ်ပါတယ်။ တအားတော်တဲ့ developer ကျ တစ်ခါတလေ အတော်လွန်ပြီး မလိုအပ်ဘဲ abstraction layer တွေ စွတ်ထည့်တာ premature optimization တွေလုပ်တာ (over engineering) လူသိနည်းတဲ့ library တွေ pattern တွေ term တွေသုံးတာ ဒါတွေကြောင့်လည်းဖြစ်နိုင်တယ်။ တအားညံ့တဲ့ developer ဆိုရင်တော့ သူ့ဘာသူတောင် ဘာရေးနေမှန်းသိချင်မှသိမှာဆိုတော့ ဆိုဖွယ်ရာမရှိဘူး။ ဒါကြောင့် team နဲ့ အလုပ်လုပ်တဲ့အခါ တော်လွန်းရင်လည်းမကောင်းသလို လျှော်လွန်းရင်လည်းမကောင်း lead လုပ်တဲ့သူများဟာ ကိုယ့် team မှာရှိတဲ့ developer တွေရဲ့ capacity ကိုယ်မရှိတော့ရင် handover လုပ်မယ့် developer တွေရဲ့အနေအထား company နဲ့ project ရဲ့ ရေရှည်အခြေအနေ ဒါတွေအပေါ်မူတည်ပြီး ကိုယ်လုပ်နိုင်တာကိုခဏထား ရေရှည်မှာ အများအတွက်သင့်တော်တဲ့လမ်းကို အဓိကထားရွေးချယ်သင့်ကြောင့် မေတ္တာရှေ့ထား မြွက်ကြားလိုက်ရပါသဗျား။
3. Unknown unknown
သူက နည်းနည်းသိမ်မွေ့တယ်။ Cognitive load ကိုမှ အကြီးစားပြောလို့ရတယ်။ Cognitive load ကမှ learning curve ရှည်တာ။ Unknown unknown ကကျ ကောက်ရိုးပုံထဲအပ်ပျောက်ရှာသလို ဘဲဉအစရှာမရသလို ဘယ်ကဘယ်လိုစရမလဲကိုမသိတာကို ပြောချင်တာ။ အဲ့တာက ရုတ်ချည်း နေ့ချင်းညချင်း ထဖြစ်တာတော့မဟုတ်ဘူး။ ဒါလောက်ကတော့ ရပါတယ်ကွာဆိုတာလေးတွေ တဖြည်းဖြည်း စုစုပြီး accumulate ဖြစ်လာတဲ့အခါ နောက်ဆုံးမှာ ကိုယ့်ကို လည်းပင်းထညှစ်တာပဲ။ အသေးအမွှားလေးတွေ variable name ပေးတာ function name ပေးတာကအစ ဂရုမစိုက်ခဲ့လို့ အဲ့လို သေးသေးသေးသေးလေးတွေ များလာတဲ့အခါ မရှုနိုင်မကယ်နိုင်ဖြစ်သွားတာမျိုးကိုလည်း complex ဖြစ်တယ်လို့ သုံးကြပါသတဲ့။ Task တစ်ခုပြီးမြောက်ဖို့ ဘာတွေသိရမလဲတောင် မသိဘူးဆိုတာမျိုးက handover process သေသေချာချာမလုပ်ခဲ့ရလို့လည်း ဖြစ်နိုင်သလို ကိုယ်ရေးထားတာကို ကိုယ်ဘာမှန်းမသိတော့တာလည်း ဖြစ်နိုင်တယ်။ Later means never လို့ဆိုတယ်။ နောက်မှဆိုတဲ့ကိစ္စတွေက မလုပ်ဖြစ်ဖို့များတယ်။ ဒါပေမယ့် ဒီလိုကိစ္စမျိုးကိုလည်း ဘယ်သူမှ ရှောင်လွှဲလို့မရပြန်ဘူး။ အထူးသဖြင့် start-up တွေမှာ အဖြစ်များကြတယ်။ အဲ့တာကြောင့် good problem solving skill တို့ prior working experience with large and comple codebase တို့ဆိုတာ ဒီကနေ့ job description တွေထဲမှာ ပါလာရတာပဲ။
ဟုတ်ပြီး အဲ့တော့ အပေါ်က complexity ၃ ချက်ကို developer ကြောင့် client ကြောင့် PM ကြောင့်ဆိုတဲ့ လူပုဂ္ဂိုလ်အပေါ်အပြစ်မဖို့ဘဲ ဘယ်လိုအကြောင်းအရာတွေက ဒီလို complexity ဖြစ်စေတာလဲဆိုတော့ နှစ်ချက်ရှိပါသတဲ့။ ပထမတစ်ချက်က
1. Dependencies
Code ရေးရင် dependency ကို ရှောင်လွှဲလို့မရဘူး။ ရေးလိုက်တဲ့ class တိုင်းသည် အခြား class တစ်ခုခုကနေ ယူသုံးဖို့ ရေးတာဖြစ်တယ်။ ဒီအတွက် dependency ကတော့ ရှိမှာပဲ။ ဒါပေမယ့် dependency တွေများလွန်းသွားတဲ့အခါ အပေါ်ကပြောတဲ့ cognitive load ကို ဖြစ်စေတယ်။
2. Obscurity
ဒါကတော့ တော်တော်လေးရိုးရှင်းတယ်။ ဘာကြောင့်ရှုပ်သလဲဆိုရင် မရှင်းလို့ ရှုပ်တာပါ။ ဘာကမရှင်းတာလဲဆိုရင် variable name ကမရှင်းတာ function name ကမရှင်းတာ variable/function usage က မရှင်းတာ object composition ကမရှင်းတာ dependency graph က မရှင်းတာ ဒါတွေမရှင်းရင် unknown unknow ဖြစ်ပြီး code ကို complex ဖြစ်စေပါတယ်။
ဒီနေ့တော့ code တွေ ဘာကြောင့်ရှုပ်သလဲဆို ဘယ်လိုရှုပ်သလဲဆိုတာကို ပြောပြခဲ့တာပဲဖြစ်ပါတယ်။ နောက်အချိန်ရရင် မရှုပ်အောင် ဘာတွေလုပ်လို့ရသလဲဆိုတာ ဆက်ရေးသွားပါဉီးမယ်။
Reference:
John Ousterhout. (2018). A Philosophy of Software Design.
