หน่วย
1. ความรู้เบื้องต้นเกี่ยวกับปัญญาประดิษฐ์และวินัยการตรวจสอบในสาขาวิศวกรรมคอมพิวเตอร์ 2. การวิเคราะห์ความต้องการและการออกแบบซอฟต์แวร์ 3. การเขียนโค้ดและการจับคู่การเขียนโปรแกรมด้วย AI 4. การทบทวนโค้ด การปรับโครงสร้างใหม่ และหนี้ทางเทคนิค 5. การดีบักและการแก้ไขปัญหา 6. ทดสอบระบบอัตโนมัติและการประกันคุณภาพ 7. โครงสร้างข้อมูล อัลกอริธึม และประสิทธิภาพ 8. ฐานข้อมูล SQL และการสร้างแบบจำลองข้อมูล 9. API สถาปัตยกรรมระบบ และคลาวด์ 10. รหัสที่ปลอดภัย การสร้างแบบจำลองภัยคุกคาม และการวิเคราะห์ช่องโหว่ 11. เอกสารประกอบ DevOps และ CI/CD อัตโนมัติ 12. ขอบเขต: ความปลอดภัย ความเป็นส่วนตัว ใบอนุญาต และจริยธรรม
หน่วย 4 / 12

การทบทวนโค้ด การปรับโครงสร้างใหม่ และหนี้ทางเทคนิค

กำไร:

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

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

ในหน่วยนี้ เราจะดูวิธีใช้ AI ในลักษณะที่มีโครงสร้างสำหรับการตรวจสอบโค้ด วิธีแก้ไขโค้ดที่ซับซ้อนโดยไม่ทำลายพฤติกรรม และวิธีการจัดการหนี้ด้านเทคนิค (การตัดสินใจเกี่ยวกับโค้ดที่รวดเร็วแต่มีค่าใช้จ่ายสูง)

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

การใช้ AI ในการตรวจสอบโค้ดที่มีโครงสร้าง

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

  1. ให้ขอบเขต. รหัสอะไร สิ่งที่ต้องทำ ในบริบทใดที่ใช้งานได้
  2. ระบุแกนลำดับความสำคัญ ความแม่นยำและความปลอดภัยต้องมาก่อน ความสามารถในการอ่านเป็นอันดับสอง
  3. ขอแก้ไขอย่างเป็นรูปธรรม “เหตุใดจึงเกิดปัญหา” และ “วิธีแก้ไขที่แนะนำ” สำหรับการค้นพบแต่ละครั้ง
  4. คุณตรวจสอบผลการวิจัย AI ยังสร้างผลบวกลวง; ตรวจสอบการค้นพบแต่ละครั้งกับโค้ดและการทดสอบ

พร้อมท์การตรวจสอบแบบมีโครงสร้าง: "ตรวจสอบฟังก์ชันต่อไปนี้เหมือนวิศวกรอาวุโส แสดงรายการสิ่งที่ค้นพบตามลำดับความสำคัญและทำเครื่องหมายด้วยแท็กเหล่านี้: ตรรกะ / ความปลอดภัย [สำคัญ], ตัวพิมพ์/ประสิทธิภาพของ Edge [ปานกลาง], ความสามารถในการอ่าน/ชื่อ [ต่ำ] สำหรับการค้นพบแต่ละครั้ง: ทำไมต้องถาม ข้อเสนอแนะในการแก้ไขอย่างเป็นรูปธรรม อย่าข้ามปัญหาการจัดรูปแบบ / การเยื้อง เครื่องมืออัตโนมัติจะจัดการมัน รหัส: [รหัส]"

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

ข้อควรระวัง: เพียงเพราะ AI บอกว่า "ไม่มีปัญหา" ไม่ใช่ข้อพิสูจน์ว่าไม่มีปัญหา AI สามารถสร้างผลลบลวงได้ สามารถหลีกเลี่ยงปัญหาด้านความปลอดภัยได้อย่างแท้จริง ส่วนเสริมการตรวจสอบ AI ไม่ใช่การแทนที่ การตรวจสอบโดยมนุษย์และการทดสอบความปลอดภัย ในโค้ดที่มีความสำคัญต่อความปลอดภัย วิศวกรผู้มีความสามารถจะเป็นผู้ตัดสินขั้นสุดท้าย

การรีแฟคเตอร์ที่เก็บรักษาไว้แบบทดสอบ

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

  1. นำพฤติกรรมปัจจุบันไปทดสอบ มิฉะนั้นให้ AI สร้าง “การทดสอบลักษณะเฉพาะ” (การทดสอบที่บันทึกพฤติกรรมปัจจุบันตามที่เป็นอยู่)
  2. แก้ไขด้วยขั้นตอนเล็กๆ การทดสอบจะต้องยังคงเป็นสีเขียวในทุกขั้นตอน
  3. เรียกใช้หลังจากแต่ละขั้นตอน จับการถดถอยตั้งแต่เนิ่นๆ

ข้อความแจ้งแผนการปรับโครงสร้างใหม่อย่างปลอดภัย: "ฟังก์ชัน 60 บรรทัดต่อไปนี้ทำงานมากเกินไปและอ่านยาก ฉันต้องการปรับโครงสร้างใหม่โดยไม่เปลี่ยนลักษณะการทำงาน ขั้นแรก: แสดงรายการกรณีการทดสอบใดที่ฉันต้องการเพื่อล็อคพฤติกรรมปัจจุบัน จากนั้น: แบ่งการปรับโครงสร้างใหม่เป็นขั้นตอนเล็ก ๆ ซึ่งแต่ละขั้นตอนสามารถดำเนินการได้ในขณะที่การทดสอบเป็นสีเขียว อย่าเพิ่งเขียนโค้ด ให้วางแผนก่อน รหัส: [รหัส]"

