AI ရေးထားတဲ့ code ကို ဘယ်လို review လုပ်မလဲ

AI ရေးထားတဲ့ code ကို review လုပ်ဖို့ ဦးစွာ ဘာပြောင်းလဲသွားလဲ — ဘယ်ဖိုင်တွေ၊ ဘာကြောင့်လဲ — ကို စတင်ပါ၊ ပြီးရင် code ဖတ်ခင် အပြုအမူကို ကိုယ်တိုင် စမ်းပါ။ ပြီးမှ AI code က မှားတတ်တဲ့ နေရာတွေကို စစ်ပါ: server ဘက်က permission စစ်ဆေးမှု မရှိခြင်း၊ browser ကို ထုတ်ပေးထားတဲ့ secret များ၊ မစစ်ထားတဲ့ input၊ မရှိတဲ့ package သို့မဟုတ် function များ၊ မတောင်းဆိုထားတဲ့ အရာတွေကို ပြင်ထားခြင်း။

AI က ပုံမှန်အားဖြင့် ရေးထားတဲ့ code က run တတ်ပြီး သပ်ရပ်ပုံရတတ်ပါတယ်။ ဒါကြောင့် သေချာမစစ်ဘဲ အတည်ပြုလိုက်ရတာ လွယ်ပါတယ်။ ဒီလမ်းညွှန်က code ကို ကျွမ်းကျင်စွာ ဖတ်တတ်တာဖြစ်စေ၊ လုံးဝ မဖတ်တတ်တာဖြစ်စေ အလုပ်ဖြစ်တဲ့ review လုပ်ငန်းစဉ် တစ်ခု ဖြစ်ပါတယ်။

အန္တရာယ်နဲ့ အညီ review ကို ချိန်ညှိပါ

ပြောင်းလဲမှု အားလုံးက အာရုံစိုက်မှု တူတူ မလိုပါဘူး။

အဆင့် 1: ဘာပြောင်းလဲသွားလဲ ကြည့်ပါ

Code ကို မဆုံးဖြတ်ခင် ပြောင်းလဲမှု စာရင်းကို ယူပါ:

• Project က Git မှာ ရှိရင် နောက်ဆုံး commit ကနေ ပြောင်းထားတဲ့ ဖိုင်နဲ့ လိုင်းတွေကို diff အဖြစ် ကြည့်ပါ။ how to use Git with an AI-built app ကို ကြည့်ပါ။
• ဒါမှမဟုတ် AI ကို တိုက်ရိုက် မေးပါ:

နောက်ဆုံး ပြောင်းလဲမှုမှာ ပြင်ခဲ့တဲ့ ဖိုင်အားလုံးကို စာရင်းပြုစုပါ၊ ဖိုင်တစ်ခုချင်းစီအတွက် ဘာပြောင်းလဲလဲ၊ ဘာကြောင့်လဲ ဝါကျတစ်ကြောင်းစီနဲ့ ရှင်းပြပါ။

ဒီအဆင့်မှာ သတိထားရမဲ့ နိမိတ်တွေ: တောင်းဆိုချက်နဲ့ မဆိုင်တဲ့ ဖိုင်တွေ၊ ဖျက်ထားတဲ့ ဖိုင်တွေ၊ သင်မတောင်းဆိုထားတဲ့ configuration သို့မဟုတ် dependency ပြောင်းလဲမှုတွေ။

အဆင့် 2: အပြုအမူကို ဦးစွာ စမ်းပါ

Code ဖတ်ခြင်းက ဘာလုပ်ဖို့ ရည်ရွယ်သလဲ ပြောပြပေမဲ့ စမ်းခြင်းက ဘာတကယ် လုပ်သလဲ ပြောပြပါတယ်။ မဖတ်ခင်:

