นักพัฒนาบางส่วนชอบการรีวิวโค้ดแบบ "interdiff"

 (gist.github.com/thoughtpolice)
3 คะแนน โดย GN⁺ 2024-09-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ทำไมบางคนถึงชอบการรีวิวโค้ดแบบ "interdiff"

การประเมินเครื่องมือรีวิวโค้ด Gerrit

  • Gerrit เป็นเครื่องมือรีวิวโค้ดโอเพนซอร์สที่ทำงานร่วมกับคลังเก็บ Git
  • สามารถเขียนแพตช์ในคลังเก็บและส่งเพื่อขอรีวิวได้
  • ผู้อื่นสามารถตรวจทานโค้ดที่เขียนไว้และชี้ปัญหาที่ต้องแก้ไขได้
  • โดยทั่วไปแล้ว การรีวิวโค้ดเป็นแนวคิดที่ดี
  • ในโครงการโอเพนซอร์ส โค้ดสามารถถูก merge ได้ ซึ่งเพิ่มทั้งภาระความรับผิดชอบและหนี้ทางเทคนิค

เครื่องมือรีวิวโค้ดหลากหลายแบบ

  • มีเครื่องมือหลายแบบ เช่น Gerrit, GitHub, Phabricator, การอัปโหลดไฟล์ .patch ไปยังตัวติดตามบั๊ก, และการส่งอีเมลผ่าน git send-email
  • เครื่องมือแต่ละชนิดใช้งานได้ในระดับที่แตกต่างกัน

ชุดแพตช์ในอุดมคติ

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

วิธีรีวิวโค้ดของ GitHub: "diff soup"

  • เดิมที GitHub สนับสนุนให้รีวิวโดยเพิ่มคอมมิตใหม่ทับบนคอมมิตเดิม
  • เรื่องนี้เกิดจากการออกแบบ UX และเหตุผลอื่น ๆ หลายประการ
  • เมื่อมีการเพิ่มหลายคอมมิตระหว่างกระบวนการรีวิว ความสัมพันธ์โดยนัยระหว่างคอมมิตจะซับซ้อนขึ้น
  • ทำให้ใช้งานเครื่องมือ git blame และ git bisect ได้ยากขึ้น

วิธีที่ดีกว่า: การรีวิวแบบ "interdiff" (หรือ git range-diff)

  • แทนที่จะเพิ่มคอมมิตใหม่ จะเผยแพร่คอมมิตเดิมในเวอร์ชันใหม่
  • ใช้ git range-diff เพื่อเปรียบเทียบความต่างระหว่างเวอร์ชันของคอมมิต
  • ผู้รีวิวสามารถรีวิวแบบเพิ่มทีละส่วนได้ โดยไม่ต้องกลับไปอ่าน diff ทั้งหมดใหม่
  • เครื่องมือ git blame และ git bisect ทำงานได้เชื่อถือได้มากขึ้น

คำอธิบายแทรก: กลยุทธ์การ merge แพตช์

  • วิธีข้างต้นเป็นอิสระจากกลยุทธ์การ merge (เช่น git rebase เทียบกับคอมมิต git merge แบบหลายพาเรนต์)

คำอธิบายแทรก: git rebase เป็นสิ่งเลวร้ายหรือไม่

  • git rebase ใช้ได้ ไม่มีปัญหา เพียงแต่ไม่ควรใช้บน public branch ที่คนอื่นจะนำคอมมิตไปต่อยอด

บันทึกอื่น ๆ

บทสรุป

  • ระบบรีวิวแบบ interdiff ส่งเสริมให้เกิดแพตช์ที่เล็กกว่าและถูก merge เข้าสู่เมนแบรนช์ได้เร็วขึ้น
  • มอบประสบการณ์รีวิวโค้ดที่ดีกว่าให้ทั้งผู้รีวิวและผู้เขียน

