คุณกำลังขอ Holy Grail ของวิศวกรรมซอฟต์แวร์และยังไม่มีใครตอบคำถามนี้ได้
สิ่งที่สำคัญคือคุณต้องติดตามประเภทของข้อผิดพลาดที่คุณทำแล้วทำการวิเคราะห์ข้อผิดพลาดเหล่านั้นเพื่อพิจารณาว่ามีแนวโน้มที่พบบ่อยหรือไม่ การวิเคราะห์สาเหตุที่แท้จริงเป็นชื่อทางการของวิปัสสนาชนิดนี้และมีเนื้อหามากมายในเว็บที่เกี่ยวข้อง
ผู้เชี่ยวชาญใช้ระบบติดตามบั๊กเพื่อให้พวกเขาสามารถ (1) รู้ว่าต้องแก้ไขอะไร แต่ยัง (2) วิเคราะห์ว่าต้องแก้ไขอะไรหลังจากข้อเท็จจริง คุณไม่จำเป็นต้องเป็นทางการมากนักเพียงแค่การนับคะแนนในสมุดบันทึกอาจเป็นเรื่องที่ดีสำหรับคุณ
ข้อบกพร่องขั้นตอนการออกแบบ
หากคุณพบว่าข้อผิดพลาดส่วนใหญ่เกิดจากความเข้าใจผิดของคำแถลงปัญหาหรือหากคุณพบว่าคุณเลือกอัลกอริทึมหรือเส้นทางที่ไม่ถูกต้องเพื่อติดตามการแก้ไขปัญหาของคุณคุณมีปัญหาในขั้นตอนการออกแบบ
มันจะทำให้คุณต้องใช้เวลามากขึ้นในช่วงเริ่มต้นของโครงการและเขียนสิ่งที่ต้องทำและวิธีที่ควรทำ ตรวจสอบงานนี้อย่างรอบคอบและทบทวนปัญหาต้นฉบับและพิจารณาว่าคุณกำลังแก้ไขปัญหาอย่างถูกต้องหรือไม่ การเริ่มต้นหนึ่งหรือสามชั่วโมงพิเศษอาจช่วยให้คุณประหยัดเวลาได้หลายชั่วโมง
ข้อผิดพลาดในการเข้ารหัส
หากการออกแบบของคุณมั่นคง แต่คุณต้องต่อสู้กับภาษาที่คุณเข้ารหัสอยู่เสมอลองหาเครื่องมือที่จะวิเคราะห์โค้ดของคุณและเตือนคุณตั้งแต่เนิ่นๆและบ่อยครั้งที่คุณทำผิดพลาด
หากคุณกำลังเขียนโปรแกรมใน C ให้เปิดคำเตือนคอมไพเลอร์ทั้งหมดใช้ semantic checker like lintและใช้เครื่องมือเช่นvalgrindเพื่อตรวจจับปัญหาที่เกี่ยวข้องกับหน่วยความจำแบบไดนามิกทั่วไป
หากคุณกำลังเขียนโปรแกรม Perl เปิดstrictและwarningsและระวังสิ่งที่กล่าว
ไม่ว่าคุณจะใช้ภาษาใดอาจมีเครื่องมือมากมายที่ช่วยคุณตรวจจับข้อผิดพลาดทั่วไปก่อนที่คุณจะถึงขั้นตอนการดีบัก
บูรณาการข้อบกพร่องขั้นตอน
ในขณะที่คุณพัฒนาโค้ดของคุณตามแนวทางการแยกส่วนที่ดีคุณจะต้องเริ่มติดกาวชิ้นส่วนต่างๆเข้าด้วยกัน ตัวอย่างเช่นส่วนต่าง ๆ ของรหัสของคุณอาจเกี่ยวข้องกับการป้อนข้อมูลของผู้ใช้การโต้ตอบกับฐานข้อมูลการแสดงข้อมูลอัลกอริทึม / ตรรกะและแต่ละส่วนเหล่านี้ถูกสร้างขึ้นโดยไม่ขึ้นอยู่กับอีกฝ่ายหนึ่ง แทนที่จะกังวลเกี่ยวกับการรวมเข้ากับทุกสิ่ง)
นี่คือจุดที่การพัฒนาทดสอบขับเคลื่อน (TDD) มีประโยชน์มาก แต่ละโมดูลของรหัสของคุณสามารถมีการทดสอบที่ตรวจสอบว่าพวกเขาทำงานตามวิธีการออกแบบ การทดสอบเหล่านี้ควรจะเขียนขึ้นก่อนหรือเร็วในกระบวนการเพื่อให้คุณมีชุด "ผู้ช่วยเหลือ" เพื่อให้คุณซื่อสัตย์ เมื่อคุณเริ่มทำทุกอย่างทำงานร่วมกันและคุณพบว่าคุณต้องเปลี่ยนวิธีการใช้งานหรือการโต้ตอบกับระบบย่อยอื่นคุณสามารถถอยกลับไปที่การทดสอบเพื่อให้แน่ใจว่าสิ่งที่คุณทำ ทุกอย่างทำงานร่วมกันไม่ทำลายความถูกต้องของรหัส
และอื่น ๆ ...
เลือกซื้อหนังสือเกี่ยวกับวิศวกรรมซอฟต์แวร์และเทคนิคการเขียนโค้ดเชิงปฏิบัติแล้วคุณจะได้เรียนรู้วิธีการต่าง ๆ ในการพัฒนาความวุ่นวายน้อยลงและเชื่อถือได้มากขึ้น นอกจากนี้คุณยังจะพบว่าประสบการณ์เก่า ๆ ที่เรียบง่าย - รับปริญญาจากโรงเรียนที่มีความทุกข์ยากจะทำให้คุณมีรูปร่างที่ดี
สิ่งที่เกือบทุกอย่างทยอยลงคือการมีเวลาน้อยและการทำงานล่วงหน้าจ่ายเป็นเงินปันผลจำนวนมหาศาลในภายหลังในกระบวนการพัฒนา / วางจำหน่าย
ความจริงที่ว่าคุณสังเกตเห็นปัญหาเหล่านี้ตั้งแต่ต้นในอาชีพการงานของคุณพูดได้ดีสำหรับอนาคตของคุณและฉันขอให้คุณโชคดีที่สุด