GitHub เปิดตัว Stacked Pull Requests: ย่อยงาน AI ชิ้นยักษ์ให้รีวิวง่ายและเป็นระเบียบ

ลองนึกถึงฟีเจอร์ใหญ่ล่าสุดที่คุณเพิ่งส่งงานไป คุณยัดมันลงใน Pull Request (PR) ขนาดมหึมาเพียงอันเดียว หรือแยกมันเป็น PR ย่อยๆ ตามขอบเขตงาน? เป็นเวลาหลายปีที่นักพัฒนาต้องตัดสินใจระหว่างการยอมเห็น PR เติบโตจนการรีวิวกลายเป็นฝันร้าย หรือการแยกมันเป็นสายของ PR ย่อยๆ ที่ต้องคอยดูแล ซิงค์ข้อมูล และแก้ปัญหาความขัดแย้ง (conflict) ด้วยตัวเองทุกครั้งที่มีการเปลี่ยนแปลงในลำดับชั้นที่ต่ำกว่า

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

ปัจจุบันเมื่อมี coding agents เข้ามาเสริมทัพ ผลิตภาพของงานก็ยิ่งเพิ่มสูงขึ้น โดย อ้างอิงจาก Gartner คาดการณ์ว่า AI จะช่วยเพิ่มผลิตภาพได้ถึง 50% ในทุกขั้นตอนของ SDLC ภายในปี 2028 แต่ถึงอย่างนั้น AI ก็ยังไม่สามารถตัดสินใจแทนคุณได้ว่าควรจัดโครงสร้าง PR อย่างไร กลับกันพวกมันยิ่งตอกย้ำความจำเป็นที่ต้องมีการจัดระเบียบที่ดีขึ้น โพสต์นี้จะพาไปดูวิธีใช้ stacked pull requests เพื่อทำให้การรีวิวโค้ดเป็นเรื่องง่าย

เจาะลึก: การเพิ่มระบบค้นหาสินค้าใน shopping assistant

สมมติว่าคุณสั่งให้ AI เพิ่มระบบค้นหาสินค้าให้กับ shopping assistant เพียงไม่กี่นาทีต่อมา เมื่อคุณกลับมาตรวจสอบโค้ด สิ่งที่มักจะพบใน PR ชุดเดียวนั้นมักประกอบด้วย:

Data model ใหม่และ Seed data
API route และการตรวจสอบความถูกต้อง (validation)
การเชื่อมต่อฝั่ง Client, UI และสถานะ error ต่างๆ

ข้อมูลทั้งหมดนี้รวมอยู่ในความเปลี่ยนแปลงขนาดมหึมาที่ยาวกว่า 1,000 บรรทัด

Animated gif showing the pull request size grow from 0 lines to over 1,500 lines.

สำหรับ agent ที่ถูกฝึกมาตามวิธีการเขียนโค้ดแบบเดิม รูปแบบนี้คือวิธีเริ่มต้นในการส่งงานของพวกมัน ลองมาดูสถานการณ์จำลองที่คุณต้องการเพิ่มระบบค้นหาสินค้าในเว็บแอปพลิเคชัน โดยเริ่มจากศูนย์ที่ไม่มีทั้ง catalog module, API หรือ data layer ใดๆ

Screenshot of the starting state of the website without a product search.

เมื่อมีการเปิด Issue เพื่อพัฒนาฟีเจอร์ ขั้นตอนปกติคือการสร้าง feature branch มอบหมายงานให้ coding agent และรอรับโค้ดทั้งหมดรวมถึงการทดสอบที่อัปเดต

หลังจากนั้นคุณต้องอ่านโค้ด ตรวจสอบพฤติกรรมของฟีเจอร์ด้วยตนเอง ทำการอัปเดตที่จำเป็น และเปิด PR พร้อมคำอธิบายที่สร้างโดย AI ซึ่งมักจะยาวแต่ไม่มีเนื้อหาสำคัญ เมื่อคุณส่งให้คนอื่นรีวิว สิ่งที่เกิดขึ้นมักจะเป็นดังนี้:

<reviewer's hat>

Reviewer: เปลี่ยนไปตั้ง 1,721 บรรทัด!! คำอธิบายนี้ก็ไม่ค่อยมีประโยชน์ เดี๋ยวค่อยมารีวิวแล้วกัน

</reviewer's hat>

ผลที่ตามมาคือ PR ขนาดใหญ่กลายเป็นคอขวด ผู้รีวิวสูญเสียบริบท คุณภาพคำแนะนำลดลง และการ merge งานล่าช้าลงอย่างมาก เสี่ยงต่อการเกิด conflict ก่อนใช้งานจริง