• Normal user အနေနဲ့ ပြောင်းလဲမှုကို desktop နဲ့ ဖုန်းအရွယ် screen မှာ စမ်းပါ။
• မှားတဲ့ input နဲ့ စမ်းပါ: အလွတ် field၊ စာသား ရှည်ရှည်၊ အနှုတ်ဂဏန်း၊ အတိတ်ရက်စွဲ။
• Logout လုပ်ပြီး၊ နောက် user တစ်ယောက်အဖြစ် စမ်းပါ။
• အရေးအကြီးဆုံး flow တွေကို ပြန်စမ်းပါ: sign up၊ login၊ အဓိက လုပ်ဆောင်ချက်၊ ငွေပေးချေမှု။

စမ်းသပ်မှု ပျက်ရင် ဖတ်ချိန် ကြိုတင်ကယ်တင်ပြီးပါပြီ — ရှင်းရှင်း အစီရင်ခံပြီး AI ကို ပြင်ခိုင်းပါ။ how to write a good bug report ကို ကြည့်ပါ။

အဆင့် 3: Server ပေါ်မှာ permission ကို စစ်ပါ

အရေးကြီးဆုံး စစ်ရမဲ့ အရာ။ AI tool တွေက မကြာခဏ page ပေါ်မှာ ခလုတ်ကို ဝှက်ထားပေမဲ့ server က မည်သူ တောင်းတိုင်း လုပ်ပေးနေတတ်ပါတယ်။

Data ဖတ်ဖို့ သို့မဟုတ် ပြင်ဖို့ route သို့မဟုတ် function တိုင်းအတွက် မေးပါ:

• User က login ဝင်ထားကြောင်း စစ်ထားလား?
• ဒီ user က ဒီ record ကို ဝင်ခွင့်ရှိကြောင်း စစ်ထားလား?
• အဲဒီစစ်ဆေးမှုက server ပေါ်မှာ ရှိလား၊ page ထဲမှာသာ မဟုတ်လား?

ထည့်ထားပြီး ပြောင်းထားတဲ့ API route တိုင်းအတွက် server ပေါ်မှာ ဘယ် permission စစ်ဆေးမှု လုပ်သလဲ၊ မျဉ်းကို ကိုးကားပြပါ။ စစ်ဆေးမှုမရှိတဲ့ route ကို အမှတ်အသားပြပါ။

ပြီးရင် စမ်းပါ: user A အနေနဲ့ login ဝင်ပြီး record ID တစ်ခုကို မှတ်ပါ၊ user B အနေနဲ့ login ဝင်ပြီး အဲဒီ ID ကို တောင်းကြည့်ပါ။ security checklist for AI-built apps မှာ စမ်းသပ်မှု အပြည့်အစုံ ရှိပါတယ်။

အဆင့် 4: ပေါက်ကြားနေတဲ့ secret တွေကို ရှာပါ

• ပြောင်းထားတဲ့ ဖိုင်တွေမှာ key သို့မဟုတ် password ပုံစံနဲ့ တူတာတွေကို ရှာပါ။
• Secret key တွေကို environment variable ကနေ ဖတ်ပြီး server code မှာသာ သုံးထားကြောင်း စစ်ပါ။
• Secret variable တွေ ရှေ့မှာ VITE_ ဒါမှမဟုတ် NEXT_PUBLIC_ လို public prefix တွေ ရှိမရှိ ကြည့်ပါ — ဒါတွေက browser code ထဲ တည်ဆောက်ပြီးသားဖြစ်ပါတယ်။

how to keep API keys safe ကိုလည်း ကြည့်ပါ။

အဆင့် 5: Input နဲ့ error တွေကို စစ်ပါ

• Server ပေါ်မှာ validation။ Browser စစ်ဆေးမှုကို ကျော်နိုင်ပါတယ်။ လိုအပ်တဲ့ field၊ အရှည်၊ format နဲ့ ခွင့်ပြုတဲ့ တန်ဖိုးတွေကို server ကလည်း စစ်ရပါမယ်။
• Database query တွေက parameter သုံးရမယ်၊ user input ကို query ထဲ စာသားအဖြစ် ပေါင်းထည့်တာ မဟုတ်ရပါ။
• Error တွေကို မလျစ်လျူရှုပါနဲ့။ ဘာမှမလုပ်တဲ့ try/catch က ပျက်ကွက်မှုတွေကို ဖုံးထားပါတယ်။ Error တွေကို log လုပ်ရမယ်၊ user တွေကို ရှင်းရှင်း စာသား ပြရမယ်။
• User တွေကို အသေးစိတ် အတွင်းပိုင်း အချက်အလက် မပြပါနဲ့ — stack trace နဲ့ database error တွေကို log ထဲမှာသာ ထားပါ။