สรุปโดย GN⁺

  • บทความนี้นำเสนอการวิเคราะห์เชิงลึกเกี่ยวกับเครื่องมือและวิธีวิทยาการรีวิวโค้ด
  • วิธีรีวิวแบบ interdiff สามารถเพิ่มประสิทธิภาพของการรีวิวโค้ดได้อย่างมาก
  • ช่วยแก้ปัญหา "diff soup" ของ GitHub ได้
  • นำเสนอปัจจัยสำคัญที่ควรพิจารณาเมื่อเลือกเครื่องมือรีวิวโค้ด
  • เครื่องมือที่มีความสามารถคล้ายกัน ได้แก่ GitHub, Gerrit และ Phabricator

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-09-12
ความเห็นจาก Hacker News

  • เวิร์กโฟลว์ที่ใช้กันเป็นหลักบน GitHub มีงานจุกจิกมากและไม่ชัดเจนสำหรับผู้ร่วมงาน

    • ทำให้ผู้รีวิวเห็น diff ที่รวมฟีดแบ็กแล้วได้ โดยไม่ทำให้ git blame และ git bisect ใช้งานเสียไป
    • ตอนรวมฟีดแบ็กจากผู้รีวิว จะใช้ git commit --fixup <แฮชของคอมมิตที่จะอัปเดต>
    • เมื่อ PR ได้รับการอนุมัติแล้ว จะใช้ git rebase --interactive origin/main --autosquash เพื่อรวมคอมมิต fixup เข้ากับคอมมิตต้นฉบับ
    • สุดท้ายจะใช้ git push --force-with-lease เพื่อรวมเข้าไป
    • ใช้ฟีเจอร์เติมคำสั่งอัตโนมัติเพื่อพิมพ์คำสั่งยาว ๆ ได้ง่ายขึ้น

  • วิธีทำโค้ดรีวิวของ GitHub ไม่มีประสิทธิภาพ และเคยใช้ Phabricator จัดการแบบแมนนวล

    • ถ้ามี UI ที่ชัดเจนโดยตรงก็น่าจะดีกว่า

  • ต้องการระบบที่ดีกว่าวิธีทำโค้ดรีวิวของ GitHub

    • อยากรวมแพตช์แก้บั๊กเล็ก ๆ ได้เร็ว และทำให้ขอบเขตการรีวิวแคบลง
    • มีคนบอกให้แยกเป็นรีวิว/PR คนละอัน แต่จะเกิดปัญหาเรื่องการพึ่งพากันระหว่าง patchset

  • การได้เห็นแนวทางใหม่ ๆ สำหรับโค้ดรีวิวเป็นเรื่องน่าสนใจเสมอ

    • เคยคิดจะลองแยกแพตช์ออกเป็น PR ที่พึ่งพากันคนละชุด
    • เครื่องมืออย่าง GitContext ช่วยให้ PR ยังเล็กได้พร้อมคง dependency ไว้
    • สามารถใช้ AI เพื่อสรุป PR และรีวิว รวมถึงสร้างข้อความ commit ที่แม่นยำได้
    • ผู้รีวิวจะเห็นเฉพาะการเปลี่ยนแปลงตั้งแต่การรีวิวครั้งล่าสุด

  • Review Board เป็นผู้แนะนำ interdiffs เป็นครั้งแรก และสิ่งนี้มีประโยชน์มากในการโค้ดรีวิว

    • คอมมิต fix-it ไม่ใช่ทางเลือกที่เหมาะสม
      1. มองไม่เห็นการเปลี่ยนแปลงต้นทาง
      2. ทำให้กราฟคอมมิตซับซ้อนขึ้น
      3. ไม่ใช่ทุกคนที่ใช้ Git
    • interdiffs ช่วยให้ผู้รีวิวติดตามอัปเดตทั้งหมดได้ตั้งแต่คำขอรีวิวครั้งแรก
    • มีประโยชน์เมื่อโพสต์หลายคอมมิตเป็นคำขอรีวิวเดียว

  • มีประสบการณ์ใช้ระบบโค้ดรีวิว Gerrit และมองว่าวิธีโค้ดรีวิวของ GitHub ไม่มีประสิทธิภาพ

    • Gerrit รองรับการซ้อนหลายแพตช์เป็นสแตก ทำให้รีวิวแพตช์เล็ก ๆ ได้ง่าย
    • อินเทอร์เฟซของ GitHub ดูเหมือนเธรดฟอรัม และไม่สามารถติดตามการ rebase ได้

  • เคยใช้ระบบโค้ดรีวิวมาหลายแบบ และแต่ละระบบก็มีข้อดีข้อเสียต่างกัน

    • Critique ถูกปรับให้เหมาะกับโมโนรีโปของ Google และ VCS แบบปรับแต่งเฉพาะ
    • Gerrit ดีสำหรับผู้รีวิว แต่ไม่สะดวกสำหรับผู้เขียน
    • GitHub เป็นมิตรกับผู้เขียน แต่ไม่มีประสิทธิภาพสำหรับผู้รีวิวและทีม
    • การใช้เครื่องมือโค้ดรีวิวที่ดีกว่าเป็นเรื่องสำคัญ

  • หลังจากใช้ระบบโค้ดรีวิว Gerrit แล้ว ก็รู้สึกว่า stack PR ของ GitHub ใช้งานลำบาก

    • GitHub ไม่แสดงการเปลี่ยนแปลงต่อคอมเมนต์ในโค้ดรีวิวได้ดีพอ
    • ใช้สคริปต์บางตัวเพื่อให้การทำงานกับ stack PR ง่ายขึ้น
    • เครื่องมืออย่าง ejoffe/spr และ spacedentist/spr มีประโยชน์