การอ่านโค้ด คำอธิบาย และความเข้ากันได้กับฐานโค้ดใหม่

กำไร:

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

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

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

ทำไม Code Annotation ถึงมีประสิทธิภาพแต่มีความเสี่ยง?

LLM เก่งมากในการอ่านโค้ดและแปลเป็นภาษามนุษย์ เช่น "ฟังก์ชันนี้จะรีเฟรชโทเค็นเซสชันของผู้ใช้"; เพราะมันได้เรียนรู้รูปแบบจากตัวอย่างที่คล้ายกันนับล้านตัวอย่าง นี่เป็นการประหยัดเวลาได้มาก โดยเฉพาะอย่างยิ่งกับฟังก์ชันที่ยาวและซ้อนกัน

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

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

ขั้นตอนในการแมปฐานรหัสต่างประเทศ

1. เริ่มต้นที่ระดับบนสุด ขั้นแรก ทำความคุ้นเคยกับโครงสร้างโฟลเดอร์และจุดเข้าใช้ (หลัก การเปิดใช้แอปพลิเคชัน เราเตอร์ที่บ้าน) ถาม AI ​​ว่า "เลเยอร์ของแอปพลิเคชันตามโครงสร้างไดเรกทอรีนี้คืออะไร" ถาม.
2. ติดตามคุณลักษณะตั้งแต่ต้นจนจบ "ไฟล์ใดบ้างที่เปิดใช้งานและลำดับใดเมื่อผู้ใช้เข้าสู่ระบบ" — การดูโฟลว์เดียวให้ความรู้มากกว่าการอ่านสถาปัตยกรรมทั้งหมด
3. แปลคำศัพท์ ถาม AI เกี่ยวกับแนวคิดเฉพาะโครงการ ("ผู้เช่า", "บัญชีแยกประเภท", "ผู้ดำเนินการงาน") และค้นหาแนวคิดที่เทียบเท่ากันในโค้ด
4. คุณทำให้ฟังก์ชันที่ซับซ้อนง่ายขึ้น ให้อธิบายฟังก์ชันแบบยาวทีละขั้นตอน จากนั้นทำเครื่องหมายขั้นตอนเหล่านั้นในโค้ด
5. ตรวจสอบ. ทำการเปลี่ยนแปลงเล็กน้อยและทำการทดสอบเพื่อทดสอบความเข้าใจของคุณ การทดสอบจะบอกคุณทันทีหากความเข้าใจของคุณผิด

มินิเคสสามอัน

กรณีที่ 1 — บริการที่สืบทอดมาลดลงจาก 2 วันเหลือ 3 ชั่วโมง นักพัฒนาเข้ารับบริการกระทบยอดการชำระเงิน 4,000 บรรทัดจากเพื่อนร่วมงานที่ลาออก มี AI สรุปโมดูลและติดตามขั้นตอนการชำระเงินตั้งแต่ต้นทางถึงปลายทาง เขาตรวจสอบฟังก์ชันสำคัญสองฟังก์ชันในโค้ดเป็นการส่วนตัว การค้นพบนี้คาดว่าจะใช้เวลา 2 วันสำหรับ "การอ่านแบบตาบอด" แบบคลาสสิก และเสร็จสิ้นในเวลาประมาณ 3 ชั่วโมงด้วยวิธี AI ที่ได้รับการยืนยัน

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

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

เทมเพลตที่คัดลอกได้สี่แบบ

การแมปโค้ดเบส:

ด้านล่างนี้คือรายการไดเร็กทอรี/ไฟล์ของโครงการ 1) แยกเลเยอร์ของแอปพลิเคชัน (อินพุต ตรรกะทางธุรกิจ การเข้าถึงข้อมูล ฯลฯ) 2) แสดงรายการการเดินทางของไฟล์ที่เป็นไปได้ของคำขอ "{{example property}}" 3) ทำเครื่องหมายพื้นที่ที่คุณไม่แน่ใจว่า "ต้องได้รับการยืนยัน" {{ไดเรกทอรี_รายการ}}

