จะใช้เวลาในการดีบักน้อยลงได้อย่างไร [ปิด]

ตามกฎของ Pareto โปรแกรมเมอร์ใช้เวลาเพียง 20% ในการทำสิ่งที่มีประโยชน์จริงๆ

ฉันใช้เวลา 80% ในการดีบักแก้ไขสิ่งเล็ก ๆ เพื่อให้ทุกอย่างทำงานได้

มีวิธีการแก้จุดบกพร่องใช้เวลาน้อยลงหรือไม่

รหัสในAGDAหรือCoq เมื่อรหัสของคุณรวบรวมมันจะทำงาน หากไม่ยอมใครง่ายๆให้เลือกภาษาที่ใช้ระบบที่อ่อนแอกว่าเช่น Haskell หรือ F #

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

การทดสอบหน่วย

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

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

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

การทดสอบหน่วยจะช่วยได้อย่างหวังว่าถ้าคุณแนะนำบั๊กพวกเขาจะแตกก่อนรหัสการผลิตของคุณ - การทดสอบหน่วยที่เขียนอย่างดีจะบอกคุณได้อย่างชัดเจนถึงสิ่งที่แตกหัก

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

1. ใช้ประเภทที่ไม่เปลี่ยนรูปได้ทุกที่ที่เป็นไปได้ - หากมีสิ่งใดที่มีมูลค่าไม่ถูกต้องคุณจะรู้ได้ทันทีว่าจะต้องมองตรงไหน
2. บังคับใช้ค่าคงที่ในรหัส - หากคุณรู้ว่าค่าไม่ได้รับอนุญาตให้ทำอย่างนั้นให้ตรวจสอบและโยนข้อยกเว้นในจุดเข้าสู่วิธีการและตัวสร้าง หากคุณรวมสิ่งนี้เข้ากับประเภทที่ไม่เปลี่ยนรูปแล้วคุณสามารถเริ่มต้นการตั้งสมมติฐานบางอย่างเกี่ยวกับสิ่งที่ถูกต้องหรือไม่
3. ให้แน่ใจว่าคุณมีการเข้าสู่ระบบที่เพียงพอ - รับสิ่งนี้ในช่วงต้นและมันจะให้ข้อมูลที่สำคัญเกี่ยวกับเมื่อสิ่งผิดปกติ AOP ทำงานได้ดีที่นี่จริงๆ การบันทึกในภายหลังมักจะเป็นขยะเล็กน้อย - เข้ามาก่อนโดยเป็นส่วนหนึ่งของการตั้งค่าโครงการ
4. หากฐานรหัสของคุณมีขนาดใหญ่ / ซับซ้อนมากพอที่จะหลีกเลี่ยงการใช้แบบดั้งเดิมได้เช่นมีประเภทที่เรียกว่า 'อายุ' แทนที่จะใช้เพียงแค่ int มันจะดูไร้จุดหมายสักหน่อยในตอนแรก แต่ความสามารถในการติดตามการใช้งานบางอย่างในทันทีนั้นเป็นชัยชนะที่ดีมาก

80% ของฉันคือ debug ฉันกำลังแก้ไขข้อบกพร่องอย่างง่าย ๆ และพยายามทำให้ทุกอย่างทำงานได้

เริ่มต้นด้วยการเขียนการทดสอบหน่วยและพยายามให้ครอบคลุมมากที่สุด มีคนพูดถึง TDD แต่ฉันจะไปกับBDD

ในตอนท้ายคุณจะใช้จ่าย 80% ในการดีบักข้อบกพร่องที่ซับซ้อน

จะใช้เวลาดีบักน้อยลงอย่างไร เขียนรหัสน้อย

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

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

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

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

• รู้วิธีใช้ซอฟต์แวร์ควบคุมเวอร์ชันของคุณ

  • การใช้สาขาจะช่วยให้คุณแยกพื้นที่ของการพัฒนาและคุณจะสามารถดูว่าพื้นที่ของการพัฒนาใดที่มีข้อบกพร่องและไม่สามารถทำได้
  • เรียนรู้วิธีใช้ bisection ใน VCS ของคุณ Git มีสิ่งนี้อยู่ภายในถ้าคุณใช้ VCS อื่นที่ไม่มีการสร้าง bisection ในการค้นหาเครื่องมือที่ทำงานเหมือน git bisect แต่สำหรับ VCS ของคุณ (ฉันรู้ว่ามันมีอยู่สำหรับ SVN และ ไม่ควรสร้างยากเกินไปสำหรับ VCS อื่น) วิธีนี้จะช่วยให้คุณ จำกัด การเปลี่ยนแปลงรหัสที่จะนำข้อบกพร่องมาใช้ซึ่งจะช่วยให้ทราบจุดที่จะดีบักเกอร์ของคุณ กระบวนการแบ่งส่วนนี้จะเร็วขึ้นหากคุณมีการทดสอบข้อผิดพลาดและรู้ว่าการกระทำที่มีการเปลี่ยนแปลงที่กระทำผิดจะมีประโยชน์มากขึ้นถ้าคุณฝึกปฏิบัติปรมาณู

• พัฒนาความเข้าใจในภาษาการเขียนโปรแกรมที่คุณใช้

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

