โปรแกรมเมอร์จริงใช้ debuggers? [ปิด]

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

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

ฉันใช้ตัวดีบักบ่อยครั้งเพราะฉันทำงานในระบบขนาดใหญ่ดังนั้นฉันจึงดูด http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html

ไม่ว่ารหัสของคุณจะสั้นและอ่านบ่อยเพียงใดมีความเป็นไปได้ที่จะมีข้อบกพร่องอยู่เสมอ http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

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

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

ดังนั้นฉันไม่ต้องการดีบักเกอร์เมื่อใด

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

• รหัสคือของฉันหรือเขียนดีและ
• มันเขียนในภาษาที่อ่านได้และ
• โครงการโดยรวมมีขนาดเล็ก

ฉันจะใช้ดีบักเกอร์อย่างหนักเมื่อใด

• คำตอบสั้น ๆ : บ่อยครั้งมักจะ
• เมื่อแอปพลิเคชันขัดข้อง โดยเฉพาะอย่างยิ่งเมื่อมีการใช้งาน มี VS2010 ติดตั้งบนคอมพิวเตอร์ที่สามารถสร้างความแตกต่างระหว่าง "ไม่ทราบข้อผิดพลาด" FileNotFoundExceptionและ
• เมื่อห้องสมุดของบุคคลที่สามขัดข้องหรือทำงานผิดปกติ
• เมื่อรหัสถูกเขียนไม่ดี โดยเฉพาะอย่างยิ่งหากไฟล์เดียวกันถูกสัมผัสโดย 10 คนที่แตกต่างกันในช่วง 10 ปีที่ผ่านมาซึ่ง 7 ในนั้นไม่ได้อยู่กับ บริษัท อีกต่อไป
• เมื่อโครงการมีขนาดใหญ่
• เมื่อรหัสค่อนข้างเสาหิน
• เมื่อมีหลายระดับ (GUI, SQL, BL) ที่เกี่ยวข้อง

โปรดทราบว่า "ดีบักเกอร์" สามารถอ้างถึงเครื่องมือมากกว่าหนึ่งรายการ ฉันใช้ดีบัก Visual Studio, SQL ดีบักเกอร์ (ส่วนใหญ่เป็น procs ที่จัดเก็บ) และ SQL profiler ด้วย (เพื่อหาว่า SP ใดที่ถูกเรียก) ฉันต้องการเครื่องมือที่มีความสามารถนี้ที่ฉันเขียนสคริปต์ sysadmin-ish ฉบับย่อหรือไม่? ไม่ถ้าฉันสร้างเครื่องมือที่ใช้ GUI ตัวน้อยของฉันเอง ขึ้นอยู่กับ ถ้าเป็น. Net WinForms - อาจจะไม่ ถ้าเป็น WPF - ใช่

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

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

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

...

ทีนี้ในทางทฤษฎีฉันสามารถอ่านรหัสฐานได้นานจนฉันเพิ่งได้รับ อย่างไรก็ตามวิธีการลงมือทำงานได้ดีที่สุดรวมถึงฉันมักจะต้องการเขียนโค้ดโง่ ๆ ที่ฉันเห็นอีกครั้ง น่าเสียดายที่ฉันใช้เวลา 10 ปีในการทำความสะอาดฐานรหัสที่ฉันใช้ดังนั้นการใช้ดีบักเกอร์จึงเป็นขั้นตอนแรกที่ชัดเจน เมื่อฉันค้นพบว่าโค้ดใดใน 5 ล้านบรรทัดที่กำลังทำงานอยู่ฉันจะสแกนไฟล์ขึ้นและลงเพื่อลองคิดดูว่าคลาสนั้นกำลังทำอะไรอยู่

"ฉันไม่ชอบ debuggers ไม่เคยมีอาจจะไม่เคย" - Linus Torvalds

ในทางกลับกันเขาไม่มีบัญชี Stack Overflow ดังนั้นฉันไม่แน่ใจว่าคุณสนใจความคิดเห็นของเขาหรือไม่ :)

ดังนั้นคำถามที่ตอบได้เฉพาะของฉันอยู่ ภายใต้สถานการณ์ใดที่คุณต้องการใช้ดีบักเกอร์ในฐานะโปรแกรมเมอร์ที่มีประสบการณ์

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

