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

 (tigerbeetle.com)
26 คะแนน โดย GN⁺ 2025-08-22 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักพัฒนาจำนวนมากรู้สึกไม่พอใจกับประสบการณ์การรีวิวโค้ดของ 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

ปิดท้าย

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

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

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

 
roxie 2025-08-23

ไม่แน่ใจว่าแนวทางของ git-review ดีจริงไหม แต่เห็นด้วยว่า PR review ที่อิงกับ GitHub นั้นแย่มาก..
 
GN⁺ 2025-08-22
ความคิดเห็นจาก Hacker News

  • สิ่งที่น่าหงุดหงิดกับ code review มานานคือ feedback ที่มีประโยชน์จริง ๆ (ไม่ใช่แค่การทักเรื่องสไตล์เล็กน้อย) แทบจะมาช้าเกินไปเสมอ จนผลลัพธ์เดียวที่เกิดขึ้นบ่อย ๆ คือ "อันนี้ต้องรื้อแล้วเริ่มใหม่ด้วยดีไซน์ใหม่ทั้งหมด" หรือ "จริง ๆ แล้วไม่จำเป็นต้องทำงานนี้ตั้งแต่แรก" ดูเหมือนว่า code review จะเป็นช่วงเวลาเดียว (หรือไม่กี่ครั้ง) ที่ผู้มีส่วนได้ส่วนเสียทุกฝ่ายเข้ามามีส่วนร่วมจริง ๆ และคิดเรื่องการเปลี่ยนแปลงอย่างจริงจัง อาจเคยมีการคุยกันในมีตติ้งหรือ Jira ticket มาก่อน แต่บ่อยครั้งคนจากอีกทีมหรืออีกแผนกหนึ่งจะเพิ่งรู้ว่ามีการเปลี่ยนแปลงนี้ก็ตอนที่ได้รับการแจ้งเตือน code review ฉันเองก็หลายครั้งเพิ่งรู้ว่าทีมอื่นกำลังทำอะไรแปลก ๆ จากการแจ้งเตือน code review เช่นกัน จะให้ทุกคนตามทุกอย่างล่วงหน้าไว้หมดเป็นเรื่องไม่สมจริง ตอนเรียนมหาวิทยาลัยยุค 90 เคยมี design review แต่ในงานจริงไม่เคยเห็นเลย และก็ไม่คิดว่า design review จะรับประกันได้ว่าจะจับทุกปัญหาได้ตั้งแต่ต้น

    • ในโลกของวิศวกรรมซอฟต์แวร์ แทบไม่มีความเป็น engineering แบบจริงจังอยู่มากนัก ส่วนหนึ่งเพราะอุตสาหกรรมนี้ยอมรับความช้าของกระบวนการ engineering ที่เหมาะสมไม่ได้ ซอฟต์แวร์ส่วนใหญ่ไม่ได้ถึงขั้นอันตรายถึงชีวิต และบั๊กหรือความผิดพลาดก็มักแก้ทีหลังได้ stakes และโอกาสในการ patch จึงต่างจากสะพาน โรงงาน หรือเครื่องยนต์เครื่องบิน ที่ความล้มเหลวเป็นสิ่งยอมรับไม่ได้

    • ทีมของเรามี developer กลุ่มเล็ก ๆ 4-6 คน เวลาเริ่มทำฟีเจอร์ใหม่ พอมีภาพร่างในหัวแล้วก็จะคุยกับเพื่อนร่วมทีมทันที ทุกคนทำแบบนี้กันหมด ทำให้ code review เน้นเรื่องเล็ก ๆ อย่าง code smell เป็นหลัก ส่วนสถาปัตยกรรมภาพใหญ่ก็มักตกลงกันล่วงหน้าโดยคน 2-3 คน ถ้าสมาชิกทีมไม่เห็นด้วยกับโค้ด พวกเขามักไม่อยากแตะโค้ดของกันและกัน แล้วสถานการณ์จะยิ่งแย่ลง ฉันเชื่อว่าต่อให้ทีมใหญ่กว่านี้ ถ้าแบ่งปันความรับผิดชอบกันได้ดีก็ทำได้โดยไม่มีปัญหา

    • การที่ผู้มีส่วนได้ส่วนเสียทุกคนเข้ามามีส่วนร่วมเฉพาะตอน code review ไม่ใช่ปัญหาของ Git หรือระบบ version control แต่เป็นปัญหาเชิงองค์กร มันคือการไม่สามารถแชร์ที่มาของ PR การคุยกันใน ticket และกระบวนการตัดสินใจได้ นี่เป็นตัวอย่างขององค์กรที่ทำงานผิดเพี้ยน พอ ๆ กับการด่ากระบวนการพิมพ์หนังสือว่าแย่ เพราะทุกคนเพิ่งมารวมตัวและมีส่วนร่วมกันจริงจังก็ตอนหนังสือพิมพ์ออกมาแล้ว

    • องค์กรของเราบังคับให้เขียน RFC สำหรับการตัดสินใจเชิงดีไซน์ที่เป็นแก่นหลักเสมอ อะไรถือเป็นการตัดสินใจเชิงดีไซน์ระดับแก่นหลักนั้น ทีมจะตัดสินใจกันเองเป็นระยะ ๆ ถ้าอยู่ในขั้น epic ของ Jira แล้ววิธี implementation รายละเอียดยังไม่ชัด ก็จะ assign ให้เขียน RFC ก่อน RFC อาจใช้ภายในทีมเราเอง หรือเปิดให้ทั้งทีมซอฟต์แวร์อ่านก็ได้ และถ้าเป็นแบบหลัง ทุกคนจะอ่านและคอมเมนต์ได้ก่อนมีตติ้งที่จัดทุก 2 สัปดาห์ แม้จะเหนื่อย แต่ก็ยังดีกว่าที่ทำงานซึ่งไม่มี collaborative design process ที่อิง RFC มาก

    • จากประสบการณ์ของฉัน เห็นด้วยมากกับเรื่อง design review แต่ก่อนเราเคยใช้เอกสารดีไซน์แบบเป็นทางการและมีการรีวิว แล้วภายหลังเปลี่ยนไปใช้การทำ prototype และการออกแบบแบบ iterative เพราะในขั้นดีไซน์มักตกหล่นรายละเอียดสำคัญ และเมื่อใช้เวลาไปมากแล้ว พอถึงช่วงหลังก็มักปล่อยผ่านแบบขอไปที การให้ทั้งทีมมานั่งรีวิวพร้อมกันก็ไม่มีประสิทธิภาพ สุดท้ายปัญหาจึงไปถูกพบใน code review อีกทั้งยังมีหลายคนที่เขียนเอกสารดีไซน์ไม่เก่งหรือไม่มีแรงจูงใจ สรุปคือถ้ามีคนเกิน 5 คน ความไม่มีประสิทธิภาพแบบนี้แทบหลีกเลี่ยงไม่ได้ สภาพแวดล้อมที่เหมาะที่สุดคือมี PO ผู้ใช้หลัก และ developer ราว 5 คนร่วมกัน

  • อ่านโพสต์ใน HN เรื่อง stacked pull request แล้วรู้สึกน่าสนใจมาก ตอนเริ่ม graphite.dev ใหม่ ๆ ถ้าไม่เคยผ่าน Facebook หรือ Google มาก่อน หลายคนจะไม่รู้จัก workflow แบบนี้เลย สนุกดีที่ได้เห็นว่าเทรนด์ code review เปลี่ยนเร็วมากภายใน 3-4 ปีที่ผ่านมา

    • ในฐานะผู้ใช้ arcanist มาตั้งแต่ก่อนยุค mercurial ฉันยังคงเชียร์ Graphite อย่างมากกับทีมที่ยังลำบากกับ PR ใหญ่ ๆ หรือ merge commit โดยเฉพาะ ฉันประทับใจมากกับความกล้าทำและผลลัพธ์ที่ทำให้มันเชื่อมกับ PR ได้สำเร็จ อยากให้ Graphite มีโหมด prescriptive ที่สามารถ initialize repo ด้วยการตั้งค่าแบบฮาร์ดคอร์ เพื่อให้ตั้งสมมติฐานที่เข้มข้นกว่านี้ได้

    • แม้ Graphite จะเป็นโซลูชันที่ยอดเยี่ยม แต่ราคาค่อนข้างแพงและยากที่จะโน้มน้าวคนที่มีอำนาจตัดสินใจให้ซื้อ หวังว่าจะมีเครื่องมือเจ๋ง ๆ แบบ Graphite ที่เป็นโอเพนซอร์ส หรือถูกฝังมาใน GitHub เลย

    • ฉันก็แอบคิดถึง fig workflow เหมือนกัน

    • หลังเหตุการณ์ด้านความปลอดภัยล่าสุดของ CodeRabbit ก็เริ่มไม่อยากทดสอบเครื่องมือใหม่ ๆ ที่ผสาน LLM เข้ากับ codebase เพราะการทดลองใหม่ที่ดูน่าตื่นเต้นสามารถกลายเป็นปัญหาด้านความปลอดภัยได้ง่าย

    • stacked pull request โดยเนื้อแท้แล้วคือการเพิ่มความซับซ้อนที่ไม่จำเป็น การเปลี่ยนแปลงเล็ก ๆ บ่อย ๆ เป็นแนวปฏิบัติในการพัฒนาที่ดีกว่ามาก และ trunk-based development หรือ continuous integration ก็เหมาะกับเป้าหมายนั้นดี

  • ดูเหมือน developer จำนวนมากขึ้นเรื่อย ๆ กำลังเห็นตรงกันว่า "เครื่องมือรีวิวควรมีหน้าตาแบบไหน" ตอนนี้จึงเป็นช่วงที่สำคัญว่าองค์กรและผู้เล่นรายใดจะทำให้สิ่งนี้นำไปใช้ได้จริงและยั่งยืน การนำ git change-id มาใช้เมื่อเร็ว ๆ นี้ถือเป็นพัฒนาการที่ดีมาก (ขอบคุณ jj, git butler, gerrit และอื่น ๆ) Graphite หรือ GitHub ยังมุ่งแก้ปัญหาให้เฉพาะผู้ใช้ของตัวเอง จึงไม่ได้เปิดกว้างสำหรับทุกคน ส่วนเครื่องมือ command line ฝั่ง client ที่มีอยู่มากมายก็ไม่ได้ทรงอิทธิพลนัก สิ่งที่จำเป็นจริง ๆ คือ:

    • ต้องใช้งานแบบ local ล้วนได้
    • ต้องมีการสนับสนุนอย่างเป็นทางการจาก core team ของ vscode (โดยเฉพาะให้ vscode integration มี UX ที่ดี)
    • ต้องนำ UI assets เดียวกันกลับมาใช้ซ้ำให้มากที่สุดกับ web UI อย่าง vscode web และ editor อื่น ๆ
    • ต้องมีความสามารถแกนหลักใน CLI หรือ library และมีขอบเขตที่ชัดเจนสำหรับการขยายต่อ
    • ต้องรองรับ commit/branch/stacked commit/agent snapshot/dev review ของตัวเองทั้งหมด
    • ต้องผสานสัญญาณ CI/CD แบบ native และต่อยอดจากงานด้าน UI ที่ยอดเยี่ยมที่ Meta เคยแสดงไว้
    • ต้องละเอียดมากตามบริบท และแก้ไขได้ทุกขั้นตอน (เช่น ใน cursor ยอมรับได้ทีละบรรทัด และ human code review ก็ควรมีการแก้ไขแบบ granular เช่นกัน)
    • ต้องเป็น incremental อย่างสมบูรณ์ และเมื่อมีการแก้ PR ต้องมีวิธีรีวิวเฉพาะส่วนที่เปลี่ยนได้ง่าย แทนที่จะต้องดูทั้งหมดใหม่

  • สิ่งที่ไม่ชอบที่สุดใน Github คือแอปมันช้ามาก ช้าจนแท็บเบราว์เซอร์ค้างได้จริง ๆ Azure DevOps เป็นเครื่องมือ code review ที่ดีที่สุดเท่าที่ฉันเคยใช้มา

    • ฉันเคยใช้ Azure DevOps ตอนพัฒนา .NET ในสภาพแวดล้อมของ Microsoft มันเป็นเครื่องมือที่เข้ากับ ecosystem ของ .NET ได้ดีจริง ๆ

    • สงสัยว่าคุณเคยใช้งาน GitLab อย่างจริงจังไหม สำหรับฉันใน big 4 แล้ว GitLab คืออันที่ชอบที่สุด

    • อยากรู้ว่าอะไรใน DevOps ที่คุณชอบขนาดนั้น ฉันใช้มันทุกวันและรู้สึกว่าคล้าย github มาก เสียอีก บางทีกลับคิดถึงฟีเจอร์ apply suggested changes อัตโนมัติของ github ด้วยซ้ำ

    • การใช้ JavaScript อย่างหนักบวกกับแรงกดดันให้ปล่อยเวอร์ชันเร็ว ทำให้ได้สภาพแวดล้อมที่ช้าแบบนี้ ถึงอย่างนั้นก็ยังดีกว่า Atlassian

  • ไอเดียการใช้ git โดยตรงกับ code review ฟังดูน่าสนใจ เพราะสะดวกที่สามารถลองจับเปลี่ยนแปลงต่าง ๆ ได้ในเครื่องตัวเองเลย ไม่เข้าใจเหมือนกันว่าทำไมต้องพยายามผูกการรีวิวให้ตรงกับ single commit เท่านั้น—แนวทางที่ reviewer commit คอมเมนต์หรือการแก้ไขของตัวเองลงใน PR branch โดยตรงก็ดูน่าสนใจดี นี่เป็น hybrid ระหว่าง github flow แบบดั้งเดิมกับ workflow แบบ mailing list/patch ของ Linux

    • สงสัยว่า github PR เป็นแบบ read-only หรือเปล่า ฉันเคยเห็นสมาชิกทีมเสนอการแก้ผ่านคอมเมนต์แบบ "suggestion" แล้วกดปุ่มครั้งเดียวก็เอาเข้า commit นั้นได้เลย

    • การบังคับให้ review commit ต้องมีแค่ commit เดียวเป็นเรื่องแปลก ถ้ามีหลายคนรีวิวก็จะเกิดปัญหาแก้ไขพร้อมกัน และมันก็ไม่สอดคล้องกับตัวโค้ดด้วย การให้แต่ละคนทำงานรีวิวของตัวเองแยกกันบนคนละ branch แล้วค่อย squash & rebase ตอนท้ายดูเป็นธรรมชาติกว่า ถ้าการถกเถียงยืดเยื้อ ก็อาจปล่อยให้มี comment commit ต่อเป็นสายกันไปก็ได้ สิ่งสำคัญคือข้อมูลพวกนี้ต้องอยู่ที่ไหนสักแห่งนอก main branch

  • ตอนรีวิวโค้ด ฉันชอบดึงลงมาเป็น local branch แล้ว soft-reset จากนั้นดูมันเหมือนเป็นโค้ดที่ตัวเองเขียนเอง ถ้า commit ถูกแบ่งมาไม่ดี ผู้ร่วมงานแต่ละคนก็ต้องมานั่งแยกมันเองเพื่อรีวิว ซึ่งไม่มีประสิทธิภาพ ถ้าสิ่งที่ต้องรีวิวมันใหญ่เกินไป ก็ยากที่จะบอกว่าใครเข้าใจทั้งหมดอย่างแท้จริง เพราะองค์รวมไม่ได้เป็นเพียงผลรวมของส่วนย่อย

    • ขอแชร์ตัวอย่าง shell function สำหรับ code review แบบง่าย ๆ ใช้งานจาก tree ที่สะอาด โดย checkout branch สำหรับ review ไว้ล่วงหน้า เปิดดู diff ใน nvim และพอเสร็จก็จัดการ branch ให้อัตโนมัติ

    • การทำ commit ที่ดีและสร้าง PR จากมันให้ดี เป็นทักษะที่สำคัญพอ ๆ กับการเขียนโค้ดให้ดี แต่ในความเป็นจริง developer ที่ไม่เก่งเรื่องการแยก PR หรือเขียน commit message ยังมีมากกว่าที่คิด

    • ในทีมที่ทำงาน parallel ด้าน data science จะ checkout branch สำหรับ code review ไว้ใช้ 2-3 อัน

    • สำหรับการรีวิว PR ฉันใช้ https://github.com/sindrets/diffview.nvim บน Neovim มันให้ UI คล้าย diff ของ vscode แต่ใช้ diff mode ของ vim ส่วนงานรีวิวเบา ๆ git log -p --function-context ก็มีประโยชน์

  • ฉันสนใจแนวทางที่ให้คนหนึ่งเขียน draft แรก แล้วอีกคนมาขัดเกลาและ merge ต่อ มีใครเคยลองทำจริงไหม

    • ฉันเห็นด้วยกับสไตล์ที่คนเขียนทำงานจริงเกิน 90% ส่วน reviewer เป็นคนรับผิดชอบการรวม final changes และ merge ด้วยตัวเอง ที่ทำงานเก่าของฉัน reviewer จะเป็นคน merge เสมอ และถ้าเป็นการเปลี่ยนแปลงใหญ่ก็จะส่งต่อแค่คอมเมนต์ วิธีนี้มีประสิทธิภาพกว่าการต้องคอยขอให้ใครมากด approve ทีละอันมาก

    • ถ้าได้มีส่วนช่วยเขียนโค้ดที่รีวิวอยู่ ก็จะให้ feedback ที่ลึกขึ้นได้มาก และโครงสร้างแบบนี้ก็ช่วยให้คนมองมันเป็น "โค้ดของพวกเรา" ไม่ใช่ "โค้ดของฉัน/ของเธอ" เข้ากันได้ดีกับวัฒนธรรมแบบ iterative และเน้น collaboration อย่าง TDD

    • วิธีนี้คล้าย asynchronous pair programming

    • ฉันรู้จักคนที่ทำ pair programming ภายใต้ trunk-based development พอเขียนโค้ดกันสองคนเสร็จ ถ้าโอเคก็ merge เข้า main ทันที แล้วถ้าเทสต์ผ่านก็ deploy ได้เลย ซึ่งใช้งานได้จริง

  • ฉันใช้ปลั๊กอินขยาย Github Pull Request ใน VSCode เพื่อรีวิวแบบ local และมันค่อนข้างสะดวก เพราะสามารถคอมเมนต์และรีวิวได้ตรงใน editor เลย

    • บนเว็บ Github ถ้าไฟล์ที่เปลี่ยนมีเยอะ มักจะซ่อนบางไฟล์ แต่ใน VSCode สามารถนำทางได้อิสระกว่ามาก จึงใช้งานสบายกว่าเยอะ และเมื่อฟีเจอร์นี้ทำได้ในคู่ผสม VSCode/Github ก็คาดเดาได้ว่าน่าจะขยายไป editor อื่นได้ด้วย

    • มันดีขึ้นก็จริง แต่ก็ยังมี vendor lock-in หนักมากทั้งฝั่ง Github และ VSCode

    • บนเว็บ Github ถ้าเปิด PR แล้วกดปุ่ม “.” เพื่อเปิดใน VSCode web ทันที ประสบการณ์ก็ดีกว่ามากเช่นกัน

  • ดีใจมากที่ได้ยินว่า Git จะมี first-class change ID! มันคล้ายกับ revision tracking ของ diffs ใน Phabricator ของ Facebook มาก อยากได้ลิงก์ไปอ่านรายละเอียดเพิ่มเติม

    • ปัญหาพื้นฐานคือ git จัดการข้อมูล branch ได้ไม่ดีพอ Fossil จำได้ว่า commit ถูกสร้างมาจาก branch ไหน task branch เองก็ทำหน้าที่เป็น change ID ได้อยู่แล้ว แน่นอนว่า git ก็ต้องยอมให้มีการเขียนประวัติใหม่ได้ด้วย เลยยิ่งทำให้การแก้ปัญหานี้ยาก

  • อยากพูดถึง Sourcehut ด้วย มันสืบทอด workflow แบบคลาสสิกที่ส่ง patch/issue/bug/discussion ผ่านอีเมล และเชื่อมกับ mailing list และ CI ได้ อีกทั้ง Drew Devault ก็มีแหล่งข้อมูลเรื่องการส่งและรับ patch ที่ git-send-email.io และ git-am.io ให้ด้วย