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

กำไร:

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

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

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

กฎทองของการปรับโครงสร้างใหม่: พฤติกรรมยังคงที่

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

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

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

ทีละขั้นตอน: ขั้นตอนการปรับโครงสร้างใหม่อย่างปลอดภัย

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

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

กรณีที่ 1 — ฟังก์ชัน 220 บรรทัดแยกอย่างปลอดภัย ทีมหนึ่งมีฟังก์ชันการประมวลผลคำสั่งซื้อ 220 บรรทัด มีการเขียนการทดสอบ 14 ครั้งแรก (ด้วยความช่วยเหลือของ AI) ซึ่งบันทึกพฤติกรรมปัจจุบัน และผ่านการทดสอบทั้งหมด จากนั้นฟังก์ชันก็ถูกแบ่งออกเป็น 5 ฟังก์ชันเล็กๆ ทีละขั้นตอนโดย AI; ทำการทดสอบหลังจากแต่ละขั้นตอน การทดสอบสองครั้งล้มเหลวในขั้นตอนเดียว – AI พลาดการคืนสินค้าในกรณี Edge การทดสอบตรวจพบสิ่งนี้ทันทีและทำการแก้ไข หากไม่มีเครือข่าย ข้อผิดพลาดอาจลุกลามไปจนถึงการใช้งานจริง

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

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

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

การตรวจจับและจัดลำดับความสำคัญของรหัสกลิ่น:

แสดงรายการผู้สมัครที่ปรับโครงสร้างใหม่ "มีกลิ่น" ในโค้ดนี้: ฟังก์ชั่นแบบยาว, การทำซ้ำ (DRYViolation), ชื่อที่ทำให้เข้าใจผิด, สภาพที่ซ้อนกันลึก, ผลข้างเคียงที่ซ่อนอยู่, หมายเลขเวทย์มนตร์ สำหรับแต่ละ: สถานที่ สาเหตุที่เกิดปัญหา ขั้นตอนเล็กๆ ที่แนะนำ ความเสี่ยงโดยประมาณ (ต่ำ/กลาง/สูง) อย่าเพิ่งเปลี่ยนรหัส เพียงวางแผน{{code}}

การเปลี่ยนแปลงการรักษาพฤติกรรมในขั้นตอนเดียว:

เพียงทำสิ่งนี้: {{single Conversion, e.g. แบ่งฟังก์ชันนี้ออกเป็น 3 ฟังก์ชันที่มีชื่อเล็กๆ}} เปลี่ยนพฤติกรรมที่มองเห็นได้ ลายเซ็น และค่าที่ส่งคืน เขียนใน 1 ประโยคว่าทำไมทุกสิ่งที่คุณเปลี่ยนแปลงจึงรักษาพฤติกรรมไว้{{code}}

ตาข่ายนิรภัยก่อนการรีแฟคเตอร์ (การทดสอบลักษณะเฉพาะ):

เขียนการทดสอบที่จับพฤติกรรมปัจจุบันของฟังก์ชันนี้ (ถูกต้องหรือไม่) เป้าหมายคือการตรวจจับว่าพฤติกรรมเปลี่ยนแปลงไปในระหว่างการปรับโครงสร้างใหม่หรือไม่ รวมรายการ + edge ทั่วไป เขียนความคาดหวังตามผลลัพธ์ปัจจุบันของฟังก์ชัน{{function}}

การสร้างบันทึกหนี้ทางเทคนิค (งานที่ค้างอยู่):

ใส่รายการกลิ่นต่อไปนี้ลงในตารางการจัดลำดับความสำคัญ: สาร พื้นที่ได้รับผลกระทบ ความถี่ของการเปลี่ยนแปลง (ความรู้ของฉัน: {{...}}) ความเสี่ยง ความพยายามโดยประมาณ ลำดับความสำคัญที่แนะนำ วางสิ่งที่มีผลกระทบสูง + ความพยายามต่ำไว้ด้านบน {{กลิ่น_รายการ}}

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

จุดอ่อน: "ล้างโค้ดนี้และทำให้ดีขึ้น"

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

รุ่นทรงพลัง; จำเป็นต้องมีการเปลี่ยนแปลงเฉพาะเพียงครั้งเดียว กำหนดลักษณะการทำงานและข้อจำกัดของลายเซ็นอย่างชัดเจน และต้องการเหตุผล คำขอที่คลุมเครือ เช่น "ทำดีกว่า" นำไปสู่การเปลี่ยนแปลงที่ไม่สามารถควบคุมได้และมีความเสี่ยง

ประเภทการรีแฟคเตอร์

ความน่าเชื่อถือของเอไอ

ข้อกำหนดเบื้องต้น

เปลี่ยนชื่อ

สูง

ขอบเขตถูกต้องหรือไม่?

การแบ่งฟังก์ชัน

สูงปานกลาง

เทสเน็ตเป็นสิ่งจำเป็น

การแบ่งปันการทำซ้ำ

ปานกลาง

ความแตกต่างของพฤติกรรมอาจถูกซ่อนไว้

การเปลี่ยนแปลงอัลกอริทึม/โครงสร้าง

ต่ำ

การทดสอบอย่างกว้างขวาง + การตรวจสอบโดยมนุษย์

การจัดเรียงสถาปัตยกรรมใหม่

ต่ำ

ขับเคลื่อนโดยมนุษย์ รองรับ AI

การจัดการหนี้ทางเทคนิค ไม่ใช่การรีเซ็ต

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

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

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

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

โดยสรุป

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

งานสมัคร

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

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

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