Code Review ကောင်းမွန်စွာ လုပ်ဆောင်ခြင်း

နားလည်ထားရမယ့် အချက်

Pull request တစ်ခု ဖွင့်ပြီးသည်နှင့် တစ်ခြားတစ်ယောက်ယောက်က ၎င်းကို review လုပ်ပေးရန် လိုအပ်ပြီး review ကောင်းစွာ လုပ်ဆောင်ခြင်းက ၎င်းကိုယ်တိုင် skill တစ်ခုဖြစ်ပါတယ်။

• Comment — formal verdict မပါဘဲ feedback ချန်ခဲ့ခြင်း
• Request changes — ကိုင်တွယ်ရမည်အထိ merge ကို ပိတ်ဆို့ခြင်း
• Approve — merge လုပ်ရန် လမ်းဖွင့်ပေးခြင်း

Review ကောင်းတစ်ခုက code run ဖြစ်မဖြစ်ထက် ပိုပြီး ကြည့်ရပါတယ်။

• Correctness — description claim အတိုင်း လုပ်ဆောင်နေသလား၊ edge case များ ကိုင်တွယ်ထားသလား
• Readability — naming, structure, ဘာလို့လဲဆိုတာကို ရှင်းပြတဲ့ comment
• Security implications — user input, authentication, data handling ရှိ သေးငယ်တဲ့ ချန်လှပ်ထားမှုများ
• Test coverage — ပြောင်းလဲမှုအတွက် test ပါဝင်ခြင်း ရှိမရှိ
• Maintainability — author မဟုတ်တဲ့ နောက်လူတစ်ဦး နားလည်ပြီး လုံခြုံစွာ တိုးချဲ့နိုင်ခြင်း ရှိမရှိ

Etiquette ကတော့ ဒါတွေ အလုပ်ဖြစ်မဖြစ် ပုံဖော်ပေးပါတယ်။

PULL REQUEST REVIEW STATES
--------------------------
                    +-------------------+
                    |   Pull Request    |
                    +-------------------+
                   /         |          \
             comment   request changes   approve
            (no verdict) (blocks merge) (clears merge)
                   \         |          /
                    +-------------------+
                    | author updates,   |
                    | reviewer re-checks|
                    +-------------------+

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Reviewer တစ်ဦးလို စဉ်းစားဖို့ GitHub website မလိုအပ်ပါဘူး — ၎င်းက ပြသပေးတဲ့ comparison အတူတူကို local မှာ git command တစ်ခုနှင့်ပဲ ရရှိနိုင်ပါတယ်။

Push မလုပ်ခင် local မှာ ဖတ်ကြည့်ခြင်း၊ ကိုယ့်ရဲ့ကိုယ်ပိုင် work ပေါ်မှာ reviewer အနေနှင့် ပထမဆုံး ကစားကြည့်ခြင်းက တစ်ခြားလူ မမြင်ခင် ပြဿနာအများကြီးကို ဖမ်းမိစေပါတယ် — ကျန်ရစ်ခဲ့တဲ့ console.log တစ်ခု၊ မသက်ဆိုင်တဲ့ formatting ပြောင်းလဲမှုတစ်ခုစသည်တို့ပါ။

GitHub ကိုယ်တိုင်ပေါ်မှာတော့ reviewer တွေက ဖတ်ခြင်းအတူတူပဲ လုပ်ပေမယ့် comment တွေ built-in ပါဝင်ပါတယ် — line တစ်ကြောင်းကို click လိုက်ရင် အဲဒီ line နှင့် revision အတိအကျကို anchor လုပ်ထားတဲ့ thread တစ်ခု ပွင့်လာပါတယ်။

• Reviewer တစ်ဦးမှာ comment, request changes, approve ဆိုတဲ့ verdict သုံးမျိုး ရှိသည်
• Review ကောင်းသည် correctness, readability, security, test coverage, maintainability ကို စစ်ဆေးသည်
• git log A..B နှင့် git diff A...B ကို local မှာသုံးပြီး GitHub PR review ကို ကြိုတင် simulate လုပ်နိုင်သည်

အတူတူ စမ်းရေးကြည့်မယ်

git init -q -b main
git config user.name "Thuta Learner"
git config user.email "learner@example.com"

echo "function login() { return true; }" > login.js
git add login.js
GIT_AUTHOR_DATE="2026-01-01T09:00:00" GIT_COMMITTER_DATE="2026-01-01T09:00:00" \
  git commit -m "Add basic login function"

git checkout -b feature/add-validation
cat > login.js <<'EOF'
function login(username, password) {
  if (!username || !password) {
    return false;
  }
  return true;
}
EOF
git add login.js
GIT_AUTHOR_DATE="2026-01-01T10:00:00" GIT_COMMITTER_DATE="2026-01-01T10:00:00" \
  git commit -m "Add input validation to login"

git log main..feature/add-validation --oneline
git diff main...feature/add-validation

git log main..feature/add-validation --oneline ->
edd0062 Add input validation to login

git diff main...feature/add-validation ->
diff --git a/login.js b/login.js
index 5f8135f..7ab42fa 100644
--- a/login.js
+++ b/login.js
@@ -1 +1,6 @@
-function login() { return true; }
+function login(username, password) {
+  if (!username || !password) {
+    return false;
+  }
+  return true;
+}

GitHub Docs: About pull request reviews — Git & GitHub