พรอมต์ที่อ่อนแอ / พรอมต์ที่แข็งแกร่ง

อ่อนแอ: "ทำให้โค้ดนี้ดีขึ้น" (ผลลัพธ์: ไม่ชัดเจนว่าต้องปรับปรุงอะไร AI ทำการเปลี่ยนแปลงตามอำเภอใจ สามารถเปลี่ยนพฤติกรรมได้อย่างเงียบๆ) แข็งแกร่ง: "สร้างฟังก์ชันการคำนวณการชำระเงินนี้ใหม่เพื่อให้อ่านง่าย ข้อจำกัด: พฤติกรรมจะต้องเหมือนเดิมทุกประการ ค่าที่ส่งคืนจะต้องไม่เปลี่ยนแปลง แยกฟังก์ชันแบบยาวออกเป็นฟังก์ชันอรรถประโยชน์ที่มีความหมาย เพิ่มตัวเลขมหัศจรรย์เป็นค่าคงที่ที่มีชื่อ แสดงรายการเปลี่ยนแปลงรายการตามรายการ และอธิบายว่าเหตุใดแต่ละรายการจึงไม่เปลี่ยนพฤติกรรม รหัส: [รหัส]"

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

การจัดการหนี้ทางเทคนิค

แนวทาง

ในระยะสั้น

ในระยะยาว

ละเลยหนี้

ความก้าวหน้าอย่างรวดเร็ว

การบำรุงรักษาเป็นอัมพาต ทีมชะลอตัวลง

เขียนใหม่ทุกอย่าง

การพัฒนาคุณสมบัติยืน

ผลตอบแทนไม่แน่นอน มีความเสี่ยงสูง

การปรับโครงสร้างใหม่ที่ได้รับการป้องกันโดยการทดสอบ

การชะลอตัวเล็กน้อย

ความเร็วที่ยั่งยืน

วิธีที่ดีต่อสุขภาพที่สุดคือวิธีที่สาม: ทำให้หนี้มองเห็นได้ (ติดตามไว้ในรายการ) เริ่มต้นที่จุดที่เจ็บปวดที่สุด และทดสอบการแก้ไขแต่ละรายการ AI เป็นตัวช่วยที่ดีในการระบุและจัดลำดับความสำคัญของรายการหนี้ แต่หนี้ที่ต้องจ่ายคือการตัดสินใจทางธุรกิจ

เคสมินิ

กรณีที่ 1 — การถดถอยแบบเงียบ นักพัฒนาบอกให้ AI "ลดความซับซ้อนของฟังก์ชันนี้"; AI แปลเงื่อนไขไม่ถูกต้องและการคำนวณคืนสินค้าเสียหาย เนื่องจากไม่มีการทดสอบ ข้อผิดพลาดจึงเกิดขึ้นหลังจากผ่านไป 3 สัปดาห์เมื่อมีการร้องเรียนจากลูกค้า ทีมงานทำงานเดียวกันโดยการเขียนการทดสอบการกำหนดลักษณะและตรวจพบข้อผิดพลาดด้วยการทดสอบสีแดงในการรันครั้งแรก

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

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

ข้อผิดพลาดทั่วไป

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

โดยสรุป

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

งานสมัคร

ใช้เส้น 40-70 ซึ่งเป็นฟังก์ชันที่ค่อนข้างซับซ้อนที่คุณมี (หรือให้ AI สร้าง) ขั้นแรกให้ปฏิบัติตามพรอมต์การทบทวนแบบมีโครงสร้าง และจัดเรียงผลการวิจัยเป็น [วิกฤต]/[ปานกลาง]/[ต่ำ]; ตรวจสอบการค้นพบอย่างน้อยหนึ่งรายการด้วยตนเองกับโค้ด จากนั้น เมื่อได้รับแจ้งเกี่ยวกับแผนการปรับโครงสร้างใหม่ที่ปลอดภัย ขั้นแรกให้สร้างและรันการทดสอบการกำหนดลักษณะ จากนั้นใช้การปรับโครงสร้างใหม่เป็นขั้นตอนเล็กๆ และตรวจสอบว่าการทดสอบยังคงเป็นสีเขียวในแต่ละขั้นตอน

รายการตรวจสอบ

  • [ ] ฉันจัดโครงสร้างการรีวิวด้วยแท็กลำดับความสำคัญ (วิจารณ์/ปานกลาง/ต่ำ)
  • [ ] ฉันได้ตรวจสอบการค้นพบ AI อย่างน้อยหนึ่งรายการโดยเทียบกับโค้ด/การทดสอบ
  • [ ] ฉันทดสอบพฤติกรรมปัจจุบันก่อนที่จะปรับโครงสร้างใหม่
  • [ ] ฉันทำการเปลี่ยนแปลงเป็นขั้นตอนเล็กๆ และทำการทดสอบในแต่ละขั้นตอน
  • [ ] ฉันระบุข้อจำกัด "พฤติกรรมต้องคงเหมือนเดิม" ในพรอมต์
  • [ ] ฉันขอยืนยันว่าการค้นพบด้านความปลอดภัยจำเป็นต้องมีการยืนยันจากมนุษย์