ประโยชน์ของการหลีกเลี่ยงการใช้ดีบักเกอร์คืออะไร

ตลอดระยะเวลาการทำงานของฉันฉันสังเกตว่านักพัฒนาซอฟต์แวร์บางคนไม่ได้ใช้เครื่องมือดีบั๊ก แต่ตรวจสอบจุดที่ผิดพลาดของรหัสเพื่อหาสาเหตุของปัญหา

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

เป็นไปได้หรือไม่ที่จะจัดการคอมเพล็กซ์โดยไม่มีดีบักเกอร์? จะแนะนำให้เลือก? มีประโยชน์อะไรบ้างที่จะได้รับจากการใช้ "การแก้ไขข้อบกพร่องทางจิต "

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

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

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

แน่นอนว่าวิธีนี้มีข้อ จำกัด เนื่องจากข้อ จำกัด ส่วนใหญ่ของจิตใจในการแสดงภาพหลายเส้นทางผ่านรหัส ฉันเรียนรู้ที่จะเคารพข้อ จำกัด เหล่านี้ในใจของฉันหันมาใช้ดีบักเกอร์เพื่อแก้ไขข้อบกพร่องในอัลกอริทึมขั้นสูงขึ้น

ยิ่งฉันรู้รหัสฐานมากเท่าไหร่ฉันก็จำเป็นต้องใช้ดีบักเกอร์น้อยลง แต่ฉันก็ยังตรวจสอบข้อผิดพลาดที่รายงานได้ซึ่งเป็นเบาะแสสำคัญในการให้เหตุผลใด ๆ

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

พวกเขาอาจไม่ใช่โปรแกรมเมอร์ที่ไม่ดี แต่พวกเขาอาจเป็นนักแก้ไขปัญหาที่ไม่มีประสิทธิภาพอย่างมาก

ฉันมักจะทำตามคำแนะนำจากการดีบั๊ก: กฎ 9 ข้อที่ขาดไม่ได้สำหรับการค้นหาแม้แต่ปัญหาซอฟต์แวร์และฮาร์ดแวร์ที่ยากที่สุด (David Agans) และสิ่งนี้ตกอยู่ภายใต้คำแนะนำของ "เลิกคิดและมอง"

งานใด ๆ ที่ต้องใช้เครื่องมือที่เหมาะสมในวิธีที่เหมาะสม หากคุณมีดีบักเกอร์ให้ใช้เพื่อดูว่าเกิดอะไรขึ้นจริง ข้อบกพร่องส่วนใหญ่เกิดจากการสันนิษฐาน

ฉันทำงานร่วมกับนักพัฒนาซอฟต์แวร์ที่ไม่ยอมใช้ debuggers เพราะพวกเขารู้ดีกว่า การตอบสนองแบบคลาสสิกที่ฉันได้รับครั้งเดียวคือ 'ความผิดพลาดนั้นไม่ได้เกิดจากฉันฉันใช้เวลาทั้งวันเพื่อตรวจสอบรหัส (แล้วค่าว่างที่อ่านจากฐานข้อมูลล่ะ) เจ้านายดูเหมือนจะคิดว่ามันเป็นการตอบกลับที่ยอดเยี่ยม แต่ลูกค้าไม่ได้

ฉันออกจากทีมเร็วที่สุดเท่าที่จะทำได้ วัตถุประสงค์ของพวกเขาคือการขนงานและทำให้ปัญหา 10 นาทีง่าย ๆ เป็นปัญหาที่ดูยุ่งตลอดทั้งวัน

แนะนำที่ดีที่สุดของคุณเพื่อการปฏิบัติของการแก้จุดบกพร่องคือสตีฟ McConnel หนังสือรหัสเสร็จสมบูรณ์ บทที่ 23 ครอบคลุมการดีบักในรายละเอียดและฉันจะกลั่นสองสามคะแนนจากมัน

