ฉันต้องการเพิ่มว่าดีบักเกอร์ไม่ใช่โซลูชันที่สมบูรณ์แบบเสมอไปและไม่ควรเป็นวิธีแก้จุดบกพร่องเสมอไป ต่อไปนี้เป็นบางกรณีที่เครื่องดีบักอาจไม่ทำงานสำหรับคุณ:
- ส่วนของโปรแกรมของคุณที่ล้มเหลวนั้นมีขนาดใหญ่มาก (บางทีการแยกส่วนที่ไม่ดีอาจเป็นไปได้?) และคุณไม่แน่ใจว่าจะเริ่มก้าวผ่านโค้ดจากที่ใด การก้าวผ่านทั้งหมดนี้อาจใช้เวลานานเกินไป
- โปรแกรมของคุณใช้การเรียกกลับจำนวนมากและวิธีการควบคุมโฟลว์ที่ไม่ใช่เชิงเส้นอื่น ๆ ซึ่งทำให้ดีบักเกอร์สับสนเมื่อคุณทำตามขั้นตอน
- โปรแกรมของคุณเป็นแบบมัลติเธรด หรือแย่กว่านั้นคือปัญหาของคุณเกิดจากสภาพการแข่งขัน
- โค้ดที่มีบั๊กจะทำงานหลายครั้งก่อนที่จะบั๊ก สิ่งนี้อาจเป็นปัญหาโดยเฉพาะอย่างยิ่งในลูปหลักหรือแย่กว่านั้นในเอนจินฟิสิกส์ซึ่งปัญหาอาจเป็นตัวเลข แม้แต่การตั้งค่าเบรกพอยต์ในกรณีนี้คุณก็แค่กดปุ่มหลาย ๆ ครั้งโดยที่บั๊กจะไม่ปรากฏขึ้น
- โปรแกรมของคุณต้องทำงานแบบเรียลไทม์ นี่เป็นเรื่องใหญ่สำหรับโปรแกรมที่เชื่อมต่อกับเครือข่าย หากคุณตั้งค่าเบรกพอยต์ในรหัสเครือข่ายปลายอีกด้านหนึ่งจะไม่รอให้คุณก้าวผ่านมันก็หมดเวลาแล้ว โปรแกรมที่ใช้นาฬิการะบบเช่นเกมที่มี frameskip ก็ไม่ได้ดีไปกว่ากัน
- โปรแกรมของคุณดำเนินการทำลายบางรูปแบบเช่นการเขียนลงไฟล์หรือส่งอีเมลและคุณต้องการ จำกัด จำนวนครั้งที่คุณต้องเรียกใช้
- คุณสามารถบอกได้ว่าจุดบกพร่องของคุณเกิดจากค่าที่มาถึงฟังก์ชัน X ไม่ถูกต้อง แต่คุณไม่รู้ว่าค่าเหล่านี้มาจากไหน การต้องทำงานผ่านโปรแกรมซ้ำแล้วซ้ำอีกการตั้งค่าจุดพักให้ไกลขึ้นและไกลออกไปอาจเป็นเรื่องยุ่งยากมาก โดยเฉพาะอย่างยิ่งถ้าฟังก์ชัน X ถูกเรียกใช้จากหลาย ๆ ที่ตลอดทั้งโปรแกรม
ในทุกกรณีเหล่านี้การหยุดโปรแกรมกะทันหันอาจทำให้ผลลัพธ์สุดท้ายแตกต่างกันไปหรือการค้นหาบรรทัดเดียวที่เกิดข้อบกพร่องด้วยตนเองนั้นเป็นเรื่องยุ่งยากมากเกินไป สิ่งนี้สามารถเกิดขึ้นได้ไม่ว่าข้อบกพร่องของคุณจะเป็นพฤติกรรมที่ไม่ถูกต้องหรือความผิดพลาด ตัวอย่างเช่นหากความเสียหายของหน่วยความจำทำให้เกิดข้อขัดข้องเมื่อถึงเวลาที่เกิดข้อขัดข้องก็ยังห่างไกลจากจุดที่หน่วยความจำเสียหายครั้งแรกมากเกินไปและไม่มีข้อมูลที่เป็นประโยชน์เหลืออยู่
ทางเลือกอื่นคืออะไร?
ง่ายที่สุดคือการบันทึกและการยืนยัน เพิ่มบันทึกในโปรแกรมของคุณตามจุดต่างๆและเปรียบเทียบสิ่งที่คุณได้รับกับสิ่งที่คุณคาดหวัง ตัวอย่างเช่นดูว่ามีการเรียกใช้ฟังก์ชันที่คุณคิดว่ามีจุดบกพร่องหรือไม่ในตอนแรก ดูว่าตัวแปรที่จุดเริ่มต้นของเมธอดเป็นอย่างที่คุณคิดหรือไม่ ซึ่งแตกต่างจากจุดพักคือโอเคที่จะมีบรรทัดบันทึกจำนวนมากซึ่งไม่มีอะไรพิเศษเกิดขึ้น คุณสามารถค้นหาผ่านบันทึกได้ในภายหลัง เมื่อคุณเข้าสู่บรรทัดบันทึกที่แตกต่างจากที่คุณคาดหวังให้เพิ่มมากขึ้นในพื้นที่เดียวกัน จำกัด ขอบเขตให้แคบลงและไกลออกไปจนกว่าจะมีขนาดเล็กพอที่จะบันทึกทุกบรรทัดในพื้นที่ที่มีปัญหา
การยืนยันสามารถใช้เพื่อดักจับค่าที่ไม่ถูกต้องเมื่อเกิดขึ้นแทนที่จะมีผลให้ผู้ใช้ปลายทางมองเห็นได้ ยิ่งคุณจับค่าที่ไม่ถูกต้องได้เร็วเท่าไหร่คุณก็ยิ่งเข้าใกล้เส้นที่สร้างขึ้นเท่านั้น
การทดสอบ Refactor และหน่วย หากโปรแกรมของคุณมีขนาดใหญ่เกินไปอาจเป็นการคุ้มค่าที่จะทดสอบทีละคลาสหรือทีละฟังก์ชัน ให้อินพุตและดูที่เอาต์พุตและดูว่าสิ่งใดไม่เป็นไปตามที่คุณคาดหวัง ความสามารถในการ จำกัด จุดบกพร่องจากโปรแกรมทั้งหมดให้เหลือเพียงฟังก์ชันเดียวสามารถสร้างความแตกต่างอย่างมากในเวลาดีบัก
ในกรณีที่หน่วยความจำรั่วไหลหรือหน่วยความจำหยุดทำงานให้ใช้เครื่องมือที่เหมาะสมซึ่งสามารถวิเคราะห์และตรวจจับได้ในขณะรันไทม์ ความสามารถในการตรวจสอบว่าเกิดการทุจริตขึ้นที่ใดเป็นขั้นตอนแรก หลังจากนี้คุณสามารถใช้บันทึกเพื่อย้อนกลับไปยังจุดที่มีการนำค่าที่ไม่ถูกต้องมาใช้
โปรดจำไว้ว่าการดีบักเป็นกระบวนการที่ย้อนกลับไป คุณมีผลลัพธ์สุดท้าย - ข้อบกพร่อง - และค้นหาสาเหตุซึ่งนำหน้า มันเกี่ยวกับการย้อนกลับไปข้างหน้าและน่าเสียดายที่ผู้แก้ปัญหาเพียงแค่ก้าวไปข้างหน้า นี่คือที่ที่การบันทึกที่ดีและการวิเคราะห์หลังการตายสามารถให้ผลลัพธ์ที่ดีกว่ามาก