คุณภาพซอฟต์แวร์ในตอนนี้ขึ้นอยู่กับข้อจำกัด (constraints) ที่คุณตั้งรอบๆ เอเจนต์ของคุณ
เกือบตลอดประวัติศาสตร์ของมนุษย์ เราประเมินคุณภาพโค้ดผ่าน การรีวิวโค้ด (code review): มีคนอ่านสิ่งที่คุณเขียนและคอยตรวจสอบว่ามันสะอาด รอบคอบ เร็ว เข้าใจง่าย และผ่านการทดสอบได้ดี สำหรับเอเจนต์แล้ว วิธีนั้นขยายขนาดได้ไม่ดีนัก เพราะมีโค้ดมากเกินกว่าที่ใครจะอ่านไหว ผลก็คือ การตรวจสอบคุณภาพของเรามากขึ้นเรื่อยๆ ต้องเกิดขึ้นที่ตัว harness สภาพแวดล้อม และระบบปฏิบัติการที่อยู่รอบๆ เอเจนต์ ผมยังคงอ่านและรีวิวโค้ดอยู่ แต่เลือกอย่างจงใจว่าจะให้ข้อจำกัดทำหน้าที่เป็นตัวตรวจสอบตรงจุดใดบ้าง
รายการของ Guillermo เป็นบททดสอบที่ดีว่าคุณพอจะข้ามการอ่านโค้ดได้หรือไม่ สังเกตว่า "ใช่" ทุกข้อจริงๆ แล้วคือการบอกว่าเดิมพันต่ำแค่ไหน - ไม่มีผู้ใช้ โค้ดที่ใช้แล้วทิ้ง โปรโตไทป์ พอเดิมพันสูงขึ้น ก็ต้องมีอะไรสักอย่างอ่านโค้ด ถ้าไม่ใช่คุณในทุกๆ diff ก็ต้องเป็นข้อจำกัด
ข้อจำกัดกำหนดว่าระบบได้รับอนุญาตให้ทำอะไรได้บ้าง ด้วยการยิงเทสต์และข้อจำกัดเชิงกำหนด (deterministic constraints) ใส่ข้อเสนอของเอเจนต์ การตั้งและรักษาข้อจำกัดเหล่านี้ต่างหาก ที่ทำให้เราสร้างลูปซึ่งส่งมอบซอฟต์แวร์คุณภาพสูงระดับ production ได้อย่างน่าเชื่อถือ แม้เอเจนต์จะสร้างการเปลี่ยนแปลงเป็นแสนหรือเป็นล้านรายการในทุกๆ วัน
เราเรียกข้อจำกัดเหล่านี้ว่า quality gates และพวกมันมีหลายรูปแบบ
มันรวมถึง unit tests, property tests และ acceptance tests ทั่วไป รวมถึง mutation testing ที่เราสร้างโค้ดหลายรูปแบบ รันมันกับเทสต์ชุดเดียวกัน และทำให้แน่ใจว่าไม่มีใครลักลอบใส่บั๊กที่เรามองไม่เห็นเข้ามา และยังรวมถึงเมตริกวัดคุณภาพโค้ด อย่าง cyclomatic complexity และความยาวบรรทัด ที่ช่วยให้โค้ดอ่านง่ายอยู่เสมอ
คนสองคนอาจไม่เห็นพ้องกันว่าจะอ่านโค้ดหรือไม่ แต่ยังเห็นพ้องกันในเรื่องกลไก Guillermo อ่านโค้ด Bob ไม่อ่านเลย ทั้งคู่กำลังอธิบายด่านทดสอบ (gauntlet) - ต่างกันแค่ว่ามนุษย์จะอยู่ข้างในด่านนั้นหรือไม่ (ผมไม่สนับสนุนความเห็นอื่นๆ ของ Bob นะ)
ข้อจำกัดยังมีบทบาทสำคัญในการตัดสินว่าระบบจะยอมรับข้อเสนอใดและนำไปใช้เป็นการเปลี่ยนแปลงโค้ด เมื่อข้อเสนอการเปลี่ยนแปลงย้ายจาก interpreter ที่รันเอเจนต์ไปยังตัวควบคุมเอเจนต์ (agent controller) แล้วออกสู่ production เราก็ได้ตรวจสอบมันมากพอที่จะมั่นใจว่าปลอดภัยพอจะส่งออกได้ และผลกระทบของการเปลี่ยนแปลงนั้นอยู่ในขอบเขตของเอเจนต์เป็นอย่างดี
เอเจนต์เสนออะไรก็ได้ ข้อจำกัดของคุณต่างหากที่ตัดสินว่าข้อเสนอหนึ่งๆ ปลอดภัยพอ ถูกต้อง มีขอบเขต และมีประโยชน์พอสำหรับคุณและทีมที่จะส่งออก
โมเดลนี้ให้อะไรเยอะ แต่ก็ละทิ้งหลายส่วนไว้ และส่วนที่ขาดหายเหล่านั้นก็ควรค่าแก่การคิดถึงในวันนี้ ปัญหาหนึ่งคือ ความเป็นอิสระ (autonomy); เอเจนต์อาจดำเนินการตามความตั้งใจได้ดี แต่ก็อาจล้มเหลวเมื่อข้อมูลไม่ครบ หรือเมื่อสิ่งที่มันพยายามทำมีความคลุมเครือ ซึ่งใช้ได้ทั้งกับตัวงานเอง และกับวิธีที่งานถูกกำหนดพารามิเตอร์โดย harness สภาพแวดล้อม และส่วนประกอบอื่นๆ
หลายเหตุผลที่มนุษย์ไม่สามารถส่งมอบโค้ดดีๆ ได้ ก็เป็นเหตุผลเดียวกันกับสิ่งที่เอเจนต์อาจทำ: สภาพแวดล้อมที่เปราะบางซึ่งรับแรงกดดันจากการรันด้วยสคริปต์ไม่ได้ การ build ที่ผลลัพธ์ไม่แน่นอน (nondeterministic) สิทธิ์ที่ขาดหาย และเทสต์ที่อ่อนแอ สิ่งเหล่านี้ผลักดันให้เราสร้างสภาพแวดล้อมที่ดีขึ้น ซึ่งให้ข้อเสนอแนะที่เอเจนต์เชื่อถือได้ รองรับรูปแบบความล้มเหลวที่สร้างความเสียหายต่ำ และทำให้การค่อยๆ สร้างความสำเร็จเป็นเรื่องง่ายขึ้น
สภาพแวดล้อมที่เราตามหาคือสภาพแวดล้อมที่เอเจนต์ทำงานจริงได้ ได้รับข้อเสนอแนะที่เชื่อถือได้ และล้มเหลวได้โดยไม่สร้างความเสียหายมากนัก
อีกประเด็นสำคัญคือความไว้วางใจ เราไม่สามารถมอบความตั้งใจ (intent) ให้กับอะไรก็ตามอย่างง่ายดาย โดยไม่ตรวจสอบความถูกต้อง แม้มันจะฉลาดและแกร่งอย่างเอเจนต์ยุคใหม่ก็ตาม เราเริ่มต้นด้วยความไว้วางใจ แต่มันต้องถูกพิสูจน์อย่างหนัก
ข้อจำกัดบางอย่างกำหนดรูปแบบงานก่อนที่มันจะเริ่ม บางอย่างให้ข้อเสนอแนะระหว่างที่เอเจนต์กำลังทำงาน และบางอย่างตัดสินว่าผลลัพธ์ของมันจะข้ามเขตแดนของ production ได้หรือไม่
มีหลายวิธีในการจำลองว่าเราจะวางโครงสร้างการตรวจสอบรอบๆ ระบบได้อย่างไร
จากประสบการณ์ของผม การมีชุดตรวจสอบที่กว้างขึ้นแต่คัดสรรมาอย่างตั้งใจ สำหรับข้อจำกัดของคุณ ช่วยได้มากกว่าการพึ่งพาแค่ unit tests เพียงอย่างเดียว แนวคิดคือการตรวจสอบแต่ละอย่างมีความรับผิดชอบที่แตกต่างกัน ซึ่งอาจมีตั้งแต่ type safety และ performance ไปจนถึงการสแกนความปลอดภัยในช่วงท้าย ผู้คนยังสามารถกำหนดข้อจำกัดของตัวเองได้เช่นกัน รวมถึงกฎสถาปัตยกรรมที่เครื่องมือ lint อย่าง ESLint บังคับใช้ได้ เครื่องมือหลายตัวเหล่านี้มี hooks ในตัวที่ใช้ดึงเอเจนต์หรือมนุษย์เข้ามาได้เมื่อมีอะไรพัง
ในตอนนี้ ความแตกต่างระหว่างผลลัพธ์ที่มีประโยชน์จากเอเจนต์กับขยะ (slop) ส่วนใหญ่ยังคงขึ้นอยู่กับฝีมือของทีมที่เดินลูปอยู่
AI ทำให้เราสร้างโค้ดได้ปริมาณมากและรวดเร็ว แต่นั่นก็หมายความว่ามนุษย์จะรีวิวทุกการเปลี่ยนแปลงได้ยากขึ้น คุณต้องตั้งใจกำหนดแทนว่าความสนใจของมนุษย์จะไปอยู่ตรงไหน ถ้าคุณเอามนุษย์ไปแทรกในระบบที่เคลื่อนที่ด้วยความเร็วเครื่องจักร ก็อย่าแปลกใจถ้ามันกระทบประสิทธิภาพการทำงาน ความสนใจของมนุษย์นั้นหายากและมีค่า เราจึงควรนำมันไปใช้กับปัญหาที่ละเอียดอ่อนที่สุดซึ่งต้องใช้ดุลยพินิจของเราอย่างตั้งใจ มนุษย์ในขั้นถัดไปควรถูกดึงเข้ามาเฉพาะเมื่อการ์ดป้องกันอัตโนมัติของข้อจำกัดพังลงเท่านั้น
"การรีวิวโค้ด" ของมนุษย์ในอนาคตจะมีหน้าตาที่แตกต่างไปจากเดิมมาก
ความถูกต้องเป็นมิติสำคัญหนึ่ง แต่คุณอาจใส่ใจมิติอื่นๆ ด้วย เช่น ความสามารถในการบำรุงรักษา (maintainability) ประสิทธิภาพ (performance) ความปลอดภัย (security) ความมีประสิทธิภาพ (efficiency) และความเข้าใจง่าย (comprehensibility) เช่นเดียวกับที่ความถูกต้องแตกออกเป็นสัญญาณหลายประเภท คุณภาพส่วนที่เหลือก็เช่นกัน และแม้จำนวนข้อจำกัดที่เรามีจะสำคัญ แต่สิ่งที่สำคัญยิ่งกว่าคือข้อจำกัดเหล่านั้นท้าทายพอที่จะผ่านเกณฑ์คุณภาพและความพร้อมผลิต (production readiness) ของเราหรือไม่
คุณภาพซอฟต์แวร์ไม่ใช่เมตริกเดียว มองมันเป็นชุดสัญญาณที่มีความสำคัญต่อคุณและทีมในระดับที่แตกต่างกัน
Back-pressure (แรงดันย้อนกลับ) สามารถนำไปปฏิบัติได้ผ่านเครื่องมือหลายอย่าง: compiler ที่ปฏิเสธโค้ดที่ไม่ถูกต้อง เทสต์ที่ล้มเหลว นโยบายความปลอดภัยที่บล็อกแนวปฏิบัติที่ไม่ดี และ CI ที่ปฏิเสธการ deploy ในอุดมคติแล้ว มันควรมีอยู่ตลอดทั้งลูป ไม่ใช่เป็นการรีวิวครั้งเดียวที่ปลายทางของงานทั้งหมด
แผนที่ของ Dex Horthy สำหรับลูปเดียวกัน จากบทความ Why Software Factories Fail กล่องสีเขียวคือข้อโต้แย้งของเขาที่ว่า ตอนนี้การรีวิวของมนุษย์ควรกลับเข้ามาอยู่ในลูป ไม่ใช่ถูกแทนที่ด้วยมัน
ข้อจำกัดและ back-pressure ช่วยให้เอเจนต์จับงานที่แย่ได้ก่อนที่มันจะกลายเป็นปัญหา
จะเกิดอะไรขึ้นถ้าเราใช้ข้อจำกัดไม่ได้ เพราะปริมาณการเปลี่ยนแปลงสูงกว่าที่เครื่องมือของเราจะรองรับไหว? เราก็จะลงเอยด้วยการสร้างคิวและพึ่งพาระบบตรวจสอบที่ทำงานด้วยความเร็วของมนุษย์ เพื่อการขยายขนาด เราต้องการผลักดันให้มากที่สุดเท่าที่จะทำได้เข้าสู่ลูปการตรวจสอบตลอดกระบวนการ ไม่ใช่รอจนถึงตอนจบ ถ้าเราสามารถขยายขนาดได้ภายในการตรวจสอบอัตโนมัติ เราก็จะเพิ่มความเร็วและปริมาณงาน (throughput) ของระบบส่งมอบทั้งหมดได้ แต่ถ้าเราหมดพื้นที่ในลูปการตรวจสอบ เราจำเป็นต้องทำอย่างใดอย่างหนึ่งจากหลายทางเลือก
อย่างแรก เราสามารถขยายระบบตรวจสอบและสร้างความจุเพิ่มขึ้นเพื่อคุมและผลักดันกลับการเปลี่ยนแปลงที่เข้ามา อย่างที่สอง เราสามารถลดอัตราที่เอเจนต์สร้างการเปลี่ยนแปลงใหม่ เพื่อให้การตรวจสอบตามทันปริมาณงาน อย่างที่สาม เราสามารถลดเกณฑ์คุณภาพลง เพื่อให้การตรวจสอบไม่ผลักดันกลับแรงเท่าที่มันควรจะเป็น จากมุมมองของการขยายขนาด เราต้องพร้อมที่จะทำทั้งหมดนี้ ในขณะเดียวกัน เราก็ไม่ควรมองข้ามความจริงที่ว่าเราอาจทำอะไรได้มากขึ้นด้วยการปลดข้อจำกัดในบางทิศทาง บางทีเราอาจเพิ่มความเร็วของการเปลี่ยนแปลงที่เอเจนต์สร้างขึ้น ด้วยการจัดหาฝูงนักพัฒนาเอเจนต์ (swarms of agent developers) หรือโรงงานซอฟต์แวร์อัตโนมัติ เพื่อสร้างการเปลี่ยนแปลงโดยไม่ต้องรอให้เรารีวิวทุกอัน
และในบางจุด เราอาจอยากให้อิสระกับพวกเขามากขึ้น ตราบใดที่เราคงข้อจำกัดที่เข้มงวดกว่าในจุดอื่น ด้วยการตั้งข้อจำกัดที่เข้มงวดขึ้นในจุดที่เราใส่ใจมากที่สุด เราจะเพิ่มปริมาณงาน (throughput) ได้สูงสุดโดยไม่เสียสละคุณภาพ ตลอดการตัดสินใจเหล่านี้ มีตัวเลือกมากมาย ที่ชัดเจนที่สุดคือ เราต้องแลกเปลี่ยนระหว่างมิติคุณภาพที่แตกต่างกัน ดังที่เราได้เน้นย้ำ ความปลอดภัยสำคัญมาก แต่เราก็ต้องแลกระหว่างการส่งมอบความปลอดภัยกับการส่งมอบผลิตภัณฑ์ให้ทันเวลา มีสเปกตรัมตั้งแต่มุ่งเน้นนวัตกรรมที่ปลายด้านหนึ่งไปจนถึงมุ่งเน้นคุณภาพที่อีกด้านหนึ่ง ที่ไหนสักแห่งระหว่างทาง เราต้องเลือกว่าเราอยากอยู่ตรงไหนบนสเปกตรัมนั้น
เราต้องการส่งข้อเสนอแนะที่ชัดเจนจากสภาพแวดล้อมและระบบกลับไปยังเอเจนต์หรือทีมของเรา เพื่อให้ผู้คนมุ่งเน้นกับเรื่องที่เป็นอัตวิสัยมากกว่า อย่างรสนิยม เจตนา และสถาปัตยกรรม ถ้าเราช่วยให้มนุษย์อยู่ในช่วงที่ปลอดภัยของข้อจำกัดได้ เราก็จะไม่ต้องให้พวกเขาทำงานหนักเพื่อพยายามหาว่าอะไรผิดพลาดไปที่ไหน
คุณภาพซอฟต์แวร์มีมากกว่าแค่ความถูกต้อง คุณภาพซอฟต์แวร์ยังหมายถึงความสามารถในการบำรุงรักษา ประสิทธิภาพที่ดี ความปลอดภัย ความมีประสิทธิภาพ และความเข้าใจง่าย ข้อจำกัดทั้งหมดที่ช่วยให้เราบรรลุมาตรฐานเหล่านี้และรักษาระบบ production ให้ไหลลื่น ต่างสร้าง back-pressure ในไปป์ไลน์การส่งมอบของเรา
เราต้องตัดสินใจอย่างรอบคอบว่าจะใช้ข้อจำกัดที่เข้มงวดตรงไหน และจะถอดหรือผ่อนคลายมันตรงไหน ใช้ข้อจำกัดที่เข้มงวดในจุดที่มันตอบสนองเป้าหมายทั้งสองข้อนี้ อย่าหนุนมันถ้ามันไม่ตอบสนองข้อใดข้อหนึ่งหรือทั้งสองข้อ เตรียมพร้อมที่จะยกระดับหรือลดมาตรฐานตามสถานการณ์ และจำไว้ว่าข้อจำกัดเหล่านี้ ณ จุดต่างๆ ในระบบซอฟต์แวร์ คือสิ่งที่ทำให้คุณภาพซอฟต์แวร์บังคับใช้ได้จริง
เราควรใช้ข้อจำกัดที่เข้มงวดในจุดที่มันตอบสนองวัตถุประสงค์คู่นี้ได้ดีที่สุด และพิจารณาถอดหรือผ่อนคลายข้อจำกัดที่ไม่ได้ตอบสนองวัตถุประสงค์ใดดีนัก เราควรพร้อมที่จะเลื่อนเกณฑ์คุณภาพขึ้นหรือลงตามความจำเป็น อันที่จริง ข้อจำกัดเหล่านี้ ณ จุดต่างๆ ในระบบซอฟต์แวร์ของเรา คือสิ่งที่ทำให้คุณภาพมีผลบังคับใช้จริง ในหลายกรณี เราสามารถสร้าง back-pressure และข้อจำกัดได้มากขึ้นด้วยการติดตั้งเครื่องมือใหม่หรือเสริมความแข็งแกร่งให้เครื่องมือที่มีอยู่แล้ว สิ่งเหล่านี้ทั้งหมดสามารถใช้ผลักดันกลับคำขอเปลี่ยนแปลงส่วนใหญ่ได้ เราต้องการสร้างมันให้ทั่วทั้งไปป์ไลน์
เราไม่ต้องการรอจนถึงปลายไปป์ไลน์ เมื่อระบบ CI ของเราจะบอกเราว่าเราไม่ได้รับอนุญาตให้ deploy โดยไม่แก้ปัญหาก่อน เราต้องการใช้สัญญาณเหล่านี้ให้เร็วที่สุดเท่าที่จะทำได้ ผ่านทุกเส้นทางที่เป็นไปได้ ข้อจำกัดสูงสุดในระบบนี้คือข้อจำกัดที่เราวางไว้กับตัวเอง ในการยืนหยัดอยู่เบื้องหลังการตัดสินใจและการกระทำที่เราทำเพื่อสร้างระบบและเดินระบบมัน แต่เช่นเดียวกับข้อจำกัดอื่นๆ ทั้งหมด เราต้องแลกเปลี่ยนอย่างรอบคอบว่าเราต้องการให้ดุลยพินิจของเราเองคอยควบคุม สร้าง back-pressure และทำหน้าที่เป็นด่านตรวจสุดท้ายมากแค่ไหน
คุณภาพอยู่ในข้อจำกัดที่เราวางรอบๆ เอเจนต์ของเรา ดังนั้น เวลาที่คุณคิดเรื่องคุณภาพให้แอปของคุณเอง จงนำคำกล่าวของปัญหานี้ไป และสร้างแผนที่ขับเคลื่อนด้วยข้อจำกัดของคุณเอง
พูดถึงเรื่องคุณภาพ เอเจนต์กำลังเขียนโค้ดให้คุณอยู่ [Sonar](https://fandf.co/45bRKE8) มอบ quality gates ที่ทำให้โค้ดของคุณส่งออกได้จริง มันรันการตรวจสอบแบบครบชุดเดียวกันทุก commit: วิเคราะห์เชิงลึกข้ามไฟล์ แผนที่ระบุว่าความเสี่ยงอยู่ตรงไหน และ quality gate ที่ทำให้มนุษย์และเอเจนต์ทุกคนต้องได้มาตรฐานเดียวกัน
บทความนี้ได้รับการจัดอันดับว่า มนุษย์เขียน 100% โดย Pangram 4