1. การทำความเข้าใจกับปัญหานั้นสำคัญและการใช้ตัวดีบั๊กก็ไม่ใช่สิ่งทดแทน
2. การคาดเดาเป็นวิธีที่ไม่ดีในการแก้ไขข้อบกพร่อง หากเพื่อนร่วมงานของคุณใช้การคาดเดาจริงๆแทนที่จะคิดเกี่ยวกับปัญหาพวกเขาก็ทำงานได้ไม่ดี Guesswork หมายถึงการติดงบการพิมพ์แบบสุ่มในรหัสและหวังว่าจะพบสิ่งที่มีประโยชน์
3. หากเพื่อนร่วมงานของคุณไม่รู้วิธีใช้ดีบักเกอร์ (แทนที่จะเลือกที่จะไม่ใช้) จริง ๆ แล้วใช่พวกเขาไร้ความสามารถเหมือนกับคนที่ไม่รู้จักไวยากรณ์ของภาษาที่พวกเขาควรจะใช้

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

การทำเช่นนี้ตลอดเวลาอาจเป็นการต่อต้านและถ้า "เดา" ไม่กี่ครั้งแรกการคาดเดาอาจเป็นกลยุทธ์การแก้ปัญหาที่ไม่ถูกต้องและควรเรียกตัวดีบั๊กจริง ๆ โดยปกติแล้วฉันจะบอกว่าไม่มีอะไรผิดปกติกับการใช้ดีบักเกอร์ .

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

ฉันประหลาดใจที่การอภิปรายในหัวข้อนี้ไม่ได้กล่าวถึง "การทดสอบหน่วย"

เนื่องจากฉันทำการพัฒนาที่ขับเคลื่อนด้วยการทดสอบฉันไม่ได้ใช้เวลามากในการดีบักเกอร์ 10 ปีที่แล้วฉันเคยทำตามขั้นตอนในการดีบัก:

1. หลังจากเขียนโค้ดเพื่อให้แน่ใจว่ามันทำงานและ
2. เมื่อฉันได้รับรายงานข้อผิดพลาดเพื่อพยายามวินิจฉัยปัญหา

สิ่งที่ฉันพบหลังจาก 10 ปีของการพัฒนาที่ขับเคลื่อนด้วยการทดสอบคือฉันมีประสิทธิผลมากขึ้นในฐานะโปรแกรมเมอร์ถ้า:

1. ฉันเขียนการทดสอบหน่วยก่อนที่จะเขียนรหัสเพื่อให้แน่ใจว่าฉันเขียนถูกต้อง
2. ฉันเขียนการทดสอบหน่วยทันทีที่ได้รับรายงานข้อผิดพลาดเพื่อพยายามทำซ้ำและเจาะลึกปัญหา

การอนุญาตให้คอมพิวเตอร์รันผ่านโค้ดและตรวจสอบผลลัพธ์ได้เร็วกว่าที่ฉันคิดหรือก้าวผ่านโค้ดเพื่อตรวจสอบผลลัพธ์ทางใจและไม่ผิดพลาด

ฉันยังต้องผ่านตัวแก้จุดบกพร่องในบางครั้งและฉันยังคงมีส่วนร่วมในการวิเคราะห์ทางจิตใจ ... แต่ไม่ค่อยมีและส่วนใหญ่สำหรับรหัสที่ยุ่งยากมาก

โดยส่วนตัวฉันพยายามลดการใช้ดีบักเกอร์ให้น้อยที่สุดโดย:

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

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

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

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

ตามที่กล่าวไว้ก่อนหน้านี้ในคำตอบข้างต้นการดีบักมีประโยชน์อย่างยิ่ง แต่ก็มีบางกรณีที่มีข้อ จำกัด

จากประสบการณ์ของฉันฉันพบว่าการใช้ตัวดีบักมีประโยชน์มากเพราะช่วยในการเปิดเผยสมมติฐานที่ผิดพลาดที่ฉันทำเกี่ยวกับสถานะของรหัสของฉัน บางคนไม่ฉลาดในการอ่านรหัสเพื่อค้นหาจุดบกพร่องดังนั้นการดีบั๊กสามารถช่วยในการเปิดเผยสมมติฐานที่ผิดพลาดที่คุณหรือผู้พัฒนารายอื่นทำเกี่ยวกับสถานะของรหัส

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