အဆင့် 6: တကယ်ရှိမရှိ စစ်ပါ

AI model တွေက အလုပ်လုပ်ပုံရပေမဲ့ မရှိတဲ့ အရာတွေကို ရည်ညွှန်းတဲ့ code ကို တစ်ခါတစ်လေ ထုတ်ပေးတတ်ပါတယ်။

• Package များ: Dependency အသစ်တိုင်း အမှန်တကယ် ရှိပြီး ထိန်းသိမ်းနေတဲ့ package ဖြစ်ရမယ်၊ နာမည်ကို အတိအကျ ရေးထားရမယ်။ လူသိများတဲ့ package တွေရဲ့ စာလုံးပေါင်းမှား ပုံစံနဲ့ ဆင်တူတဲ့ နာမည်တွေကို သတိထားပါ။
• Function နဲ့ API option များ: Library function ဒါမှမဟုတ် ပြင်ပ API option ကို မမြင်ဖူးတဲ့ code ခေါ်ထားရင် တရားဝင် documentation မှာ စစ်ပါ။
• Placeholder code: TODO၊ mock၊ fake၊ hard-coded နမူနာ data၊ သို့မဟုတ် တန်ဖိုးတစ်ခုတည်း ပြန်ပေးတဲ့ function တွေကို ရှာပါ။

ပက်ကေ့ဂျ် အသစ် ထည့်ထားလား? တစ်ခုချင်းစီအတွက် အတိအကျ နာမည်၊ ဘာအတွက်လဲ၊ ဒါမရှိဘဲ လုပ်လို့ရလားဆိုတာ ပြပါ။

အဆင့် 7: ကိုက်ညီလားစစ်ပါ

Code က အလုပ်လုပ်ပေမဲ့ app ကို နောက်ပိုင်း ပြောင်းရခက်အောင် လုပ်နိုင်ပါတယ်:

• ထပ်နေခြင်း။ Logic တူတူကို နေရာများစွာမှာ ကူးထားရင် ခွဲထွက်သွားပါလိမ့်မယ်။
• တသမတ်တည်းဖြစ်မှု။ App ရဲ့ တခြားနေရာတွေက သုံးတဲ့ pattern တွေကို လိုက်နာရမယ်။
• အရွယ်အစား။ လိုင်း 20 တောင်းဆိုချက်က လိုင်း 600 ထုတ်ပေးတာ မေးခွန်းထုတ်ထိုက်ပါတယ်။
• အသုံးမပြုတဲ့ code။ အသစ်တွေ ဘေးမှာ ကျန်ခဲ့တဲ့ အဟောင်း version တွေ။

ဒီပြောင်းလဲမှုကြောင့် project ထဲမှာ အခု အသုံးမပြုတော့တဲ့ code ရှိလား၊ ဒါမှမဘဲ တခြားနေရာမှာ ထပ်နေတဲ့ logic ရှိလား? ဘာမှ မပြောင်းပါနဲ့၊ စာရင်းပဲ ပြပါ။

အများဆုံး ဖြစ်တတ်တဲ့ အမှားများ

