กำไร:
- ความสามารถในการใช้ AI เป็นตาที่สองในการตรวจสอบโค้ดเพื่อให้สามารถอ่านได้ ตรรกะ และความปลอดภัย
- ความสามารถในการวางแผนขั้นตอนการปรับโครงสร้างใหม่ด้วยการสนับสนุน AI โดยไม่รบกวนการทำงานของโค้ดที่ซับซ้อน
- ความสามารถในการตรวจสอบการตรวจสอบของ AI และแก้ไขคำแนะนำด้วยการทดสอบและการเปรียบเทียบการควบคุมเวอร์ชัน
ในด้านวิศวกรรมซอฟต์แวร์ รหัสจะถูกอ่านมากกว่าที่เขียนไว้มาก บรรทัดของโค้ดถูกเขียนเพียงครั้งเดียว แต่จะถูกอ่าน แก้ไข และสร้างจากหลายสิบครั้งในช่วงเวลาหลายเดือน นั่นเป็นเหตุผลว่าทำไมการตรวจสอบโค้ด (การตรวจสอบโค้ดของผู้อื่นหรือของคุณเองเพื่อหาตรรกะ ความสามารถในการอ่านได้ และการรักษาความปลอดภัย) และการปรับโครงสร้างใหม่ (การปรับปรุงโครงสร้างของโค้ดโดยไม่เปลี่ยนแปลงพฤติกรรม) ถือเป็นหัวใจสำคัญของวิศวกรรม AI กลายเป็น “ตาที่สอง” อันทรงพลังสำหรับงานทั้งสองนี้ โดยแนะนำความสามารถในการอ่านได้อย่างรวดเร็ว ชี้ให้เห็นปัญหาด้านตรรกะและความปลอดภัยที่ถูกมองข้าม และแบ่งการปรับโครงสร้างครั้งใหญ่เป็นขั้นตอนเล็กๆ ที่ปลอดภัย แต่มีกฎที่สำคัญอย่างหนึ่ง: การปรับโครงสร้างใหม่ไม่ควรเปลี่ยนพฤติกรรม และสิ่งเดียวที่รับประกันได้ว่าสิ่งนี้คือการทดสอบ
ในหน่วยนี้ เราจะดูวิธีใช้ AI ในลักษณะที่มีโครงสร้างสำหรับการตรวจสอบโค้ด วิธีแก้ไขโค้ดที่ซับซ้อนโดยไม่ทำลายพฤติกรรม และวิธีการจัดการหนี้ด้านเทคนิค (การตัดสินใจเกี่ยวกับโค้ดที่รวดเร็วแต่มีค่าใช้จ่ายสูง)
แนวคิด: หนี้ทางเทคนิค: การตัดสินใจเกี่ยวกับโค้ดที่ทำในวันนี้เพื่อความรวดเร็วที่ทำให้การบำรุงรักษาทำได้ยากในอนาคต กลิ่นโค้ด: รูปแบบที่ไม่ใช่ข้อผิดพลาดแต่บ่งบอกถึงปัญหา (ฟังก์ชันยาวเกินไป รหัสซ้ำ) การถดถอย: เมื่อการเปลี่ยนแปลงทำลายสิ่งที่เคยใช้ได้ผลก่อนหน้านี้
การใช้ AI ในการตรวจสอบโค้ดที่มีโครงสร้าง
เมื่อเวลามีจำกัด จำเป็นต้องมุ่งเน้นไปที่ประเด็นที่มีความเสี่ยงสูงสุด ตัวจัดรูปแบบอัตโนมัติจะจัดการกับปัญหาการจัดรูปแบบ เช่น การเยื้องและระยะห่าง คุณต้องให้ความสำคัญกับตรรกะ ความปลอดภัย และพฤติกรรมของ Edge Case เมื่อมีการตรวจสอบ AI ให้ขอรายการที่มีลำดับความสำคัญ ไม่ใช่การวิจารณ์แบบธรรมดา
- ให้ขอบเขต. รหัสอะไร สิ่งที่ต้องทำ ในบริบทใดที่ใช้งานได้
- ระบุแกนลำดับความสำคัญ ความแม่นยำและความปลอดภัยต้องมาก่อน ความสามารถในการอ่านเป็นอันดับสอง
- ขอแก้ไขอย่างเป็นรูปธรรม “เหตุใดจึงเกิดปัญหา” และ “วิธีแก้ไขที่แนะนำ” สำหรับการค้นพบแต่ละครั้ง
- คุณตรวจสอบผลการวิจัย AI ยังสร้างผลบวกลวง; ตรวจสอบการค้นพบแต่ละครั้งกับโค้ดและการทดสอบ
พร้อมท์การตรวจสอบแบบมีโครงสร้าง: "ตรวจสอบฟังก์ชันต่อไปนี้เหมือนวิศวกรอาวุโส แสดงรายการสิ่งที่ค้นพบตามลำดับความสำคัญและทำเครื่องหมายด้วยแท็กเหล่านี้: ตรรกะ / ความปลอดภัย [สำคัญ], ตัวพิมพ์/ประสิทธิภาพของ Edge [ปานกลาง], ความสามารถในการอ่าน/ชื่อ [ต่ำ] สำหรับการค้นพบแต่ละครั้ง: ทำไมต้องถาม ข้อเสนอแนะในการแก้ไขอย่างเป็นรูปธรรม อย่าข้ามปัญหาการจัดรูปแบบ / การเยื้อง เครื่องมืออัตโนมัติจะจัดการมัน รหัส: [รหัส]"
พร้อมท์การตรวจสอบที่เน้นความปลอดภัย: "ตรวจสอบรหัสนี้เพื่อความปลอดภัยเท่านั้น: ขาดการตรวจสอบอินพุต, ความเสี่ยงของการแทรกซึม, ขาดการควบคุมการอนุญาต, การรั่วไหลของข้อมูลที่เป็นความลับ, ค่าเริ่มต้นที่ไม่ปลอดภัย เพิ่มตัวอย่างสถานการณ์การโจมตีให้กับการค้นหาแต่ละครั้ง หากไม่มีปัญหาด้านความปลอดภัย ให้ระบุอย่างชัดเจนว่า 'ฉันไม่พบปัญหาด้านความปลอดภัยที่สำคัญ' รหัส: [รหัส]"
ข้อควรระวัง: เพียงเพราะ AI บอกว่า "ไม่มีปัญหา" ไม่ใช่ข้อพิสูจน์ว่าไม่มีปัญหา AI สามารถสร้างผลลบลวงได้ สามารถหลีกเลี่ยงปัญหาด้านความปลอดภัยได้อย่างแท้จริง ส่วนเสริมการตรวจสอบ AI ไม่ใช่การแทนที่ การตรวจสอบโดยมนุษย์และการทดสอบความปลอดภัย ในโค้ดที่มีความสำคัญต่อความปลอดภัย วิศวกรผู้มีความสามารถจะเป็นผู้ตัดสินขั้นสุดท้าย
การรีแฟคเตอร์ที่เก็บรักษาไว้แบบทดสอบ
กฎทองของการรีแฟคเตอร์: ทดสอบก่อน เปลี่ยนแปลงทีหลัง ก่อนที่จะแก้ไขโค้ด ควรมีการทดสอบที่จะล็อกพฤติกรรมปัจจุบัน เพื่อให้คุณทราบได้ทันทีหากการเปลี่ยนแปลงดังกล่าวทำให้บางสิ่งบางอย่างเสียหาย อย่าทำลายลำดับเมื่อมีการปรับโครงสร้าง AI
- นำพฤติกรรมปัจจุบันไปทดสอบ มิฉะนั้นให้ AI สร้าง “การทดสอบลักษณะเฉพาะ” (การทดสอบที่บันทึกพฤติกรรมปัจจุบันตามที่เป็นอยู่)
- แก้ไขด้วยขั้นตอนเล็กๆ การทดสอบจะต้องยังคงเป็นสีเขียวในทุกขั้นตอน
- เรียกใช้หลังจากแต่ละขั้นตอน จับการถดถอยตั้งแต่เนิ่นๆ
ข้อความแจ้งแผนการปรับโครงสร้างใหม่อย่างปลอดภัย: "ฟังก์ชัน 60 บรรทัดต่อไปนี้ทำงานมากเกินไปและอ่านยาก ฉันต้องการปรับโครงสร้างใหม่โดยไม่เปลี่ยนลักษณะการทำงาน ขั้นแรก: แสดงรายการกรณีการทดสอบใดที่ฉันต้องการเพื่อล็อคพฤติกรรมปัจจุบัน จากนั้น: แบ่งการปรับโครงสร้างใหม่เป็นขั้นตอนเล็ก ๆ ซึ่งแต่ละขั้นตอนสามารถดำเนินการได้ในขณะที่การทดสอบเป็นสีเขียว อย่าเพิ่งเขียนโค้ด ให้วางแผนก่อน รหัส: [รหัส]"
พรอมต์ที่อ่อนแอ / พรอมต์ที่แข็งแกร่ง
อ่อนแอ: "ทำให้โค้ดนี้ดีขึ้น" (ผลลัพธ์: ไม่ชัดเจนว่าต้องปรับปรุงอะไร AI ทำการเปลี่ยนแปลงตามอำเภอใจ สามารถเปลี่ยนพฤติกรรมได้อย่างเงียบๆ) แข็งแกร่ง: "สร้างฟังก์ชันการคำนวณการชำระเงินนี้ใหม่เพื่อให้อ่านง่าย ข้อจำกัด: พฤติกรรมจะต้องเหมือนเดิมทุกประการ ค่าที่ส่งคืนจะต้องไม่เปลี่ยนแปลง แยกฟังก์ชันแบบยาวออกเป็นฟังก์ชันอรรถประโยชน์ที่มีความหมาย เพิ่มตัวเลขมหัศจรรย์เป็นค่าคงที่ที่มีชื่อ แสดงรายการเปลี่ยนแปลงรายการตามรายการ และอธิบายว่าเหตุใดแต่ละรายการจึงไม่เปลี่ยนพฤติกรรม รหัส: [รหัส]"
ข้อความแจ้งที่มีประสิทธิภาพระบุอย่างชัดเจนถึงข้อจำกัด "พฤติกรรมจะต้องคงเหมือนเดิมทุกประการ" และสิ่งที่ต้องปรับปรุง หากไม่มีข้อจำกัดนี้ AI สามารถเปลี่ยนตรรกะในนามของ "การปรับปรุง" และสร้างการถดถอยแบบเงียบๆ ได้
การจัดการหนี้ทางเทคนิค
แนวทาง
ในระยะสั้น
ในระยะยาว
ละเลยหนี้
ความก้าวหน้าอย่างรวดเร็ว
การบำรุงรักษาเป็นอัมพาต ทีมชะลอตัวลง
เขียนใหม่ทุกอย่าง
การพัฒนาคุณสมบัติยืน
ผลตอบแทนไม่แน่นอน มีความเสี่ยงสูง
การปรับโครงสร้างใหม่ที่ได้รับการป้องกันโดยการทดสอบ
การชะลอตัวเล็กน้อย
ความเร็วที่ยั่งยืน
วิธีที่ดีต่อสุขภาพที่สุดคือวิธีที่สาม: ทำให้หนี้มองเห็นได้ (ติดตามไว้ในรายการ) เริ่มต้นที่จุดที่เจ็บปวดที่สุด และทดสอบการแก้ไขแต่ละรายการ AI เป็นตัวช่วยที่ดีในการระบุและจัดลำดับความสำคัญของรายการหนี้ แต่หนี้ที่ต้องจ่ายคือการตัดสินใจทางธุรกิจ
เคสมินิ
กรณีที่ 1 — การถดถอยแบบเงียบ นักพัฒนาบอกให้ AI "ลดความซับซ้อนของฟังก์ชันนี้"; AI แปลเงื่อนไขไม่ถูกต้องและการคำนวณคืนสินค้าเสียหาย เนื่องจากไม่มีการทดสอบ ข้อผิดพลาดจึงเกิดขึ้นหลังจากผ่านไป 3 สัปดาห์เมื่อมีการร้องเรียนจากลูกค้า ทีมงานทำงานเดียวกันโดยการเขียนการทดสอบการกำหนดลักษณะและตรวจพบข้อผิดพลาดด้วยการทดสอบสีแดงในการรันครั้งแรก
กรณีที่ 2 — ตาที่สองที่มีประโยชน์ ในการตรวจสอบโค้ด AI ตระหนักว่าการอนุญาตผู้ใช้นั้นได้รับการตรวจสอบในอินเทอร์เฟซเท่านั้น ไม่ใช่บนเซิร์ฟเวอร์ นี่เป็นช่องโหว่ในการเข้าถึงโดยไม่ได้รับอนุญาต วิศวกรเพิ่มการตรวจสอบการอนุญาตฝั่งเซิร์ฟเวอร์ การตรวจสอบ AI จะช่วยป้องกันเหตุการณ์ด้านความปลอดภัยที่เกิดขึ้นจริง
กรณีที่ 3 — ผลบวกลวง AI แจ้งว่า "ไม่เคยใช้ตัวแปรนี้ ลบออก"; อย่างไรก็ตาม มันถูกใช้โดยอ้อมผ่านกลไกการสะท้อนตัวแปร หากวิศวกรไม่ตรวจสอบข้อเสนอแนะกับการทดสอบ ข้อเสนอแนะนั้นจะถูกลบและเกิดข้อผิดพลาดรันไทม์ ทุกการค้นพบของ AI จะต้องได้รับการยืนยันก่อนนำไปใช้
ข้อผิดพลาดทั่วไป
- การรีแฟคเตอร์โดยไม่ต้องทดสอบ ไม่มีอะไรเหลือที่จะรักษาพฤติกรรมไว้ได้
- การใช้การค้นพบของ AI โดยไม่ตรวจสอบความถูกต้อง ผลบวกลวงและผลลบลวงเกิดขึ้นทั้งคู่
- เสียเวลาของมนุษย์กับปัญหารูปแบบ การมุ่งเน้นไปที่งานที่สามารถแก้ไขได้ด้วยเครื่องมืออัตโนมัติจะบดบังความเสี่ยงที่แท้จริง
- เอาคำตอบว่า "ไม่มีปัญหา" เป็นหลักประกัน AI สามารถหลีกเลี่ยงช่องโหว่ได้ จำเป็นต้องมีการตรวจสอบโดยเจ้าหน้าที่
- พยายามจะชำระหนี้ให้หมดในคราวเดียว การเขียนซ้ำครั้งใหญ่มีความเสี่ยง ขั้นตอนที่ถูกวัดและป้องกันโดยการทดสอบเป็นที่ต้องการ
โดยสรุป
การตรวจสอบโค้ดและการปรับโครงสร้างใหม่จะกำหนดอายุการใช้งานของโค้ด AI เป็นเครื่องมือสร้างแผนและตาที่สองที่ทรงพลัง: ให้การค้นพบที่มีการจัดลำดับความสำคัญ สถานการณ์ด้านความปลอดภัย และแผนการปรับโครงสร้างใหม่ขั้นตอนเล็กๆ แต่การปรับโครงสร้างใหม่ไม่ควรเปลี่ยนพฤติกรรม และมีเพียงการทดสอบเท่านั้นที่รับประกันสิ่งนี้ ตรวจสอบทุกการค้นพบของ AI โดยเทียบกับโค้ดและการทดสอบ อย่าเอาคำตอบว่า "ไม่มีปัญหา" มาเป็นหลักฐาน ทำให้มองเห็นหนี้ด้านเทคนิคและชำระหนี้ตามขั้นตอนที่วัดผลและได้รับการป้องกันจากการทดสอบ
งานสมัคร
ใช้เส้น 40-70 ซึ่งเป็นฟังก์ชันที่ค่อนข้างซับซ้อนที่คุณมี (หรือให้ AI สร้าง) ขั้นแรกให้ปฏิบัติตามพรอมต์การทบทวนแบบมีโครงสร้าง และจัดเรียงผลการวิจัยเป็น [วิกฤต]/[ปานกลาง]/[ต่ำ]; ตรวจสอบการค้นพบอย่างน้อยหนึ่งรายการด้วยตนเองกับโค้ด จากนั้น เมื่อได้รับแจ้งเกี่ยวกับแผนการปรับโครงสร้างใหม่ที่ปลอดภัย ขั้นแรกให้สร้างและรันการทดสอบการกำหนดลักษณะ จากนั้นใช้การปรับโครงสร้างใหม่เป็นขั้นตอนเล็กๆ และตรวจสอบว่าการทดสอบยังคงเป็นสีเขียวในแต่ละขั้นตอน
รายการตรวจสอบ
- [ ] ฉันจัดโครงสร้างการรีวิวด้วยแท็กลำดับความสำคัญ (วิจารณ์/ปานกลาง/ต่ำ)
- [ ] ฉันได้ตรวจสอบการค้นพบ AI อย่างน้อยหนึ่งรายการโดยเทียบกับโค้ด/การทดสอบ
- [ ] ฉันทดสอบพฤติกรรมปัจจุบันก่อนที่จะปรับโครงสร้างใหม่
- [ ] ฉันทำการเปลี่ยนแปลงเป็นขั้นตอนเล็กๆ และทำการทดสอบในแต่ละขั้นตอน
- [ ] ฉันระบุข้อจำกัด "พฤติกรรมต้องคงเหมือนเดิม" ในพรอมต์
- [ ] ฉันขอยืนยันว่าการค้นพบด้านความปลอดภัยจำเป็นต้องมีการยืนยันจากมนุษย์