ในทางตรงกันข้ามกับประโยชน์ที่ได้จาก debuggers ในตัวอย่างข้างต้นฉันพบว่ามันยากและไม่มีประโยชน์ที่จะใช้เมื่อมีการใช้เธรดแบบมัลติเธรด (เช่นการทำงานพร้อมกันการประมวลผลแบบอะซิงโครนัส) มันสามารถช่วยได้ แต่มันง่ายที่จะสูญเสียการวางแนวของคุณในหมอกแบบมัลติเธรดเมื่อเบรกพอยต์ของจุดดีบั๊กถูกโจมตีในหนึ่งเธรดที่จุด A และเธรดแยกต่างหากที่จุด B นักพัฒนาถูกบังคับให้ดันเบรกพอยต์ใหม่ " กระบวนการคิด "ที่อยู่ด้านบนสุดของ" สแต็ค "ในสมองของเขาและปรับทิศทางตัวเองให้เป็นรหัสที่จุดพักเบรก หลังจากความเกี่ยวข้องของเบรกพอยต์ B ลดลงผู้พัฒนาก็เปลี่ยนกลับไปที่เบรกพอยต์แรกและต้องระลึกถึงสิ่งที่เขา / เธอกำลังมองหาก่อนที่จะก่อให้เกิดเบรกพอยต์บีฉันรู้ว่านี่อาจเป็นคำอธิบายที่สับสน

นอกจากนี้ความไม่แน่นอนของรหัสที่เกิดขึ้นพร้อมกันยังสามารถเบี่ยงเบนความสนใจของนักพัฒนาในการแก้ไขข้อบกพร่องของรหัสที่เกิดขึ้นพร้อมกัน

โดยสรุปในความเห็นที่ซื่อสัตย์ของฉัน:

• การดีบักเมื่อใช้งานพร้อมกัน = เพิ่มแนวโน้มที่จะสูญเสียโฟกัสของ "รูปแบบการคิดแก้จุดบกพร่อง"

และ

• ทุกเวลาอื่น = เพิ่มประสิทธิภาพการแก้ไขข้อบกพร่อง b / c ความสนใจของคุณไม่ถูกขัดจังหวะโดยเบรกพอยต์ที่ไม่คาดคิด (ไม่คาดคิดเนื่องจากสภาพการแข่งขัน)

ฉันคิดว่าพวกเขาไม่ยอมใครง่ายๆเกินไป โดยส่วนตัวเมื่อฉันพบข้อผิดพลาดฉันตรวจสอบรหัสอีกครั้งพยายามติดตามมันในใจของฉันจากตรรกะของโปรแกรมเพราะบางครั้งช่วยให้ฉันค้นพบปัญหาอื่น ๆ หรือผลข้างเคียงได้ง่ายกว่าการใช้ debbuger และแก้ไขข้อผิดพลาดที่ปรากฏ .

แม้เมื่อฉันคิดว่าฉันถูกจับฉันก็มักจะทำการดีบั๊กเพื่อให้แน่ใจว่าฉันพูดถูก เมื่อปัญหาซับซ้อนขึ้นอีกเล็กน้อยผมเชื่อว่าการแก้ไขข้อบกพร่องเป็นสิ่งจำเป็นอย่างยิ่ง

นอกจากนี้ ... แค่ความเห็นของฉัน แต่ไม่มีข้อแก้ตัวที่จะไม่ใช้ประโยชน์จากเครื่องมือที่ IDE ที่ทันสมัยสามารถนำมาใช้กับตารางได้ หากช่วยให้งานของคุณเร็วขึ้นและเชื่อถือได้มากขึ้นคุณควรใช้งาน

เกลียดที่จะพูดคุยกัน แต่โปรแกรมเมอร์หลายคนที่ฉันเคยพบคิดว่ามีวิธีเดียวที่จะแก้ปัญหา (ทางของพวกเขา) มันง่ายที่จะสันนิษฐานว่าการทดสอบที่เป็นไปได้ทุกอย่างนั้นเกิดขึ้นแล้ว มุมมองที่แตกต่างอาจมีค่ามาก

