Software Architect တစ်ဦး၏ အခန်းကဏ္ဍ

ရည်ရွယ်ချက်

Architect တစ်ယောက်ဖြစ်ရခြင်းဆိုတာ ကုဒ်တွေချည်းပဲ ရေးနေရတာမဟုတ်ဘဲ အစစအရာရာကို မျှတအောင် စီမံရတဲ့ အခန်းကဏ္ဍတစ်ခုဖြစ်ကြောင်း ခင်ဗျားတို့ နားလည်စေဖို့ပါ။

ရာထူးတစ်ခုထက် ပိုတဲ့ တာဝန်ယူမှု

Architect လို တွေးခေါ်လုပ်ဆောင်ဖို့ “Software Architect” ဆိုတဲ့ ရာထူးကြီး ရထားမှ မဟုတ်ပါဘူး။ ဘယ် Team မှာပဲဖြစ်ဖြစ်၊ ဆုံးဖြတ်ချက်တစ်ခုရဲ့ ရေရှည်အကျိုးဆက်ကို ထည့်တွက်တဲ့သူ၊ နည်းပညာပိုင်းဆိုင်ရာ ရည်မှန်းချက်တွေကို သူများနားလည်အောင် ရှင်းပြနိုင်သူ၊ ပြီးတော့ Team တစ်ခုလုံးကို လမ်းညွှန်ပေးနိုင်သူဟာ Architect တစ်ယောက်ရဲ့ တာဝန်ကို ယူထားတာပါပဲ။

Architect တစ်ယောက်ရဲ့ အဓိက မဏ္ဍိုင် (၄) ရပ်

အောင်မြင်တဲ့ Architect တစ်ယောက်ဟာ အောက်ပါ နယ်ပယ် ၄ ခုလုံးကို ဟန်ချက်ညီညီ စီမံနိုင်ရပါမယ်:

1. နည်းပညာ ကျွမ်းကျင်သူ (Technical Expert): ဒါက အခြေခံအကျဆုံးပါပဲ။ နည်းပညာတွေ၊ Pattern တွေရဲ့ အလုပ်လုပ်ပုံနဲ့ သူတို့ရဲ့ အားသာချက်/အားနည်းချက် (Trade-offs) တွေကို နက်နက်နဲနဲ နားလည်ထားရပါမယ်။
2. ဆက်သွယ်ပြောဆိုသူနှင့် ညှိနှိုင်းသူ (Communicator & Negotiator): နည်းပညာနဲ့ ပတ်သက်တဲ့ ရှုပ်ထွေးတဲ့ အကြံဉာဏ်တွေကို နည်းပညာမသိတဲ့ သူဌေးတွေကော၊ ကုဒ်ရေးမယ့် Developer တွေကိုပါ ရိုးရှင်းအောင် ရှင်းပြနိုင်ရပါမယ်။ လုပ်ငန်းရဲ့ လိုအပ်ချက်တွေကို သေချာနားထောင်ပြီး အကောင်းဆုံးဖြစ်မယ့် နည်းပညာနဲ့ ညှိနှိုင်းဖြေရှင်းပေးရပါမယ်။
3. ခေါင်းဆောင်နှင့် လမ်းညွှန်သူ (Leader & Mentor): ကိုယ်က ကုဒ်ရေးတဲ့ စံနှုန်းတွေကို သတ်မှတ်ပေးပြီး၊ Team က အဲ့ဒီအတိုင်း ပျော်ပျော်ရွှင်ရွှင် လိုက်လုပ်လာအောင် ခေါင်းဆောင်နိုင်ရပါမယ်။ တခြား Developer တွေရဲ့ အရည်အချင်းတွေ တိုးတက်လာအောင်လည်း သင်ပြလမ်းညွှန်ပေးရပါမယ်။
4. လုပ်ငန်းမဟာဗျူဟာ ကျွမ်းကျင်သူ (Business Strategist): ကုမ္ပဏီရဲ့ စီးပွားရေး ရည်မှန်းချက်တွေကို နားလည်ရပါမယ်။ ကိုယ်ရွေးချယ်လိုက်တဲ့ Architecture က ကုမ္ပဏီရဲ့ ရည်မှန်းချက်တွေ အောင်မြင်လာအောင် တိုက်ရိုက် အထောက်အကူပြုဖို့ အရေးကြီးပါတယ်။

Architect တစ်ယောက်လို ဘယ်လို တွေးခေါ်မလဲ? (How to think like an Architect)

• ကိုယ့်အလုပ်ထက် ပိုတွေးပါ: အလုပ်တစ်ခုပေးလိုက်ရင် “ဒါလေး ပြီးသွားရင် ရပြီ” လို့ မတွေးပါနဲ့။ ကိုယ်ရေးလိုက်တဲ့ ဖြေရှင်းချက်က System ကြီးရဲ့ တခြားအပိုင်းတွေကို ဘယ်လို ထိခိုက်မလဲ၊ Performance ကျသွားမလား၊ နောက်ပိုင်း ပြင်ရလွယ်ပါ့မလား ဆိုတာကိုပါ ကြိုတွေးပါ။
• Code တွေများများဖတ်ပါ: အရင်လူတွေ ဆုံးဖြတ်ခဲ့တဲ့ Architecture တွေရဲ့ အကျိုးဆက်ကို သိချင်ရင် အဲ့ဒီအချိန်က ရေးခဲ့တဲ့ Code တွေ ကို ပြန်ဖတ်ကြည့်တာ အကောင်းဆုံးပါပဲ။
• ပုံကြမ်းဆွဲတာ၊ မှတ်တမ်းတင်တာကို အကျင့်လုပ်ပါ: Feature အသေးလေးတွေ လုပ်ရင်တောင်မှ C4 ပုံကြမ်းလေး ဆွဲကြည့်တာ ဒါမှမဟုတ် ADR မှတ်တမ်းလေး တိုတိုရေးကြည့်တာ မျိုးတွေကို အမြဲ လေ့ကျင့်ပါ။
• ဆရာတစ်ယောက်ရှာပါ: Senior Engineer တွေ၊ တခြား Architect တွေနဲ့ စကားများများပြောပါ။ သူတို့ ဆုံးဖြတ်ချက်ချရင် “ဘာကြောင့် ဒီလိုဆုံးဖြတ်တာလဲ” ဆိုတာကို မေးမြန်းလေ့လာပါ။