จัดการ Spec, Tests และ Code ให้ตรงกันในยุค AI Development
เจาะลึกโมเดลความเชื่อมโยงและการทำ CI checks เพื่อป้องกันปัญหา Spec Drift เมื่อเอเจนต์ AI เขียนโค้ดเร็วเกินไป
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- AI coding agents ช่วยส่งมอบฟีเจอร์ได้เร็ว แต่ทำให้ specs, tests และ code หลุดจากกันเงียบๆ
- ทางแก้ไม่ใช่การเพิ่มเอกสาร แต่เป็นการสร้างความเชื่อมโยงขนาดเล็กที่ตรวจสอบได้ระหว่างข้อมูล 4 ส่วน
- ปัญหา Drift ปรากฏใน 4 รูปแบบที่ทีมพัฒนาที่ใช้ AI มักพบเจอได้เร็วกว่าปกติ
- การตรวจสอบความเชื่อมโยงควรถูกผูกไว้ในระบบ CI แทนที่จะเป็นหน้าวิกิที่ไม่มีใครอ่าน
เมื่อเครื่องมือ AI coding agents สามารถส่งมอบฟีเจอร์ได้อย่างรวดเร็ว สิ่งที่มักจะค่อยๆ คลาดเคลื่อนตามมาคือข้อกำหนด (specs) ชุดทดสอบ (tests) และโค้ด (code) คู่มือนี้จึงได้นำเสนอโมเดลความเชื่อมโยง (traceability model) การแมปจาก spec ไปยัง test และ code รวมถึงการทำ CI checks ที่ช่วยตรวจจับความคลาดเคลื่อนนี้ก่อนที่จะทำการรวมโค้ด (merge)
ข้อกำหนดที่ไม่มีใครนำกลับมาตรวจสอบเทียบกับระบบที่กำลังรันอยู่จริงนั้นแย่ยิ่งกว่าการไม่มีข้อกำหนดเสียอีก เพราะมันสร้างความมั่นใจที่จอมปลอม ผู้รีวิวเชื่อมั่นในเอกสารมากกว่าชุดความเปลี่ยนแปลง (diff) และเมื่อเอเจนต์ AI ได้รับคำสั่งให้ทำตามรูปแบบเดิม มันก็จะทำตามสิ่งที่โค้ดกำลังทำอยู่จริงๆ แม้ว่าสิ่งนั้นจะขัดแย้งกับข้อกำหนดที่ควรจะเป็นก็ตาม
ทางออกของปัญหานี้ไม่ใช่การเขียนเอกสารให้มากขึ้น แต่เป็นความเชื่อมโยงขนาดเล็กที่สามารถบังคับใช้ได้ระหว่างสิ่งที่มีอยู่แล้วในคลังโค้ดส่วนใหญ่ ได้แก่ ข้อกำหนด การตัดสินใจเบื้องหลังการออกแบบ ชุดทดสอบที่พิสูจน์สิ่งนั้น และคอมมิตหรือพูลรีเควสต์ที่เปลี่ยนแปลงมัน
การเกิด Specification Drift หรือที่วงการเรียกว่า Specification Rot ถือเป็นความท้าทายสำคัญในยุคที่ AI เข้ามาเร่งความเร็วในการเขียนโค้ด เนื่องจากเอเจนต์สามารถสร้างโค้ดซ้ำๆ ได้อย่างรวดเร็ว ทำให้ความตั้งใจในข้อกำหนดดั้งเดิมค่อยๆ ห่างเหินจากหน้างานจริง การเปลี่ยนผ่านจากเอกสารนิ่งๆ มาเป็นข้อมูลที่สืบย้อนได้ (Traceable Data) จึงเป็นกุญแจสำคัญในการควบคุมคุณภาพซอฟต์แวร์สมัยใหม่
ปัญหาความคลาดเคลื่อนหรือ Drift มักแสดงออกมาใน 4 รูปแบบที่จดจำได้ง่าย และทีมที่ขับเคลื่อนด้วย AI มักจะเผชิญกับทั้ง 4 รูปแบบนี้เร็วกว่าทีมที่เขียนโค้ดด้วยมือทุกบรรทัด การวิจัยกระบวนการพัฒนาซอฟต์แวร์ด้วย AI ระบุว่า Specification drift เป็นความเสี่ยงที่เกิดขึ้นซ้ำๆ เพราะเอเจนต์สร้างโค้ดใหม่อย่างรวดเร็วและซ้ำซ้อน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
โมเดลความเชื่อมโยงที่ใช้งานได้จริงจำเป็นต้องมีตัวระบุ (identifiers) 6 รายการที่เชื่อมโยงข้อกำหนดทางธุรกิจไปจนถึงบรรทัดโค้ดและพูลรีเควสต์ โดยความสัมพันธ์ระหว่างตัวระบุเหล่านี้จะมีลักษณะเป็นกราฟ (graph) แทนที่จะเป็นเส้นตรง เพราะข้อกำหนดหนึ่งข้อสามารถแตกแขนงเป็นงานย่อยได้หลายงาน และพูลรีเควสต์หนึ่งรายการก็สามารถแตะต้องข้อกำหนดหลายข้อพร้อมกันได้
เกณฑ์การยอมรับ (acceptance criterion) ทุกข้อใน spec คือการยืนยันพฤติกรรม (behavioral assertion) ซึ่งสอดคล้องกับรูปทรงของชุดทดสอบ (test case) อยู่แล้ว ทำให้เวิร์กโฟลว์แบบ Spec-Driven Development (SDD) ที่แข็งแกร่งสามารถสร้างชุดทดสอบจากเกณฑ์การยอมรับชุดเดียวกับที่สร้างโค้ด แทนที่จะให้ AI ต้องมาคิดค้นชุดทดสอบของตัวเองทีหลัง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น