การฝึกอบรมการตรวจสอบโค้ดที่สร้างโดย AI: วิธีสอนนักพัฒนาให้ตรวจสอบสิ่งที่แบบจำลองเขียนขึ้น

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

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

คู่มือนี้จัดทำขึ้นสำหรับหัวหน้าทีมพัฒนาศักยภาพด้านวิศวกรรมและผู้จัดการฝ่ายวิศวกรรม ครอบคลุมวิธีการอธิบายปัญหาด้านประสิทธิภาพ การวินิจฉัยช่องว่าง การออกแบบการเตรียมการและการฝึกฝน การดำเนินการตามกรณีศึกษา และการประเมินว่าทักษะที่ได้รับสามารถนำไปใช้ในการตรวจสอบจริงได้หรือไม่ เนื้อหาเกี่ยวกับการออกแบบการฝึกอบรม ข้อบกพร่อง การทดสอบ และกฎการตรวจสอบทุกข้อในโปรแกรมของคุณควรได้รับการตรวจสอบโดยวิศวกรอาวุโสและทีมรักษาความปลอดภัยของคุณ

การฝึกอบรมการตรวจสอบโค้ดที่สร้างโดย AI คืออะไร?

การฝึกอบรมการตรวจสอบโค้ดที่สร้างโดย AI สอนนักพัฒนาให้สั่งการผู้ช่วยอย่างชัดเจน จากนั้นประเมินและตรวจสอบสิ่งที่ได้รับกลับมา: ถูกต้องหรือไม่ ปลอดภัยหรือไม่ ทำงานได้ดีภายใต้ภาระงานพร้อมกันหรือไม่ มีประสิทธิภาพเพียงพอหรือไม่? นี่ไม่ใช่หลักสูตรเกี่ยวกับเครื่องมือเฉพาะใดเครื่องมือหนึ่ง แต่เป็นการฝึกฝนนิสัยการตรวจสอบที่คงเดิมแม้ว่าเครื่องมือจะเปลี่ยนไปก็ตาม

ข้อเท็จจริงด่วน

1. อธิบายปัญหาด้านประสิทธิภาพ

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

