အတိုဆုံးပြောရရင်တော့ ကိုယ့် အတွက် ကိုယ် ရေးသင့်တယ် ပဲ ပြောရမယ်။
ပြီးခဲ့သည့် post မှာ Business Value အကြောင်းကို ပြောထားပါတယ်။ ဒါကြောင့် code quality က အရေးမကြီး ဘူး မဟုတ်ဘူး။ product တစ်ခု အောင်မြင်ခြင်း မအောင်မြင်ခြင်းက business value ပေါ်မှာ မူတည်တယ်။ Code quality မကောင်းလို့ နောက်တစ်ချိန် အောင်မြင်သည့် အချိန်မှာ ပြန်ပြင်မယ် ဆိုရင် ကိုယ်ပဲ ဒုက္ခရောက်မှာ။ အလုပ်ထုတ်ခံထိမလား ကိုယ်ပဲ အများကြီး ပြန်ပြင်ရမလား ဖြစ်မှာ။
တချို့ product တွေက Launch Fast! Fail Fast! တွေ။ Business Model ကို test လုပ်ကြည့်သည့် product တွေ ရှိတယ်။ အဲဒီလို product တွေ မှာ အချိန်တွေ အများကြီး ပေးပြီး ရေးဖို့ အချိန် မရှိဘူး။ Unit Test တွေ ထည့်သင့်တာ မှန် ပေမယ့် launch fast လုပ်ချင်တာ။ fail မလား success ဖြစ်မလား သိချင်တာ။ အဲဒီလို အခါတွေမှာ code quality ထက် အမြန် launch လုပ်ဖို့ လိုတယ်။
Facebook ကို စသည့် အချိန်က Unit Test ခေတ်မစား သေးသလို မြန်မြန် launch လုပ်လို့ရသည့် PHP နဲ့ ပဲ စခဲ့တာပဲ။ ASP.NET , JSP တွေ ရှိပေမယ့် သူတို့ က စနစ်ကျတယ် ဆိုရမယ်။ အကုန်လုံးကို စနစ်တကျ နဲ့ အချိန် အကြာကြီး ယူပြီး ဖန်တီးရတယ်။ ဒါမှနောက်ပိုင်း maintainece တွေ အဆင်ပြေမှာ။ ဒါပေမယ့် Facebook ကို မြန်မြန် နဲ့ develop လုပ်ပြီး functionality တွေပဲ ဂရုစိုက်ခဲ့တာ။
Quality ကောင်းသည့် Code က အချိန်ပေးရတယ်။ Layer တွေကို ခွဲရေးခြင်းကို အကျင့်လုပ်ရတယ်။ အကျင့် မရှိသေးရင် ပို အချိန် ကြာတယ်။ ပိုမှန် နေ့ တဝက်ကို ၁ ရက် သို့မဟုတ် ၂ ရက် လောက် ကြာသွားတတ်တယ်။ TDD ဆိုရင် ၂ ရက်လောက် ကြာသွားကော။
အစပိုင်းမှာ ကြာပေမယ့် နောက်ပိုင်းမှာ မြန် လာတယ်။ Maintain လုပ်ရတာ အများကြီး မြန်တယ်။ feature ထည့်ရတာ အများကြီး မြန်တယ်။ ဥပမာ မြန်မြန် ဆန်ဆန် ရေးထားသည့် code က feature ထည့် ဖို့ ၂ ရက်လောက် အချိန် ပေးရပေမယ့် quality ကောင်းသည့် code က ၁ ရက်လောက် နဲ့ ပြီးတယ်။ အကုန်လုံးက loose coupling ဖြစ်ပြီး dependency တွေ ကို လျော့ ချ ထား နိုင်တာကြောင့်။ အစောကတည်းက အဲလို မလုပ်ထားရင် တစ်ခု ပြင်ရင် နောက်တစ်ခု မှာ ပြဿနာ တက်ပြန်ကော။ feature တစ်ခု ပြင်ပြီးသွားရင် regression test ကို အများကြီး အချိန်ပေးရတယ်။ Error တက်လိုက် ပြန်ပြင်လိုက် နဲ့ အချိန်တွေ အရမ်းကြာတယ်။
Bad Coding က တကယ်တန်းတော့ technical debt ပဲ။ Programmer တွေက သိရဲ့ သား နဲ့ အချိန် မလောက်လို့ နောက်မှ ပြင်မယ် လုပ်ခဲ့တာတွေ အများကြီးပဲ။ အဲဒီတော့ maintain ခက်တယ်။
ဘာနဲ့ တူသလဲဆိုတော့ အိမ်ဆောက်သည့် အခါမှာ foundation တွေ သေချာ တူးပြီး ဆောက်သည့် အခါမှာ အရမ်းကြာတယ်။ foundation ကို ဖြစ်သလောက်လေး တူးပြီး ဖြစ်သလို ဆောက်တာ ကတော့ မြန်တာပေါ့။ အရေးကြီးတာက business ဘက်က decision ပဲ။ prototype level လောက် လိုချင်တာလား။ ရေရှည်အတွက် လုပ်ချင်တာလား ဆိုတာပဲ။ ဥပမာ ပွဲ အတွက် အိမ် ပုံ စံ တွေ ပြဖို့ အစအဆုံး foundation တူးပြီး ဆောက်မယ် ဆိုရင် အချိန် မှီ မှာ မဟုတ်သလို ပွဲအချိန် ရောက်သည့် အခါမှာလည်း မပြီးသေးသည့် အိမ်ပုံစံ ပဲ မြင်ရပြီး ရောင်းထွက်မှာ မဟုတ်ဘူး။ ဒါကြောင့် business ဘက်က လိုချင်သည့် level ပေါ်မူတည်ပြီး prototype level ပဲ ဆောက်သင့်ရင် ဆောက်ရမှာပဲ။
Developer အနေနဲ့ တော့ ဘယ် code မဆို quality ကောင်းကောင်း နဲ့ ရေးချင်ကြတာပဲ။ အတတ်နိုင်ဆုံး တတ်သလောက် တော့ ရေးကြတာပဲ။ ရေးသည့် အထဲမှာ timeline, senior developer knowledge , code review , company ရဲ့ developer best practices guide line တွေက အရမ်းကို အရေးပါတယ်။
code ကောင်းကောင်းရေးထားသည့် အကျင့် က အလုပ်အသစ်တွက် interview တွေ မှာ အများကြီး အထောက်အကူပြုတယ်။ ကိုယ့်ရဲ့ quality ကို ကိုယ် တိုး တက်အောင် ဖန်တီး မှ ပိုကောင်းသည့် နေရာကို ကို ရမှာ။ Interview တော်တော်များများမှာ SOLID , Loose Coupling , Layer တွေ ခွဲ ရေးတာ မေးတတ်တာပဲ။ ပုံမှန် ရေးနေကျ ဖြစ်မှ လွယ်လွယ် ကူ ကူ ဖြေနိုင်မှာ။
ဒါကြောင့် ဖြစ်နိုင်ရင် Best Practices တွေကို လိုက်နာပါ။ Business team နဲ့ လည်း အမြဲတန်း align လုပ်ပါ။ ပုံမှန် အားဖြင့် developer တွေက business ဘက်က လူတွေ tech နဲ့ ပတ်သက်ပြီး ဘာမှ မသိဘူး သတ်မှတ်ပြီး align လုပ်ဖို့ မကြိုးစားကြဘူး။ Team တစ်ခု အနေနဲ့ business requirement , big picture ကို မြင်ဖို့ လိုတယ်။ ပြီးမှ timeline နဲ့ ဖြစ်နိုင်သည့် quality ကို align လုပ်ဖို့ လိုတယ်။ business team ကိုလည်း sacrifice လုပ်ရမယ့် code quality ကိုလည်း နားလည်အောင် ရှင်းပြဖို့ လိုတယ်။
နောက်ပိုင်းတော့ code တွေ မှာ ဖြစ်ဖြစ် git commit မှာ ဖြစ်ဖြစ် comment ရေးထားတယ်။ ဘာကြောင့် ဒီလို ဆိုးရွား သည့် code ဖြစ်နေရသည့် အကြောင်းကို။ ဒါမှ နောက် လူတွေ က ကိုယ့် code ကို ကြည့် ပြီး မဆဲအောင်ပေါ့။