• သပ်ရပ်နေလို့ အတည်ပြုခြင်း။ သပ်ရပ်တဲ့ code ကလည်း permission စစ်ဆေးမှုကို ကျော်နိုင်ပါတယ်။
• စမ်းခြင်းအစား ဖတ်ခြင်း။ ဦးစွာ စမ်းပါ၊ ပြီးမှ ဖတ်ပါ။
• Happy path ကိုသာ စမ်းခြင်း။ မှားတဲ့ input၊ မှားတဲ့ user၊ logout အခြေအနေကိုပါ စမ်းပါ။
• ဆက်စပ်မှုမရှိတဲ့ ဖိုင်ပြောင်းလဲမှုကို လျစ်လျူရှုခြင်း။ ဘာကြောင့် ဖိုင်အားလုံး ပြောင်းသွားလဲ မေးပါ။
• Self-review ကို အပြည့်အဝ ယုံခြင်း။ AI ရဲ့ review ကို ပထမအဆင့်အဖြစ်သာ သုံးပြီး စမ်းသပ်ခြင်းဖြင့် အတည်ပြုပါ။
• တစ်ပတ်စာ ပြောင်းလဲမှုတွေကို တစ်ခါတည်း review လုပ်ခြင်း။ ပြောင်းလဲမှု ငယ်ငယ်လေးတွေကို ဖြစ်တိုင်း review လုပ်ပါ။

စစ်ဆေးစာရင်း

• ဘယ်ဖိုင်တွေ ပြောင်းသွားလဲ၊ ဘာကြောင့်လဲ သိပြီး ဆက်စပ်မှုမရှိတာ ဘာမှ မပြောင်းထားပါ။
• ပြောင်းလဲမှုက desktop နဲ့ ဖုန်းမှာ အလုပ်လုပ်တယ်၊ မှားတဲ့ input၊ logout အခြေအနေနဲ့ နောက် user အနေနဲ့ စမ်းပြီးပါပြီ။
• Data route တိုင်းက server ပေါ်မှာ login နဲ့ ပိုင်ဆိုင်မှု စစ်ထားတယ်။
• Code ထဲ သို့မဟုတ် browser bundle ထဲ secret မရှိပါ။
• Input ကို server ပေါ်မှာ စစ်ထားတယ်၊ query တွေက parameter သုံးထားတယ်။
• Error တွေကို log လုပ်ထားတယ်၊ လျစ်လျူမရှုထားဘူး၊ user တွေကို အသေးစိတ် မပြထားဘူး။
• Package အသစ်တွေက တကယ်ရှိပြီး လိုအပ်တယ်၊ တီထွင်ထားတဲ့ function သို့မဟုတ် placeholder မကျန်တော့ပါ။
• အန္တရာယ်မြင့်တဲ့ ပြောင်းလဲမှုတွေကို သေချာဖတ်ပြီး လိုအပ်ရင် ဒုတိယ reviewer ရှိပါတယ်။

Mythex မှာ code review လုပ်ခြင်း

• Ask mode က code ကို မပြင်ဘဲ မေးခွန်းတွေ ဖြေပေးပါတယ် — "ပြောင်းထားတာ အားလုံး ရှင်းပြ" နဲ့ "ဘယ် route တွေမှာ permission စစ်ဆေးမှု မရှိလဲ" လို prompt တွေအတွက် အထူးကောင်းပါတယ်။ Chat ကို ကြည့်ပါ။
• Code view က plan တိုင်းမှာ ဖိုင် tree၊ editor နဲ့ terminal ကို ပြပါတယ် (Free မှာ read-only၊ Pro မှာ ပြင်လို့ရ)၊ ဒါကြောင့် ပြောင်းထားတာကို သင်ကိုယ်တိုင် ဖတ်နိုင်ပါတယ်။ Code editor ကို ကြည့်ပါ။
• /test က agent ကို preview ထဲ user တစ်ယောက်အနေနဲ့ နှိပ်စမ်းခိုင်းပြီး ပျက်နေတဲ့ flow တွေကို အစီရင်ခံစေပါတယ်။
• Checkpoint တွေက review မအောင်တဲ့ ပြောင်းလဲမှုကို ပြန်ပြန်နိုင်စေပါတယ်။

Developer တစ်ယောက်က သင့်အတွက် review လုပ်ပေးနေရင် how to work with a developer on an AI-built app က handoff ကို ရှင်းပြပါတယ်။ Review မှာ bug တွေ့ရင် how to debug an AI-built app ကို ကြည့်ပါ။

မေးခွန်းများ