การรีวิวโค้ดน่าจะทำได้ดีกว่านี้

• นักพัฒนาจำนวนมากรู้สึกไม่พอใจกับประสบการณ์การรีวิวโค้ดของ GitHub และกำลังมีความพยายามรูปแบบใหม่เพื่อปรับปรุงสิ่งนี้
• เครื่องมือทดลองชื่อ git-review ถูกออกแบบมาให้จัดการการรีวิวโค้ดร่วมกับโค้ดโดยตรงบนเครื่องโลคัล แทนที่จะทำผ่านเว็บอินเทอร์เฟซบนเบราว์เซอร์
• การรีวิวถูกจัดการเป็นคอมมิตเดียว โดยทิ้งคอมเมนต์รีวิวไว้ในโค้ดเหมือนคอมเมนต์ และให้ผู้รีวิวกับผู้เขียนช่วยกันแก้ไขคอมมิตนี้ไปเรื่อย ๆ
• อย่างไรก็ตาม หากมีการแก้โค้ดหรือ rebase ระหว่างการรีวิว จะเกิดความไม่สะดวกในเรื่องการจัดการ conflictและการใช้ --force-with-lease ทำให้แนวทางนี้ไม่ประสบความสำเร็จมากนัก
• สุดท้ายจึงกลับไปใช้การรีวิวผ่านเว็บอีกครั้ง แต่แนวคิดเรื่องการใส่สถานะรีวิวไว้ใน Git repository โดยตรงยังคงน่าสนใจ และมีความเป็นไปได้ว่าจะเกิดทางเลือกที่ดีกว่าเดิมเมื่อ Git พัฒนาต่อไป เช่น การนำChange-Id แบบ Gerritมาใช้

---

การมองเห็นปัญหาของระบบรีวิวโค้ด

• ปัจจุบันมีคนจำนวนมากไม่พอใจกับกระบวนการรีวิวโค้ดของ GitHub
• ปัญหาหลักคือการรองรับstacked pull requestและinterdiff reviewที่ยังไม่ดีพอ รวมถึง
  • สถานะการรีวิวไม่ได้ถูกเก็บไว้ภายใน repository
  • จำเป็นต้องรีวิวผ่านเว็บอินเทอร์เฟซที่ยึด remote เป็นศูนย์กลาง
• ปัญหาที่ผู้เขียนมองเห็นคือการขาดความกระจายศูนย์ของการรีวิวและความไม่มีประสิทธิภาพของอินเทอร์เฟซ

เปรียบเทียบเวิร์กโฟลว์การเขียนโค้ดและการรีวิว

• เวลาคนเขียนโค้ด พวกเขาใช้งานเอดิเตอร์บนเครื่องโลคัล
  • หน่วงต่ำทั้งในด้านหน่วยความจำและ NVMe และเป็นสภาพแวดล้อมที่ปรับให้เหมาะกับเวิร์กโฟลว์เฉพาะของผู้ใช้
• การรีวิวโค้ดก็ควรทำโดยดึง source branch ลงมาไว้บนเครื่องโลคัลแล้วทำงานกับมัน
  • ด้วยเครื่องมืออย่างMagit เราไม่เพียงดู diff ได้ แต่ยังสำรวจบริบทของโค้ดทั้งหมดได้ด้วย
  • สามารถใช้สภาพแวดล้อมการพัฒนาที่ทรงพลังได้ เช่น รันเทสต์ ไปยังตำแหน่งนิยามของโค้ด หรือทดลอง refactor
• ในทางกลับกัน หากต้องการทิ้งฟีดแบ็กไว้ใน PR ก็ต้องย้ายไปใช้เว็บอินเทอร์เฟซบนเบราว์เซอร์ที่ช้า และเมื่อ diff มีขนาดใหญ่ก็มีอาการหน่วงเวลาพิมพ์อย่างชัดเจน

อินเทอร์เฟซรีวิวโค้ดและโครงสร้างการจัดเก็บที่เหมาะสม

• ในความเป็นจริง การทิ้งคอมเมนต์แบบ inline ในโค้ดหรือแก้โค้ดโดยตรงคือวิธีที่เป็นธรรมชาติที่สุด

  // CR(matklad): Hm, this check seems imprecise to me.  
  // Shouldn't we compare `replica.view` instead of `header.view` here?  
  if (header.view != view) return;  
  