คำอธิบายฟังก์ชั่น (ทีละขั้นตอน):

แบ่งฟังก์ชันนี้ออกเป็นกลุ่มแถวและอธิบายเป็นภาษาตุรกีว่าแต่ละกลุ่มทำอะไร สุดท้าย: รายการอินพุต เอาต์พุต ผลข้างเคียง (ฐานข้อมูล/ไฟล์/เครือข่าย) และกรณีขอบที่เป็นไปได้ รวบรวมพฤติกรรมที่คุณไม่แน่ใจภายใต้หัวข้อ "ต้องตรวจสอบ" แยกต่างหาก{{function}}

การติดตามการไหลของข้อมูล:

ค่า "{{variable/data}}" มาจากไหน ต้องผ่านการแปลงแบบใดบ้าง เขียนไว้ที่ไหน สร้างโฟลว์เชนโดยใช้ชื่อฟังก์ชันในโค้ด รหัสที่เกี่ยวข้อง: {{code_segments}}

เรียนรู้วิธีการใช้ห้องสมุด:

ฉันต้องการสร้าง {{Purpose}} ด้วย {{library}} ยกตัวอย่างการทำงานขั้นต่ำ ตรวจสอบให้แน่ใจว่าทุกฟังก์ชันที่คุณใช้เป็นของไลบรารีนี้จริงๆ หากคุณไม่แน่ใจ ให้ทำเครื่องหมายที่ "ยืนยันจากเอกสารอย่างเป็นทางการ" เวอร์ชัน: {{เวอร์ชัน}}

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

อ่อนแอ: "อธิบายรหัสนี้" (สงสัยอะไร อยู่ระดับไหน จะทำอะไร)

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

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

ภารกิจ

เอไอทำได้ดี

อย่าลืมตรวจสอบ

สรุปสถาปัตยกรรมทั่วไป

ลบเลเยอร์

ลำดับการโทรจริง

ฟังก์ชั่นที่ซับซ้อน

คำอธิบายทีละขั้นตอน

ตรรกะย้อนกลับ ผลข้างเคียง

สตรีมข้อมูล

ร่างห่วงโซ่

สาขาที่มีเงื่อนไขข้ามเส้นทาง

การใช้ห้องสมุด

การสร้างตัวอย่าง

ความถูกต้องและเวอร์ชันของ API

ไม่มีการทดแทนความเข้าใจของมนุษย์

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

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

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

• พิจารณาสรุปไว้เป็นหลักฐาน การตัดสินใจเกี่ยวกับโค้ดโดยไม่ตรวจสอบคำอธิบายหมายถึงการติดกับดักของชื่อที่ทำให้เข้าใจผิด
• ติดกาวชิ้นใหญ่เกินไป การสรุป 2,000 บรรทัดในคราวเดียวจะให้ผลลัพธ์แบบผิวเผินและเกิดข้อผิดพลาดได้ง่าย แบ่งออกเป็นชิ้น ๆ
• ไม่ระบุจุดประสงค์. หากคุณไม่พูดว่า "สิ่งที่คุณจะทำ" คำอธิบายจะยังคงเป็นคำอธิบายทั่วไปและไม่เน้นที่ธุรกิจของคุณ
• ไม่ตรวจสอบอินสแตนซ์ไลบรารี โมเดลอาจเรียก API ที่ล้าสมัยหรือไม่มีอยู่จริง เปรียบเทียบกับเอกสารราชการ
• มอบการเรียนรู้ทั้งหมดออกไป การทำงานเฉพาะกับบทคัดย่อโดยไม่เคยอ่านโค้ดฐานจะทำให้คุณทำอะไรไม่ถูกเมื่อเกิดข้อผิดพลาดจริงครั้งแรก

โดยสรุป

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

งานสมัคร

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

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

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