• จงมีเหตุผล

  • อย่าเปลี่ยนแปลงมากกว่าหนึ่งอย่างพร้อมกันหากอย่างนั้นพฤติกรรมที่เปลี่ยนไปคุณจะไม่รู้ว่าการเปลี่ยนแปลงใดที่ทำให้เกิดการเปลี่ยนแปลงพฤติกรรม
  • ตรวจสอบสมมติฐานของคุณ

การเพิ่มความคิดเห็นสำหรับการทดสอบหน่วย แต่มันจะดีมากถ้ารหัสของคุณถูกแยกเพื่อรองรับ (เช่น MVC) หากคุณไม่สามารถใช้ MVC (หรือคล้ายกัน) (โครงการดั้งเดิม) การทดสอบหน่วยจะไม่ทำงานเลยสำหรับ UI ของคุณ ฉันจะเพิ่มการทดสอบ UI อัตโนมัติ (การทดสอบ UI ของ Microsoft Coded, WaitN) เนื่องจากจะเป็นการลดข้อผิดพลาดในส่วนของรหัสของคุณ

ฉันขอแนะนำให้ใช้เครื่องมือวิเคราะห์แบบสแตติก (เช่นการวิเคราะห์รหัส FxCop / Microsoft, Resharper, JustCode สำหรับโลก MS) สิ่งเหล่านี้สามารถค้นหาปัญหาการเข้ารหัสที่พบบ่อยทุกชนิดซึ่งสามารถลดงานการดีบักที่โง่และมุ่งเน้นไปที่การแก้ไขข้อบกพร่องทางตรรกะทางธุรกิจ

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

เมื่อไม่นานมานี้ฉันได้รับความคิดมากเกี่ยวกับปัญหานี้คำตอบง่ายๆคืออ่านเรื่องของการออกแบบของสิ่งต่าง ๆ ในชีวิตประจำวันของ Don Norman; เขียนโค้ดอย่างที่คุณต้องการออกแบบผลิตภัณฑ์

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

ฟังก์ชั่นชื่ออย่างสังหรณ์ใจ เรื่องนี้เป็นที่รู้จักกันอย่างเป็นทางการว่า affordance นั่นคือปุ่มกดที่จะกดคันโยกกำบังที่จะเปลี่ยนจับที่จะดึง ฯลฯ

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

- ใช้นามธรรมตามความเหมาะสม ความจำระยะสั้นอ่อนแอ

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

- หน่วยทดสอบ สิ่งเหล่านี้ไม่ได้ป้องกันข้อผิดพลาดอย่างแท้จริงเท่าที่เห็นได้ชัดว่าข้อบกพร่องอยู่ที่ไหนและให้มีสติ

ฉันแน่ใจว่าฉันขาดหลักการอื่น ๆ อีกมากมาย แต่ประเด็นคืออ่านข้อผิดพลาดในการออกแบบ

วิธีที่ดีที่สุดในการลดการดีบัก IMO คือการเน้นและทำให้ช้าลงเมื่อมีการเข้ารหัส สิ่งนี้บังคับให้คุณเห็นความผิดพลาดที่คุณทำ!

ในขณะที่ฉันสนับสนุนการทดสอบหน่วยที่แนะนำข้างต้นทั้งหมด TDD หรือ BDD จะมีค่ามากเพราะคุณต้องคิดก่อนเกี่ยวกับปัญหาและวิธีแก้ปัญหา

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

บางครั้งการเขียนลวก ๆ บนแผ่นกระดาษอย่างรวดเร็วจะช่วยให้คุณเห็นชิ้นส่วนเชื่อมต่อที่ใหญ่ขึ้นของปริศนา

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

PS ฉันหมายถึง 5 อาจสิบนาทีไม่ใช่ชั่วโมงเขียนสเปคขนาดใหญ่

มีคำตอบที่ดีอยู่แล้ว แต่มีอาหารอีกมากสำหรับนอกเหนือจากสิ่งที่คนอื่นพูด

เรียนรู้จากความผิดพลาดของคุณ อย่าทำแบบเดียวกันซ้ำไปซ้ำมา

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

ใส่ใจกับความต้องการ แม้ว่าจะใช้งานได้ แต่ไม่ได้ทำตามข้อกำหนดที่ระบุนั่นเป็นข้อบกพร่อง

บันทึกข้อยกเว้นสามารถช่วยได้จริงเมื่อมีสิ่งผิดปกติหกเดือนนับจากนี้ เป็นนิสัยของการบันทึกข้อยกเว้น

ความคิดสูงสุดสองข้อของฉันคือ 1) เขียนโค้ดที่ดีขึ้นซึ่งจะล้มเหลวเมื่อคุณทำสิ่งที่ไม่คาดคิด 2) พัฒนาตัวเองให้ดีขึ้น

รหัสของฉันเกลื่อนไปด้วย

if(value!=null) throw new NotImplementedException();
if(obj.v>0) throw new Exception(); //sometimes i dont write NotImplementedException
if(value=="thing") throw ...;

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

เพื่อให้ดีขึ้นในการแก้ไขข้อบกพร่องรอบ ๆ ด้วย call stack, เบรกพอยต์ (พร้อมเงื่อนไข), หน้าต่างทันที (หรือที่รู้จักในชื่อ prompt หรือ repl window), ตัวแปร 'watch' และสิ่งอื่น ๆ