• เมื่อข้อมูลถูกเก็บไว้ในฐานข้อมูลระยะไกลแทนที่จะเป็น local git repository ก็จะเกิดทั้งปัญหาความหน่วงและvendor lock-in

แนวคิดของ git-review และประสบการณ์ใช้งานจริง

• แนวคิดของ git-review มีดังนี้:
  • การรีวิวโค้ดเกิดขึ้นในรูปของคอมมิตเดียวที่อยู่บนสุดของ PR branch
  • ภายในคอมมิตนั้นจะมีการเพิ่มคอมเมนต์ในโค้ดที่มีมาร์กเกอร์พิเศษ
  • ผู้รีวิวและผู้เขียนจะผลัดกันแก้ไขคอมมิตนี้ โดยทำงานร่วมกันบนพื้นฐานของ push --force-with-lease
  • เมื่อคอมเมนต์ทั้งหมดถูกทำเครื่องหมายว่าแก้ไขแล้ว (//? resolved) และรีวิวจบลง ก็จะเพิ่มrevert commitเพื่อเก็บบันทึกไว้
• แม้แนวคิดจะเรียบง่ายและใช้งานได้จริง แต่ในทางปฏิบัติก็เกิดปัญหาต่อไปนี้
  • หากมีการแก้โค้ดระหว่างรีวิว ก็มักเกิด conflict ระหว่างคอมเมนต์กับคอมมิตด้านล่างหรือคอมมิตใหม่
  • กระบวนการforce-pushเพิ่มแรงเสียดทานในการทำงานร่วมกันและเพิ่มความซับซ้อนของงาน
  • เกิดความไม่สอดคล้องกันระหว่างประวัติการเปลี่ยนแปลงของโค้ดกับความคืบหน้าของการรีวิว และทำให้จัดการ merge conflict ได้ยาก

การเปลี่ยนแปลงใหม่และความเป็นไปได้ในอนาคต

• ในอนาคตมีความเป็นไปได้ที่Git upstream จะรองรับ Change-Id สไตล์ Gerrit
  • จะช่วยให้ติดตามประวัติการแก้ไขรายคอมมิตได้ง่ายขึ้น และคาดว่าจะรองรับinterdiff reviewได้กว้างขึ้น
  • แต่ก็มีแนวโน้มว่าจะขัดกับแนวทางของ git-review บางส่วน
  • ในโครงสร้าง Change-Id แบบใหม่ อาจเปิดทางให้เกิดแนวทางแปลกใหม่ เช่น การเพิ่มคอมเมนต์รีวิวเข้าไปในตัวคอมมิตเอง

บทสรุปและระบบที่น่าสนใจสำหรับอ้างอิง

• สุดท้าย ตอนนี้จึงย้อนกลับมาใช้การรีวิวโค้ดผ่านเว็บอินเทอร์เฟซอีกครั้ง
• ความต้องการโซลูชันที่ดีกว่ายังคงมีอยู่
• ระบบและเครื่องมือที่เกี่ยวข้องซึ่งน่าสนใจ
  • Fossil: ระบบ SCM ที่เก็บข้อมูลทุกอย่างไว้ภายใน repository
  • NoteDb: รวมประวัติการเก็บสถานะรีวิวของ Gerrit เข้ากับ git
  • git-bug: เก็บข้อมูล issue ไว้ใน git
  • git-appraise: เก็บข้อมูลรีวิวไว้ใน git เอง
  • prr: สร้างอินเทอร์เฟซรีวิวในเอดิเตอร์โดยเชื่อมกับ GitHub API
  • How Jane Street Does Code Review: ตัวอย่างของแนวทางที่ดีกว่าในโลกความเป็นจริง
  • git-pr: โปรเจกต์ที่แทนที่เวิร์กโฟลว์ PR ทั้งหมดด้วยความสามารถเนทีฟของ git

ปิดท้าย

• ตอนนี้ยังไม่มีทางออกที่สมบูรณ์แบบ และความพยายามเพื่อสร้างประสบการณ์นักพัฒนาที่ดียิ่งขึ้นก็ยังดำเนินต่อไป
• ยังมีความคาดหวังอย่างมากต่อทิศทางการพัฒนาในอนาคต