การเขียนโปรแกรมด้วยการลองผิดลองถูกสามารถเกิดขึ้นได้ด้วยวิธีการใหม่ที่ยอดเยี่ยม

ข้อเสียมักใช้เวลานานกว่ามาก

เอิ่มมันขึ้นอยู่กับบุคคลนั้น โดยส่วนตัวฉันไม่ได้ใช้ debuggers มาก เมื่อฉันตั้งโปรแกรมไมโครคอนโทรลเลอร์ฉันมักจะใช้ LEDs หรือเขียนข้อมูลไปยัง EEPROMs เพื่อ "ตรวจแก้จุดบกพร่อง" โค้ดบนมัน ฉันไม่ได้ใช้ JTAG

เมื่อฉันเขียนโปรแกรมซอฟต์แวร์สำหรับพีซีหรือเซิร์ฟเวอร์ฉันมักจะใช้การบันทึกและเอาต์พุตคอนโซลจำนวนมาก สำหรับภาษา C-style ฉันใช้คำสั่ง preprocessor และใน Java I ใช้ระดับการบันทึก

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

มีความแตกต่างระหว่างการไม่จำเป็นต้องใช้ดีบักเกอร์และไม่ทราบวิธีการ (หรือปฏิเสธ) ใช้ดีบักเกอร์ เครื่องมือดีบั๊กเป็นหนึ่งในเครื่องมือมากมายที่ใช้ในการติดตามและแก้ไขข้อบกพร่อง ฉันทำงานร่วมกับนักพัฒนาซอฟต์แวร์ที่สามารถไขปริศนาในหัวของพวกเขาและคนอื่น ๆ ที่คิดว่าพวกเขาทำได้

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

เครื่องมือ / แพลตฟอร์มที่แตกต่างกันใช้เทคนิคการดีบั๊กที่แตกต่างกัน (ดีบั๊ก, การบันทึก, การทดสอบหน่วย ฯลฯ ) ตราบใดที่นักพัฒนาคุ้นเคยกับเทคนิคบางประการสำหรับแพลตฟอร์ม / เครื่องมือของพวกเขานอกเหนือจากการตรวจสอบโค้ดอีกครั้ง นักพัฒนาที่มีทักษะ แต่ถ้าพวกเขามีเคล็ดลับเพียงอย่างเดียวเมื่อมันทำการแก้ไขข้อบกพร่องแล้วพวกเขาก็จะเจอข้อบกพร่องในที่สุดพวกเขาไม่สามารถค้นหาหรือแก้ไขได้

มีคำตอบมากมาย แต่ไม่พูดถึงHeisenbug ?!?!

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

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

ฉันอ่านข้อโต้แย้งเกี่ยวกับการดีบักเกอร์ที่นี่เมื่อเร็ว ๆ นี้ (หรือว่าเป็น StackOverflow?) คุณควรมีกรณีทดสอบกับรหัสของคุณ หากการทดสอบของคุณผ่านการดีบั๊กของคุณอาจจะไม่ใช้บั๊ก (สมมุติว่า: คุณจะดีบั๊กด้วยข้อมูลที่คล้ายกับข้อมูลการทดสอบของคุณ)

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

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

ด้วยการทดสอบหน่วยที่ดีและข้อยกเว้นที่ให้ backtrace คุณไม่ค่อยต้องใช้ดีบักเกอร์

ครั้งสุดท้ายที่ฉันใช้ดีบั๊กคือเมื่อฉันได้รับไฟล์หลักในแอปพลิเคชันรุ่นเก่า

ฉันเป็น "debbuger minion" หรือว่าคนเหล่านี้เป็น "ไม่ยอมใครง่ายๆ"

ทั้ง พวกเขาเป็นคนประเภทที่ต้องการทำให้ชีวิตของพวกเขายากขึ้นแล้วมันควรจะเป็น

