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

ရည်ရွယ်ချက်

Architect တစ်ယောက်ဖြစ်ရခြင်းဆိုသည်မှာ နည်းပညာကျွမ်းကျင်မှုထက် ပိုမိုကျယ်ပြန့်သော ဘက်စုံအခန်းကဏ္ဍတစ်ခုဖြစ်ကြောင်း နားလည်ရန်နှင့် Architectural စဉ်းစားပုံစဉ်းစားနည်းကို မည်သို့ပျိုးထောင်ရမည်ကို လေ့လာရန် ဖြစ်ပါတယ်။

ရာထူးတစ်ခုသက်သက်မဟုတ်ဘဲ၊ တာဝန်ယူရတဲ့ အခန်းကဏ္ဍတစ်ခုပါ

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

Architect တစ်ယောက်၏ အဓိကမဏ္ဍိုင်ကြီးလေးခု

အောင်မြင်တဲ့ Architect တစ်ယောက်ဟာ အဓိကနယ်ပယ်လေးခုကို ချိန်ခွင်လျှာညှိပြီး လုပ်ဆောင်ရပါတယ်-

1. Technical Expert (နည်းပညာကျွမ်းကျင်သူ) - ဒါက အခြေခံအုတ်မြစ်ပါပဲ။ သင်ဟာ နည်းပညာတွေ၊ Pattern တွေ၊ နိယာမတွေ၊ နဲ့ သူတို့ရဲ့ အပေးအယူမျှတမှု (Trade-offs) တွေကို နက်နက်နဲနဲ နားလည်ထားရပါမယ်။ (ဒီသင်တန်းက ဒီအချက်ကို အဓိကထားခဲ့ပါတယ်)။

2. Communicator & Negotiator (ဆက်သွယ်ပြောဆိုသူနှင့် ညှိနှိုင်းသူ) - သင်ဟာ ရှုပ်ထွေးတဲ့ နည်းပညာအကြံဉာဏ်တွေကို Technical သမားရော၊ Non-technical ပရိသတ်ကိုပါ ရိုးရှင်းအောင် ရှင်းပြနိုင်ရပါမယ်။ လုပ်ငန်းရဲ့လိုအပ်ချက်တွေကို နားထောင်ပြီး၊ နည်းပညာအရခိုင်မာပြီး အဲဒီလိုအပ်ချက်တွေကို ဖြည့်ဆည်းပေးနိုင်တဲ့ ဖြေရှင်းချက်တွေကို ညှိနှိုင်းပေးရပါမယ်။

3. Leader & Mentor (ခေါင်းဆောင်နှင့် လမ်းညွှန်သူ) - သင်က နည်းပညာပိုင်းဆိုင်ရာများကို သတ်မှတ်ပေးပြီး၊ Team ကို အဲဒီအတိုင်းလိုက်လုပ်ဖို့ အားတက်သရောဖြစ်အောင် ဆောင်ရွက်ပေးရပါမယ်။ Team ထဲက တခြား Developer တွေကို သူတို့ရဲ့ ကျွမ်းကျင်မှုတွေတိုးတက်လာအောင်နဲ့ Career မှာ ကြီးထွားလာအောင် ကူညီပေးရပါမယ်။

4. Business Strategist (လုပ်ငန်းမဟာဗျူဟာကျွမ်းကျင်သူ) - သင်က ကုမ္ပဏီရဲ့ ရည်မှန်းချက်တွေကို နားလည်ထားရပါမယ်။ သင့်အလုပ်က သင်ရွေးချယ်လိုက်တဲ့ နည်းပညာနဲ့ Architecture တွေက အဲဒီလုပ်ငန်းရည်မှန်းချက်တွေကို တိုက်ရိုက်အထောက်အကူပြုပြီး ဖြစ်မြောက်အောင်လုပ်ပေးဖို့ သေချာစေရမှာပါ။

Architectural စဉ်းစားပုံစဉ်းစားနည်းကို ဘယ်လိုပျိုးထောင်မလဲ

• ကိုယ့်အလုပ်ထက် ပိုပြီးစဉ်းစားပါ - သင့်ကို အလုပ်တစ်ခုပေးအပ်တဲ့အခါ၊ အဲဒါကို ဘယ်လိုပြီးအောင်လုပ်မလဲဆိုတာတစ်ခုတည်းကိုပဲ မစဉ်းစားပါနဲ့။ သင့်ရဲ့ ဖြေရှင်းချက်က System ရဲ့ တခြားအစိတ်အပိုင်းတွေ၊ သူ့ရဲ့ Performance၊ နဲ့ ပြင်ဆင်ထိန်းသိမ်းရလွယ်ကူမှုအပေါ် ဘယ်လိုသက်ရောက်မှုရှိမလဲဆိုတာကိုပါ စဉ်းစားပါ။

• Code တွေကို ဖတ်ပါ (အထူးသဖြင့် Code အဟောင်းတွေ) - အတိတ်က Architectural ဆုံးဖြတ်ချက်တွေရဲ့ အကျိုးဆက်တွေကို လေ့လာဖို့ အကောင်းဆုံးနည်းလမ်းကတော့ အဲဒီဆုံးဖြတ်ချက်တွေကနေ ဖြစ်ပေါ်လာတဲ့ Code တွေကို ဖတ်တာပါပဲ။

• ပုံကြမ်းဆွဲတာနဲ့ မှတ်တမ်းတင်တာကို လေ့ကျင့်ပါ - သေးငယ်တဲ့ Feature တွေအတွက်တောင်၊ ရိုးရှင်းတဲ့ C4 ပုံကြမ်းတစ်ခုဆွဲတာ ဒါမှမဟုတ် သင်ချမှတ်ခဲ့တဲ့ ဆုံးဖြတ်ချက်တစ်ခုအတွက် ADR အတိုလေးတစ်ခုရေးတာကို လေ့ကျင့်ပါ။

• Mentor တစ်ယောက်ရှာပါ - Senior Engineer တွေ၊ Architect တွေနဲ့ စကားပြောပါ။ သူတို့ရဲ့ ဆုံးဖြတ်ချက်တွေနောက်ကွယ်က “ဘာကြောင့်” ဆိုတာကို ရှင်းပြခိုင်းပါ။