အကြောင်းပြချက်ခိုင်မာသော ဆုံးဖြတ်ချက်များ - Architectural Decision Records(ADRs)
ပြဿနာ - “ငါတို့ အဲဒီတုန်းက ဘာလို့များ ဒီလိုလုပ်ခဲ့ကြတာလဲ?”
Section titled “ပြဿနာ - “ငါတို့ အဲဒီတုန်းက ဘာလို့များ ဒီလိုလုပ်ခဲ့ကြတာလဲ?””Project တွေမှာ အမြဲကြုံရလေ့ရှိတဲ့ ပြဿနာကတော့၊ ဆုံးဖြတ်ချက်တစ်ခုချပြီး လပိုင်းလောက်ကြာသွားတဲ့အခါ အဲ့ဒီဆုံးဖြတ်ချက်ကို ဘာလို့ချခဲ့လဲဆိုတာ ဘယ်သူမှ မမှတ်မိကြတော့တာပါပဲ။ အသစ်ရောက်လာတဲ့ Developer တွေကလည်း အရင်လူတွေ ဘာလို့ ဒီလိုရေးခဲ့လဲ မသိတဲ့အတွက်၊ အမှားဟောင်းတွေကို ထပ်လုပ်မိတတ်ပါတယ်။
ဖြေရှင်းချက် - Architectural Decision Records (ADRs)
Section titled “ဖြေရှင်းချက် - Architectural Decision Records (ADRs)”ADR ဆိုတာ အရေးကြီးတဲ့ ဆုံးဖြတ်ချက် တစ်ခုတည်းကိုပဲ အကြောင်းပြချက်နဲ့တကွ တိုတိုရှင်းရှင်း ရေးမှတ်ထားတဲ့ မှတ်တမ်းလေး (Text File) တစ်ခု ဖြစ်ပါတယ်။ သူ့ရဲ့ ရည်ရွယ်ချက်က Project မှာ Code တွေ ပြောင်းလဲလာတာနဲ့အမျှ ကိုယ့်ရဲ့ ဆုံးဖြတ်ချက် မှတ်တမ်းတွေပါ အမြဲ Up-to-date ဖြစ်နေစေဖို့ပါ။
ADR တစ်ခု ဘယ်လိုရေးမလဲ?
Section titled “ADR တစ်ခု ဘယ်လိုရေးမလဲ?”ADR ဆိုတာ စာအုပ်ကြီးလို အရှည်ကြီး ရေးစရာ မလိုပါဘူး။ အဓိက ပါဝင်ရမယ့် အပိုင်း (၅) ပိုင်းပဲ ရှိပါတယ်။
- Title (ခေါင်းစဉ်): ဆုံးဖြတ်ချက်ကို ရှင်းပြတဲ့ စာတိုလေး (ဥပမာ - “User Data တွေအတွက် PostgreSQL ကို အသုံးပြုရန်”)။
- Status (အခြေအနေ): ဒီဆုံးဖြတ်ချက်က ဘာအဆင့်ရောက်နေပြီလဲ (ဥပမာ - Proposed (အကြံပြုထားဆဲ)၊ Accepted (လက်ခံအတည်ပြုပြီး)၊ Deprecated (မသုံးတော့ပါ))။
- Context (နောက်ခံအကြောင်းအရာ): အဲ့ဒီအချိန်တုန်းက ဘယ်လို အခက်အခဲ၊ ပြဿနာတွေ ရှိနေလို့လဲဆိုတာ ရှင်းပြပါ။
- Decision (ဆုံးဖြတ်ချက်): ဒါကြောင့် ဘာလုပ်ဖို့ ဆုံးဖြတ်လိုက်လဲဆိုတာကို တိတိကျကျ ရေးပါ။
- Consequences (အကျိုးဆက်များ): ဒီဆုံးဖြတ်ချက်ကြောင့် ဘာတွေဖြစ်လာမလဲ။ အားသာချက် (Pros)၊ အားနည်းချက် (Cons) နဲ့ ဘာတွေကို အလျှော့ပေးလိုက်ရလဲ (Trade-offs) ဆိုတာကို သေချာရေးပါ။ ဒါက ADR မှာ အရေးအကြီးဆုံး အပိုင်း ပါပဲ။