GitHub stacked pull requests

Stacked pull requests นำเสนอโครงสร้างการส่งงานที่ดีกว่าด้วยหลักการ "การย่อยงาน" (decomposition) แทนที่จะส่ง PR เดียวที่แก้ทุกอย่าง คุณจะแยกฟีเจอร์ออกเป็นชั้นเชิงตรรกะและระบุห่วงโซ่ของสิ่งที่ต้องพึ่งพากัน วิธีนี้ช่วยให้คุณและ agent ย่อยงานยักษ์ให้กลายเป็นสายของงานที่เล็ก ตรงจุด และสามารถรีวิวแยกกันได้

PR ขนาดใหญ่จะถูกเปลี่ยนเป็น stack ของ PR ขนาดเล็กที่จัดเรียงตามลำดับตรรกะ โดยแต่ละอันจะจำกัดวงอยู่เพียง เรื่องเดียว (single concern) มีขนาดเล็กพอที่จะเข้าใจง่าย และมีบริบทที่ต่อเนื่องมาจากชั้นก่อนหน้าโดยธรรมชาติ

โครงสร้างของ Stack

การสร้าง stack เริ่มจากการ set the stack base ซึ่งสำคัญมากเพราะ CI checks และกฎการ merge จะถูกประเมินเทียบกับ base นี้ จากนั้นจึงวางงานที่เป็นแกนหลักไว้ล่างสุด และวางงานที่ต้องพึ่งพามันไว้ในชั้นต่อๆ ไป

Stack Layer (L#)/Branch	สิ่งที่ต้องส่ง	ขึ้นอยู่กับ
L1 (feat/catalog-data)	typed catalog พร้อม seed data และ data access	main (stack base)
L2 (feat/search-api)	endpoint /api/products/search	feat/catalog-data
L3 (feat/chat-grounding)	Chat เรียกใช้ API และตอบข้อมูลจริง	feat/search-api
L4 (feat/grounded-ui)	Product citation cards + สถานะต่างๆ	feat/chat-grounding

โครงสร้างนี้ช่วยให้แยกการรีวิวตามความเชี่ยวชาญได้ชัดเจน เช่น ให้เจ้าของข้อมูลรีวิวส่วน Data และให้เจ้าของ UI รีวิวส่วน UX โดย GitHub รองรับการทำงานนี้ผ่านหน้า UI และ gh stack CLI

ติดตั้ง stacked pull requests CLI extension

ใช้คำสั่งต่อไปนี้เพื่อติดตั้งส่วนขยาย:

gh extension install github/gh-stack

นอกจากนี้ คุณยังต้องสอนให้ coding agents เรียนรู้วิธีจัดการ stack แทนคุณด้วยคำสั่ง:

gh skill install github/gh-stack

หรือผ่าน npx:

npx skills add github/gh-stack

ขั้นตอนการทำงานในแต่ละชั้น

ในแต่ละชั้น (Layer) ตั้งแต่การสร้าง Data catalog ไปจนถึง Grounded UI coding agents จะทำงานเป็นลำดับขั้น โดยเริ่มจากการสร้าง stack ใหม่ เพิ่มชั้นงานทีละส่วนบน branch ก่อนหน้า และรันการตรวจสอบจนกว่าจะผ่านก่อนที่จะดำเนินการในชั้นถัดไป

เมื่อ local stacked branches ทั้งหมดพร้อมแล้ว คุณสามารถ push งานไปยัง remote ด้วย gh stack push และสร้าง PR ที่เชื่อมโยงกันบน GitHub ด้วย gh stack submit ได้ทันที

การรีวิวและอัปเดต Stack

บน GitHub คุณจะพบ stack map ซึ่งเป็นระบบนำทางที่ช่วยให้ผู้รีวิวย้ายไปมาระหว่าง PR ใน stack ได้อย่างรวดเร็ว โดยมีหลักการคือ อ่านจากบนลงล่าง เพื่อดูบริบทโดยรวม และ รีวิวจากล่างขึ้นบน เพื่อตรวจสอบงานตามลำดับความสำคัญ

หากมีการร้องขอการเปลี่ยนแปลง (changes requested) ในชั้นล่างสุด คุณสามารถให้ agent แก้ไขโค้ดใน branch นั้น และใช้คำสั่ง gh stack rebase หรือ gh stack sync เพื่อให้การเปลี่ยนแปลงกระเพื่อมขึ้นไปยังชั้นบนของ stack โดยอัตโนมัติ ช่วยให้ stack map กลับมาพร้อม merge สู่สายงานหลักได้อย่างสะอาดหมดจด

เริ่มต้นใช้งาน stacked pull requests >