งานวิจัยชี้ให้เห็นถึงเหตุผลว่าทำไมจึงต้องมีการฝึกฝนอย่างตั้งใจ ในการศึกษาเกี่ยวกับ GitHub Copilot เพียร์ซและเพื่อนร่วมงานได้สร้างโปรแกรม 1,689 โปรแกรมใน 89 สถานการณ์ที่เลือกตามประเภทจุดอ่อนที่ทราบ และพบว่าประมาณ 40 เปอร์เซ็นต์ของโปรแกรมเหล่านั้นมีช่องโหว่ (เพียร์ซและคณะ, 2021นั่นเป็นเครื่องมือในยุคแรกและเป็นสถานการณ์เฉพาะ ดังนั้นอย่าถือว่าตัวเลขดังกล่าวเป็นอัตราสำหรับผู้ช่วยในปัจจุบัน การศึกษาผู้ใช้แยกต่างหากได้ขอให้ผู้เข้าร่วมเขียนโค้ดโดยมีและไม่มีผู้ช่วย AI ผู้ที่ใช้ผู้ช่วยเขียนโค้ดที่มีความปลอดภัยน้อยกว่าอย่างมีนัยสำคัญ และมีแนวโน้มที่จะเชื่อว่าโค้ดของตนปลอดภัยมากกว่า (เพอร์รีและคณะ, 2023จากการศึกษาเดียวกันพบว่า ผู้เข้าร่วมที่ไว้วางใจผู้ช่วยน้อยลงและมีส่วนร่วมกับคำแนะนำของผู้ช่วยมากขึ้น จะมีความเสี่ยงต่อการกระทำที่ผิดพลาดน้อยลง

ต่อไปนี้เป็นบทเรียนสองข้อสำหรับการออกแบบการฝึกอบรม ผลลัพธ์ที่น่าเชื่อถือจำเป็นต้องมีผู้ตรวจสอบอย่างแข็งขัน และความมั่นใจไม่ใช่หลักฐาน ดังนั้นแบบฝึกหัดจึงต้องขอให้มีการทดสอบ ไม่ใช่ความคิดเห็น

เขียนคำอธิบายผลการปฏิบัติงานในประโยคเดียว แล้วให้ผู้จัดการฝ่ายวิศวกรรมตรวจสอบ: "เมื่อได้รับการเปลี่ยนแปลงที่สร้างขึ้น นักพัฒนาจะระบุความเสี่ยงด้านความปลอดภัย การทำงานพร้อมกัน และประสิทธิภาพที่พวกเขาพบ และสำหรับแต่ละความเสี่ยง จะอธิบายหรือเขียนการทดสอบที่จะแสดงให้เห็นถึงความเสี่ยงนั้น"

2. วิเคราะห์ช่องว่างด้านการเรียนรู้และบริบท

ก่อนที่คุณจะเริ่มสร้างอะไรก็ตาม ให้เปรียบเทียบงานนั้นกับสิ่งที่โปรแกรมปัจจุบันของคุณปฏิบัติและประเมินอยู่ โดยปกติแล้วจะมีสามคำถามที่ช่วยแยกแยะช่องว่างในการฝึกอบรมออกจากสิ่งอื่น ๆ ได้แก่:

1. แนวทางปฏิบัติในปัจจุบันใช้โจทย์งานจริงหรือไม่? หากการฝึกอบรมครอบคลุมเฉพาะการเขียนคำสั่ง แต่ไม่เคยขอให้ผู้พัฒนาตรวจสอบผลลัพธ์ ก็เท่ากับว่าไม่มีใครได้ฝึกฝนการตรวจสอบเลย และหากการประเมินเป็นการทดสอบแบบเลือกตอบเกี่ยวกับกฎการเขียนโค้ดที่ปลอดภัย ก็เท่ากับว่านั่นเป็นการวัดความสามารถในการจดจำ
2. ความต้องการด้านการรับรู้คืออะไร? ในระบบการจัดระดับความสามารถของบลูมฉบับปรับปรุงใหม่ การตัดสินว่าโค้ดปลอดภัยหรือไม่และการเลือกการทดสอบที่พิสูจน์ความปลอดภัยนั้นอยู่ในระดับการวิเคราะห์และการประเมิน ในขณะที่การออกแบบคำแนะนำที่ดีขึ้นหรือการแก้ไขปัญหานั้นอยู่ในระดับการสร้าง การจับคู่กิจกรรมกับระดับเหล่านั้นมีอธิบายไว้ในคู่มือของเราแล้ว การจับคู่กิจกรรมการเรียนรู้กับอนุกรมวิธานของบลูม.
3. มีปัจจัยอื่นนอกเหนือจากทักษะที่เป็นอุปสรรคอยู่หรือไม่? ตรวจสอบเวลาในการตรวจสอบ เครื่องมือ และผู้รับผิดชอบ หากผู้ตรวจสอบมีเวลาห้านาทีต่อ pull request การฝึกอบรมใดๆ ก็จะไม่ทำให้เกิดการตรวจสอบ หากไม่มีการวิเคราะห์แบบคงที่หรือเครื่องมือทดสอบในขั้นตอนการพัฒนา นักพัฒนาอาจพบความเสี่ยง แต่ไม่สามารถพิสูจน์ได้ รายงานสาเหตุที่ไม่เกี่ยวข้องกับการฝึกอบรมไปยังผู้ที่สามารถแก้ไขได้

3. การเตรียมการออกแบบและการฝึกปฏิบัติ

เมื่อคุณทราบแล้วว่าการฝึกอบรมสามารถช่วยอุดช่องว่างใดได้บ้าง ให้กำหนดหน้าที่ที่ชัดเจนให้กับแต่ละขั้นตอน

การเตรียมการ. ตรวจสอบความรู้พื้นฐานด้วยการวิเคราะห์เบื้องต้น: ประเภทจุดอ่อนทั่วไปที่ระบบของคุณเผชิญ โครงสร้างการทดสอบของคุณ และรายการตรวจสอบการทบทวนที่ทีมของคุณใช้ การเรียนรู้ด้วยตนเองเหมาะสมกับขั้นตอนนี้ การตรวจสอบความจำจะยืนยันเฉพาะความรู้พื้นฐานเท่านั้น

การปฏิบัติ ใช้แบบฝึกหัดการตรวจสอบที่สร้างจากโค้ดที่สร้างขึ้นอย่างสมจริง ใส่ข้อบกพร่องจำนวนเล็กน้อยที่หลากหลายประเภทลงในแต่ละแบบฝึกหัด เช่น การขาดการตรวจสอบความเป็นเจ้าของ การแข่งขันระหว่างสองคำขอ และลูปที่ไม่มีประสิทธิภาพ รวมถึงโค้ดส่วนที่ทำงานได้ดี นักพัฒนาตรวจสอบ ระบุความเสี่ยงแต่ละข้อ บอกความร้ายแรง และเสนอวิธีการทดสอบที่จะแสดงให้เห็นถึงความเสี่ยงนั้น ขอเหตุผล ไม่ใช่แค่รายการหมายเลขบรรทัด

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

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

4. ลองทำตัวอย่างที่สมจริงดู

เป็นเพียงตัวอย่างเท่านั้น ผู้จัดการฝ่ายวิศวกรรมควรตรวจสอบความถูกต้องของกรณีศึกษาและเกณฑ์การตอบคำถามก่อนนำไปใช้

กรณี. เอนด์พอยต์ที่สร้างขึ้นจะส่งคืนใบแจ้งหนี้ของลูกค้าโดยใช้รหัสใบแจ้งหนี้ โดยจะตรวจสอบว่าผู้เรียกใช้มีเซสชันที่ถูกต้องหรือไม่ ใช้คำสั่งค้นหาแบบมีพารามิเตอร์ และผ่านการทดสอบพื้นฐาน ฟังก์ชันเดียวกันนี้ยังใช้เพิ่มตัวนับการดาวน์โหลดที่ใช้ร่วมกันโดยไม่ต้องล็อกอีกด้วย

ภารกิจนั้น ผู้พัฒนาได้ระบุความเสี่ยงแต่ละอย่างที่พวกเขาพบ จัดลำดับความสำคัญ และอธิบายวิธีการทดสอบที่จะยืนยันความเสี่ยงแต่ละอย่าง

เป็นการลองทำครั้งแรก "ดูเหมือนจะไม่มีปัญหา การค้นหาข้อมูลมีการกำหนดพารามิเตอร์ และการทดสอบผ่านแล้ว" นักพัฒนาซอฟต์แวร์ถือว่าการทดสอบผ่านแล้วเป็นหลักฐานยืนยัน และไม่ได้ถามว่าการทดสอบนั้นไม่ครอบคลุมอะไรบ้าง

ให้ข้อเสนอแนะและลองใหม่อีกครั้ง ผู้ตรวจสอบขอให้ผู้พัฒนาอธิบายว่าการตรวจสอบเซสชันพิสูจน์อะไรได้บ้าง และพิสูจน์อะไรไม่ได้บ้าง ส่วนการลองใหม่นั้นขอให้พิจารณาลูกค้าสองรายที่แตกต่างกัน และคำขอสองรายการที่เกิดขึ้นพร้อมกัน

ความพยายามที่หนักแน่นกว่าเดิม "การตรวจสอบเซสชันพิสูจน์ว่าใครกำลังโทรมา ไม่ใช่ว่าใบแจ้งหนี้เป็นของพวกเขา ฉันจะเขียนการทดสอบโดยให้ลูกค้า A ร้องขอหมายเลขใบแจ้งหนี้ของลูกค้า B และคาดว่าจะได้รับการปฏิเสธ ตัวนับจะเพิ่มขึ้นโดยไม่มีการซิงโครไนซ์ ดังนั้นการร้องขอสองครั้งพร้อมกันอาจทำให้พลาดการอัปเดต ฉันจะทำการทดสอบแบบพร้อมกันและเปรียบเทียบจำนวน การสืบค้นนั้นมีพารามิเตอร์ ดังนั้นฉันจะไม่เสียเวลาไปกับส่วนนั้น" โปรดสังเกตว่าคำตอบนี้จัดลำดับความเสี่ยงและเชื่อมโยงแต่ละความเสี่ยงกับการทดสอบ

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

5. ประเมินศักยภาพและวางแผนการถ่ายโอน

หลักฐานแสดงถึงความสามารถคือการปฏิบัติแบบฝึกหัดใหม่ที่ผู้เรียนไม่เคยเห็นมาก่อน การตรวจสอบคะแนนคุณภาพและการระบุข้อบกพร่องที่เกี่ยวข้อง เกณฑ์การประเมินอย่างง่ายใช้มาตราส่วน 0 ถึง 2 ต่อเกณฑ์:

เกณฑ์การให้คะแนน: 0 คือ ขาดหายไปหรือไม่ได้รับการสนับสนุน 1 คือ ขาดหายไปบางส่วนแต่มีรายละเอียดที่สำคัญ และ 2 คือ สมบูรณ์และมีเหตุผลรองรับตามเกณฑ์ที่ตกลงกันไว้ กำหนดข้อผิดพลาดที่สำคัญแยกต่างหาก เช่น การอนุมัติโค้ดที่มีเส้นทางการเข้าถึงที่ไม่ได้รับการป้องกัน เพื่อให้คะแนนโดยรวมไม่สามารถปกปิดข้อผิดพลาดนั้นได้ เกณฑ์การให้คะแนนนี้เป็นเพียงข้อเสนอแนะ ไม่ใช่มาตรฐานความพร้อมที่ได้รับการตรวจสอบแล้ว: ควรปรับปรุงโดยปรึกษากับผู้จัดการฝ่ายวิศวกรรมและทดลองใช้ก่อน ดูคำแนะนำของเราได้ที่... ออกแบบแบบฝึกหัดเชิงโต้ตอบพร้อมข้อเสนอแนะที่เป็นประโยชน์ แสดงวิธีการเขียนข้อเสนอแนะที่เชื่อมโยงกับการตัดสินใจ

วางแผนการถ่ายโอนงานอย่างรอบคอบ หลังจากเสร็จสิ้นแบบฝึกหัด ให้จับคู่ผู้พัฒนาแต่ละคนกับ pull request จริงที่มีโค้ดที่สร้างขึ้น และตรวจสอบสิ่งที่ค้นพบร่วมกัน หรือทำการทบทวนสั้นๆ เกี่ยวกับการตรวจสอบล่าสุดที่พลาดบางสิ่งไป

ในกรณีที่การนำเสนอแบบโต้ตอบมีประโยชน์

รูปแบบอินเทอร์แอคทีฟช่วยให้ทุกคนตกลงกันได้ก่อนที่จะเห็นภาพรวม ในเซสชันสด ผู้ดำเนินรายการสามารถแสดงตัวอย่างโค้ดที่สร้างขึ้น ถามนักพัฒนาแต่ละคนให้พิมพ์ความเสี่ยงที่พวกเขาเห็นและการทดสอบที่พวกเขาจะเขียน จากนั้นจึงเปิดเผยผลลัพธ์ก่อนการอภิปราย แบบฝึกหัดเดียวกันนี้สามารถทำได้ด้วยตนเองเพื่อเตรียมความพร้อม AhaSlides รองรับการเรียนรู้แบบอินเทอร์แอคทีฟและการสลับระหว่างการนำเสนอแบบสดและแบบเรียนรู้ด้วยตนเอง เป็นเครื่องมือสำหรับการนำเสนอและการเรียนรู้ ไม่ใช่สถานที่สำหรับรันโค้ด ดังนั้นให้รันแบบฝึกหัดเขียนโค้ดในสภาพแวดล้อมของคุณเอง ตรวจสอบฟังก์ชันการเขียน การให้ข้อเสนอแนะ หรือการรายงานเฉพาะใดๆ ที่คุณวางแผนจะใช้กับเวิร์กโฟลว์ของคุณเอง สำหรับคำแนะนำในการเลือกรูปแบบ โปรดดูบทความของเราเกี่ยวกับ เมื่อใดควรใช้การเรียนรู้แบบปรับเปลี่ยนได้ การเรียนรู้แบบโต้ตอบ และการเรียนรู้แบบสด.

วัดสิ่งที่เปลี่ยนแปลงไป

กำหนดล่วงหน้าว่าอะไรที่จะแสดงให้เห็นว่านักพัฒนาสามารถทำงานนั้นได้ เปรียบเทียบคุณภาพการตรวจสอบและการระบุข้อบกพร่องในแบบฝึกหัดที่ไม่เคยเห็นมาก่อนกับเกณฑ์มาตรฐาน กำหนดว่าใครบ้างที่เข้าร่วม ตัวหาร และช่วงเวลา หากผลลัพธ์ดีขึ้น ให้ตรวจสอบว่ามีอะไรเปลี่ยนแปลงไปบ้างในช่วงเวลาเดียวกัน เช่น กฎการวิเคราะห์แบบคงที่ใหม่ รายการตรวจสอบการตรวจสอบที่แก้ไข หรือการเปลี่ยนแปลงผู้ช่วย ก่อนที่จะให้เครดิตการฝึกอบรม

ข้อจำกัดที่อาจยังคงอยู่

• ถึงเวลาตรวจสอบแล้ว การตรวจสอบอย่างละเอียดใช้เวลานานกว่าการตรวจสอบแบบคร่าวๆ และกำหนดเวลาส่งงานก็ใกล้เคียงกับการตรวจสอบแบบคร่าวๆ มากกว่า
• เครื่องมือ หากไม่มีชุดทดสอบหรือการสแกนในขั้นตอนการพัฒนา ก็ยากที่จะพิสูจน์ความเสี่ยงได้
• เปลี่ยนเครื่องมือ ผู้ช่วยมักเปลี่ยนแปลงเร็ว ดังนั้นควรเน้นการฝึกฝนนิสัยการรีวิว ไม่ใช่แค่ผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่ง
• ความคุ้มครองตามคดี แบบฝึกหัดหนึ่งแสดงให้เห็นถึงข้อบกพร่องบางประเภท คะแนนไม่ได้บ่งบอกถึงวิจารณญาณของนักพัฒนาโดยทั่วไป
• โอน ประสิทธิภาพในการอบรมเชิงปฏิบัติการไม่เหมือนกับประสิทธิภาพในการทำงานในห้องตรวจงานที่วุ่นวาย

แจ้งปัญหาเหล่านี้ให้ผู้สนับสนุนทราบตั้งแต่เนิ่นๆ และวางแผนแก้ไขแยกต่างหาก การฝึกอบรมช่วยเพิ่มสิ่งที่นักพัฒนาสามารถค้นหาและพิสูจน์ได้ แต่ไม่ได้สร้างเวลาหรือเครื่องมือขึ้นมาใหม่

คำถามที่พบบ่อย

การฝึกอบรมการตรวจสอบโค้ดที่สร้างโดย AI คืออะไร?

มันสอนให้นักพัฒนาสามารถตั้งคำถาม ประเมิน และตรวจสอบโค้ดที่สร้างโดยผู้ช่วย AI เพื่อค้นหาปัญหาด้านความปลอดภัย การทำงานพร้อมกัน และประสิทธิภาพ และสนับสนุนแต่ละปัญหาด้วยการทดสอบ

โค้ดที่สร้างขึ้นโดยอัตโนมัติมีความปลอดภัยน้อยกว่าโค้ดที่เขียนโดยมนุษย์หรือไม่?

การศึกษาหลายชิ้นชี้ให้เห็นถึงความเสี่ยง แต่ผลลัพธ์ขึ้นอยู่กับเครื่องมือ งาน และการออกแบบการศึกษา การศึกษาผู้ใช้ชิ้นหนึ่งพบว่าผู้เข้าร่วมที่มีผู้ช่วยเขียนโค้ดที่มีความปลอดภัยน้อยลงและรู้สึกมั่นใจมากขึ้น ซึ่งเป็นเหตุผลหนึ่งที่ควรฝึกฝนนิสัยการตรวจสอบโค้ด

คุณประเมินอย่างไรว่านักพัฒนาสามารถตรวจสอบโค้ดที่สร้างขึ้นได้หรือไม่?

จัดทำแบบฝึกหัดการเขียนโค้ดใหม่และให้คะแนนคุณภาพการตรวจสอบและการระบุข้อบกพร่องตามเกณฑ์ที่ตกลงกันไว้ แบบทดสอบเกี่ยวกับกฎการเขียนโค้ดที่ปลอดภัยจะยืนยันความรู้พื้นฐานเท่านั้น

คุณต้องการสภาพแวดล้อมจำลองสำหรับการเขียนโค้ด (code sandbox) สำหรับการฝึกอบรมหรือไม่?

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

จะเริ่มที่ไหนดี

เลือกประเภทของการเปลี่ยนแปลงที่เกิดขึ้นซ้ำๆ ในโค้ดของคุณ เขียนคำอธิบายประสิทธิภาพ ให้ผู้จัดการฝ่ายวิศวกรรมตรวจสอบข้อบกพร่องที่กำหนดไว้และชุดทดสอบที่จะแสดงให้เห็นถึงข้อบกพร่องเหล่านั้น และร่างเกณฑ์การประเมินสามข้อโดยใช้มาตราส่วน 0 ถึง 2 พร้อมรายการข้อผิดพลาดที่สำคัญ ทดลองใช้กับกลุ่มเล็กๆ ก่อนที่จะนำไปใช้งานจริง

หากต้องการเรียนรู้วิธีการดำเนินการตรวจสอบจริงกับทีมของคุณเอง และนำกลับมาใช้ใหม่ได้ตามความต้องการของตนเอง โปรดสำรวจ AhaSlides