การดีบักเป็นเพียงเครื่องมือที่นักพัฒนาซอฟต์แวร์ที่ดีควรใช้อย่างเชี่ยวชาญ

แน่นอนบางครั้งคุณสามารถรู้ด้วยหัวใจที่ข้อผิดพลาดได้ถ้าคุณรู้รหัสฐาน แต่คุณสามารถสูญเสียทั้งวันหรือทั้งสัปดาห์เพื่อหาข้อผิดพลาดที่น่ารำคาญเพียงแค่มองเข้าไปในรหัส

ในภาษาที่พิมพ์แบบไดนามิกโดยไม่มีการดีบักบางประเภท (แม้ว่าจะเป็นเพียงการทิ้งค่าไปยังคอนโซล) บางครั้งการเดาก็เป็นไปไม่ได้

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

ขึ้นอยู่กับขอบเขตของปัญหา หากโปรแกรมมีขนาดเล็กและมีการแบ่งสิ่งต่าง ๆ เป็นอย่างดีคุณอาจสามารถหาได้โดยดู หากโปรแกรมนั้นมีรหัส 4.5 ล้านบรรทัดที่พัฒนาโดยทีมงานกว่า 100 คนตลอดระยะเวลาหลายปีนั้นข้อบกพร่องบางอย่างจะเป็นไปไม่ได้

หนึ่งในคำถามในโปรแกรมดังกล่าว (ใน C) คือหน่วยความจำเขียนทับ โปรแกรมดีบั๊กที่มีเบรกพอยต์ของหน่วยความจำระบุบรรทัดที่ละเมิดรหัสทันทีที่พบจุดบกพร่อง แต่ในกรณีนี้ไม่มีทางที่ใครจะสามารถอ่านและเก็บรักษารหัสทั้งหมด 4.5 ล้านบรรทัดเพื่อระบุจุดเดียวที่มีคนเขียนอาร์เรย์ของพวกเขา (รวมทั้งพวกเขาจะต้องรู้จักรูปแบบรันไทม์ของหน่วยความจำสำหรับสถานะของโปรแกรม gargantuan ประมาณ 10 นาทีสำหรับอินพุทระยะยาวเพื่อไปยังจุดนั้น)

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

หากข้อผิดพลาดเกิดขึ้นในคอมพิวเตอร์ของลูกค้าหรือในคอมพิวเตอร์ที่สภาพแวดล้อมแตกต่างจากของคุณมากการตั้งค่าตัวดีบักเกอร์ / ตัวดีบักระยะไกลนั้นยุ่งยาก ดังนั้นสำหรับวันที่อากาศหนาวเย็นที่คุณได้รับข้อผิดพลาดจากสนามการตอบสนองของ 'แต่ ... ฉันไม่มีบั๊ก' ไม่ได้ช่วยอะไร ดังนั้นคุณต้องพัฒนาชุดทักษะในการแก้ไขปัญหาและค้นหาข้อผิดพลาดเพียงแค่ทำความเข้าใจกับรหัสและไฟล์บันทึก

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

นอกจากนี้ให้พิจารณาว่าไม่ใช่ทุกคนที่ได้รับมอบหมายให้ใช้รหัสการดีบักนั้นคุ้นเคยกับรหัสดังกล่าว ผู้รับเหมาหลายครั้งเข้ามาในสภาพแวดล้อมที่พวกเขามีอุดมคติโดยทั่วไปสิ่งที่เกิดขึ้น พวกเขาอาจได้รับการอธิบายรายละเอียดของสภาพแวดล้อม - หรือแผนที่สคีมาอายุ 20 ปีและแนวทางการตั้งชื่อ arcane (ลองทำความเข้าใจความแตกต่างระหว่างตาราง X1234 และตาราง X4312 กับเขตข้อมูล F1, F2 และ F3 [ใช่ขยะเช่นนี้ มีอยู่] เมื่อคุณเป็นคนใหม่) แต่หลายครั้งที่คำอธิบายนั้นผิด มิฉะนั้นทำไมจึงมีข้อผิดพลาด "ลึกลับ"

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