แก้ไข:

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

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

ในบางครั้งดีบักเกอร์อาจเป็นเครื่องมือที่ยอดเยี่ยมและเมื่อใดก็ตามที่ฉันสามารถสร้างและเรียกใช้โค้ดบนเดสก์ท็อปได้ฉันก็จะใช้ดีบักเกอร์เสมอ

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

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

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

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

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

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

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

นาน ๆ ครั้ง.

วิธีการของคุณควรเล็ก / ง่ายพอที่จะรวบรวมและดำเนินการโดยความคิดของคุณการทดสอบหน่วยควรครอบคลุมการใช้งาน หากคุณพบข้อบกพร่องเขียนการทดสอบ เรียกใช้แก้ไขได้

ฉันมักจะใช้ดีบักเกอร์เมื่อ ive มีพฤติกรรมที่ไม่คาดคิดจากโค้ดที่ไม่สามารถทดสอบได้เช่นกรอบงาน ASP.NET

ใน Smalltalk ฉันพัฒนาเกือบทั้งหมดในเครื่องมือดีบั๊ก:

1. เขียนแบบทดสอบที่ฉันรู้ว่าจะล้มเหลว
2. ทำการทดสอบ เมื่อล้มเหลวตัวดีบักจะปรากฏขึ้น
3. เขียนในดีบักเกอร์รหัสที่จำเป็นเพื่อให้ผ่านการทดสอบ
4. ดำเนินการต่อ
5. หากฉันได้รับไฟเขียวให้ไปที่ขั้นตอนที่ 1 พร้อมการทดสอบความล้มเหลวใหม่ มิฉะนั้นในดีบักเกอร์จะหาสิ่งที่ฉันทำผิดและแก้ไข

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

ฉันต้องยอมรับว่าฉันใช้ดีบั๊กน้อยลงเรื่อย ๆ ฉันพัฒนาใน Delphi มากว่า 10 ปี ฉันยังเขียนขั้นตอนที่เก็บไว้ใน PL / SQL ตั้งแต่สองสามเดือนฉันเป็นนักพัฒนา PHP ด้วย

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

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

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

ฉันใช้รหัสในบางครั้งโดยไม่มีการดีบั๊ก แต่เมื่อถูกบังคับให้เข้าจู่โจมนั่นคือ มรดกฝังตัว gunge บน 8051 หรือ Z80

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

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

ดังนั้นฉันต้องการดีบักเกอร์เพื่อลบข้อบกพร่องโง่จ้องมองและ cockups ฮาร์ดแวร์ ฉันต้องการการบันทึกที่ดีเพื่อตรวจจับข้อบกพร่องของการรวมระบบเป็นระยะ

ฉันต้องมีทั้งคู่ - ฉันต้องการความช่วยเหลือทั้งหมดที่ฉันสามารถหาได้!

ฉันใช้ดีบักเกอร์เมื่อขั้นตอนเหล่านี้ล้มเหลวเท่านั้น:

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

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

ดังนั้นคำสั่งการบันทึกที่ถูกวางไว้อย่างรอบคอบจะไปไกล

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

หากคุณเก่งในการแก้ไขข้อบกพร่องของ printf (และย้อนกลับไปในยุคแปดเราไม่ได้มีทางเลือกมากนัก แต่จะทำให้ดีขึ้นจริง ๆ ) บางทีผู้ดีบักอาจไม่ได้เพิ่มอะไรมากมาย

มันเป็นคำถามของทางเลือกส่วนตัว

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

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

นอกเหนือจากคุณสมบัติทั้งสองนี้ฉันไม่คิดว่าดีบักเกอร์นั้นจำเป็นจริงๆ โปรแกรมที่ซับซ้อนใด ๆ ที่คุณทำควรมีโหมด "verbose" บางอย่างเช่นบอกทุกอย่างที่มันทำกับ printf หรือ std :: cout สิ่งที่เลือกมันทำและพารามิเตอร์อื่น ๆ มากมาย

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

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

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

ผู้ใช้ดีบั๊กมีประโยชน์สำหรับภาษาที่คอมไพล์แล้วมีน้อยมากสำหรับภาษาที่ถูกบุกรุก