จะเป็นโปรแกรมเมอร์แบบ zero-bug ได้อย่างไร? [ปิด]

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

ฉันจะเป็นโปรแกรมเมอร์ zero-bug ได้อย่างไรและรู้ว่าตัวละครทุกตัวในรหัสของฉันจะเป็นสาเหตุและส่งผลกระทบอย่างไร

อย่าเขียนโค้ดเลย

นั่นเป็นวิธีเดียวที่คุณสามารถเป็นโปรแกรมเมอร์แบบ zero-bug

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

ข้อบกพร่อง Zero เป็นไปไม่ได้สำหรับโปรแกรมที่ไม่สำคัญ

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

ซอฟต์แวร์นี้ไม่มีข้อบกพร่อง มันสมบูรณ์แบบสมบูรณ์แบบตามที่มนุษย์บรรลุ พิจารณาสถิติเหล่านี้: โปรแกรมสามเวอร์ชันสุดท้าย - ยาว 420,000 บรรทัด - มีข้อผิดพลาดเพียงข้อเดียว ซอฟต์แวร์รุ่น 11 ล่าสุดนี้มีข้อผิดพลาดทั้งหมด 17 ข้อ

ใช้การอัปเกรดซอฟต์แวร์เพื่ออนุญาตให้รถรับส่งนำทางด้วย Global Positioning Satellites การเปลี่ยนแปลงที่เกี่ยวข้องกับโปรแกรมเพียง 1.5% หรือรหัส 6,366 บรรทัด ข้อมูลจำเพาะสำหรับการเปลี่ยนแปลงหนึ่งครั้งนั้นมี 2,500 หน้าซึ่งเป็นปริมาณที่หนากว่าสมุดโทรศัพท์ ข้อกำหนดสำหรับโปรแกรมปัจจุบันเติม 30 วอลุ่มและรัน 40,000 หน้า

"Zero-bug โปรแกรมเมอร์" เป็น oxymoron เหมือนนักร้องเงียบ ๆ แต่เมื่อผ่านไป 60 ปีของการเขียนโปรแกรมทำให้เกิดปัญญากลั่นขึ้นมาบ้างซึ่งจะทำให้คุณเป็นโปรแกรมเมอร์ที่ดีขึ้นเช่น:

• เป็นคนอ่อนน้อมถ่อมตน - คุณและจะทำผิดพลาด ซ้ำแล้วซ้ำเล่า
• ระวังขนาดกะโหลกที่มีอยู่อย่าง จำกัด เข้าหาภารกิจด้วยความถ่อมใจอย่างเต็มที่และหลีกเลี่ยงการใช้เล่ห์เหลี่ยมอย่างโรคระบาด [Edsger Dijkstra]
• ต่อสู้กับการระเบิดแบบ combinatorial
• กำจัดสถานะที่ไม่แน่นอน (เท่าที่จะทำได้) ใช่เรียนรู้การเขียนโปรแกรมใช้งานได้
• ลดจำนวนเส้นทางรหัสที่เป็นไปได้
• ทำความเข้าใจกับขนาดของช่องว่างอินพุทและเอาท์พุท (ของฟังก์ชั่นของคุณ) และลองลดขนาดเพื่อให้ได้การทดสอบที่ครอบคลุมมากขึ้น 100%
• สมมติว่ารหัสของคุณใช้งานไม่ได้ - พิสูจน์เป็นอย่างอื่น!

TDD

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

วิธีการ TDD ให้ประโยชน์อย่างน้อยสองประการ

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

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

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

ฉันเชื่อว่าทีมพัฒนาที่ดีที่ TDD ส่งมอบรหัสมีข้อบกพร่องน้อยที่สุด

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

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

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

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

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

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

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

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

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

มันยากเป็นพิเศษที่จะได้รับรหัสปราศจากข้อบกพร่องในสภาพแวดล้อมการเขียนโปรแกรมหลัก (Java, C #, PHP, ฯลฯ ) ฉันจะมุ่งเน้นไปที่การสร้างรหัสที่ผ่านการทดสอบอย่างดีและมีการตรวจสอบโดยเพื่อนในการทำซ้ำแบบควบคุมระยะสั้น

การรักษาโค้ดให้ง่ายที่สุดเท่าที่จะทำได้จะช่วยให้คุณหลีกเลี่ยงข้อบกพร่อง

ตรวจสอบให้แน่ใจว่าคุณกำลังใช้เครื่องมือวิเคราะห์รหัส (เช่นFindBugs , PMDและอื่น ๆ ) ซึ่งรวมกับคำเตือนของคอมไพเลอร์ที่เข้มงวดซึ่งจะแสดงปัญหาทั้งหมดเกี่ยวกับรหัสของคุณ จดบันทึกสิ่งที่พวกเขากำลังบอกคุณพยายามอย่างแท้จริงที่จะเข้าใจว่าลักษณะของบั๊กคืออะไรจากนั้นทำตามขั้นตอนในการเปลี่ยนสำนวนการเขียนโปรแกรมของคุณเพื่อให้รู้สึกผิดปกติกับโค้ดในลักษณะที่แนะนำบั๊กนั้นอีกครั้ง

ทั้งหมด "อย่ารหัสเลย" คำตอบหายไปอย่างสมบูรณ์จุด นอกจากนี้เจ้านายของคุณก็ไม่ได้เป็นคนปัญญาอ่อนแน่นอน!

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

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

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

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

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

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

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

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

อย่าเขียนอะไรที่ซับซ้อนกว่า "Hello World!" หรือถ้าคุณบอกให้ทุกคนไม่ใช้มัน

ถามหัวหน้าของคุณสำหรับตัวอย่างนี้เรียกว่ารหัสฟรีบั๊ก

ฉันเห็นด้วยกับคนอื่น นี่คือวิธีที่ฉันจะแก้ไขปัญหา

• รับผู้ทดสอบ ดูสาเหตุทดสอบของโจเอล
• ใช้ห้องสมุดอย่างกว้างขวาง อาจจะดีกว่าดีบั๊ก ฉันเป็นแฟนตัวยงของ CPAN สำหรับ Perl

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

• ใช้เทคนิคการทดสอบที่หลากหลาย (อื่น ๆ ที่ ATDD)
• สร้างการตรวจสอบอย่างเป็นทางการของซอฟต์แวร์ของเรา
• มีทีมงาน QA แยกต่างหาก
• ทำการวิเคราะห์อย่างหนักเกี่ยวกับการเปลี่ยนแปลงแต่ละครั้งที่เกิดขึ้นกับฐานของรหัส
• ใช้ภาษาที่โน้มตัวต่อความปลอดภัยและความระมัดระวังมากขึ้น

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

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

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

ฉันคิดว่าขั้นตอนแรกที่ดีในการเป็นโปรแกรมเมอร์ "zero-bug" คือการเปลี่ยนทัศนคติของคุณที่มีต่อข้อบกพร่อง แทนที่จะพูดในสิ่งที่ "พวกเขาเกิดขึ้น" "รับ QA และผู้ทดสอบที่ดีขึ้น" หรือ "นักพัฒนาดูดการทดสอบ" พูดว่า:

ข้อบกพร่องไม่ได้รับการยอมรับและฉันจะทำทุกอย่างภายในอำนาจของฉันเพื่อกำจัดพวกเขา

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

เรียกได้ว่าเจ้านายของคุณพูดถูก เป็นไปได้ที่จะเขียนซอฟต์แวร์ที่เข้าใกล้ข้อบกพร่องเป็นศูนย์

แต่ปัญหาคือค่าใช้จ่ายในการเขียนโปรแกรม zero-bug เกือบจะสูงมาก คุณต้องทำสิ่งต่าง ๆ เช่น:

• ใช้ข้อกำหนดที่เป็นทางการตามข้อกำหนดของคุณ เป็นทางการเช่นเดียวกับการใช้ Z หรือ VDM หรือสัญลักษณ์ทางเสียงอื่น ๆ

• ใช้เทคนิคการพิสูจน์ทฤษฎีบทเพื่อพิสูจน์อย่างเป็นทางการว่าโปรแกรมของคุณใช้ข้อมูลจำเพาะ

• สร้างชุดหน่วยการถดถอยและชุดทดสอบระบบและสายรัดเพื่อทดสอบข้อบกพร่องทุกอย่าง (และนี่ก็ไม่เพียงพอในตัวเอง)

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

มันไม่น่าเป็นไปได้อย่างยิ่งที่เจ้านายของคุณพร้อมที่จะจ่ายเงินทั้งหมดนี้ ... หรืออดทนต่อเวลาที่ต้องทำทั้งหมด

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

นี่คือขั้นตอนในการสร้างบั๊กโปรแกรมฟรี:

1. อย่าเริ่มการเข้ารหัสเว้นแต่คุณจะมีข้อกำหนดคุณลักษณะของ UNAMBIGUOUS
2. ห้ามทดสอบหรือหรือถ้าคุณไม่เชื่อมั่นในการทดสอบเพื่อตรวจจับข้อบกพร่องในซอฟต์แวร์
3. ใช้ข้อเสนอแนะทั้งหมดจากข้อบกพร่องที่ค้นพบระหว่างการทดสอบรีวิวและการผลิตกับกระบวนการและนักพัฒนาที่ใส่ข้อบกพร่องตั้งแต่แรก ทิ้งส่วนประกอบที่ชำรุดทั้งหมดโดยสมบูรณ์ทันทีที่พบข้อบกพร่อง อัปเดตรายการตรวจสอบของคุณและฝึกฝนนักพัฒนาของคุณเพื่อไม่ให้ทำผิดพลาดอีกครั้ง

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

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

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

โปรแกรมป้องกัน: http://en.wikipedia.org/wiki/Defensive_programming

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

สิ่งนี้อาจเป็นผลมาจากการเข้าใจผิดเกี่ยวกับวิธีการที่ดีไม่ใช่แค่อาการปวดฟันทั่วไป

สิ่งที่ฉันหมายถึงคือเป็นไปได้ว่าเจ้านายของคุณได้ยิน"วิธีการเป็นศูนย์ข้อบกพร่อง" (ดูหัวข้อที่ 5) และไม่เข้าใจว่ามันหมายถึงอะไร
แน่นอนว่ามันไม่สะดวกสำหรับการจัดการที่จะเลื่อนการพัฒนาฟีเจอร์ใหม่ ๆ ลงไปในข้อผิดพลาดที่คุณไม่ควรใส่ ...
และแน่นอนมันเป็นสิ่งที่คุกคามโบนัสของเขาดังนั้นแน่นอนว่าคุณจะไม่ได้รับเพราะ "โปรแกรมเมอร์ที่ดี มีข้อบกพร่อง "...

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

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

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

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

การพัฒนาซอฟต์แวร์ของพวกเขาและเมื่อพวกเขามาถึงระดับของข้อบกพร่องที่มีลำดับความสำคัญต่ำพวกเขาเพียงแค่เปิดตัวผลิตภัณฑ์และแก้ปัญหาในภายหลัง

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

บั๊กนั้นหลีกเลี่ยงไม่ได้เช่นเดียวกับธรรมชาติของมนุษย์ที่จะทำผิด

ไม่มีข้อบกพร่องเหมือนกับการมีระบบความปลอดภัย 100% หากระบบมีความปลอดภัย 100% แน่นอนว่าไม่มีประโยชน์อีกต่อไป (อาจอยู่ภายในคอนกรีตตันและตันและไม่ได้เชื่อมต่อกับภายนอกเลยไม่ใช่แบบมีสายหรือไร้สายเช่นเดียวกับที่ไม่มีระบบความปลอดภัยที่สมบูรณ์แบบ ไม่มีระบบที่ไร้ข้อบกพร่องที่ซับซ้อน

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

ฉันคิดว่าคุณสามารถเขียนโปรแกรมที่ไม่มีบั๊กได้ แต่โดยทั่วไปแล้วเป็นโปรแกรมที่คุณเขียนไปแล้ว 10 หรือ 12 ครั้ง ครั้งที่ 13 ที่คุณเขียนโปรแกรมเดียวกันตั้งแต่เริ่มต้นคุณรู้วิธีที่จะทำ: คุณรู้ปัญหาคุณรู้เทคนิคคุณรู้จักห้องสมุดภาษา ... คุณเห็นมันในใจของคุณ รูปแบบทั้งหมดอยู่ที่นั่นในทุกระดับ

สิ่งนี้เกิดขึ้นกับฉันด้วยโปรแกรมที่ง่ายมากเพราะฉันสอนการเขียนโปรแกรม มันง่ายสำหรับฉัน แต่ยากสำหรับนักเรียน และฉันไม่ได้พูดถึงวิธีแก้ปัญหาที่ฉันทำหลาย ๆ ครั้งในกระดานดำ แน่นอนฉันรู้สิ่งเหล่านั้น ฉันหมายถึงโปรแกรมประมาณ 300 บรรทัดที่แก้ปัญหาโดยใช้แนวคิดที่ฉันรู้จักดี (แนวคิดที่ฉันสอน) ฉันเขียนโปรแกรมเหล่านี้โดยไม่มีการวางแผนและพวกเขาก็ใช้งานได้และฉันรู้สึกว่าฉันรู้รายละเอียดทั้งหมดฉันไม่ต้องการ TDD เลย ฉันได้รับข้อผิดพลาดในการรวบรวมสองหรือสาม (ส่วนใหญ่พิมพ์ผิดและสิ่งอื่น ๆ เช่นนั้น) และที่มัน ฉันสามารถทำสิ่งนี้สำหรับโปรแกรมขนาดเล็กและฉันก็เชื่อว่าบางคนสามารถทำเช่นนั้นสำหรับโปรแกรมที่ซับซ้อนมากขึ้น ฉันคิดว่าคนอย่าง Linus Torvalds หรือ Daniel J. Bernstein มีความชัดเจนในใจพวกเขาเป็นคนใกล้ชิดที่สุดที่คุณจะได้รับรหัสปราศจากข้อผิดพลาด ถ้าคุณเข้าใจสิ่งต่าง ๆ อย่างลึกซึ้งฉันคิดว่าคุณสามารถทำได้ ฉันทำได้เฉพาะโปรแกรมง่ายๆเท่านั้นอย่างที่ฉันพูด

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

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

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

ข้อบกพร่อง imho และสิ่งประดิษฐ์ขั้นตอนวิธีที่ไม่แน่นอนต้องปรากฏขึ้นในระหว่างขั้นตอนการเข้ารหัส: พวกเขาสร้างแรงบันดาลใจและบังคับให้มีการวิวัฒนาการของรหัส
อย่างไรก็ตามเป็นไปได้ (โดยปกติหลังจากการทดสอบบางอย่าง) เพื่อตรวจสอบตัวแปรทุกตัวที่อาจใช้ก่อนการประกาศเพื่อจัดการข้อผิดพลาดทุกที่ที่อาจปรากฏ - เพื่อทำให้โปรแกรมเป็นศูนย์ข้อผิดพลาด ... จนกว่าคุณจะได้รับคำขอสำหรับคุณสมบัติที่พิจารณาแล้ว เป็นไปไม่ได้เมื่อคุณพูดถึงสถาปัตยกรรมของโปรแกรม;)

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

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

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

ฉันคิดว่ามันมีรสนิยมที่ดีเกี่ยวกับโค้ดซึ่งคุณสามารถพัฒนาด้วยการฝึกฝนและทบทวนและการอ่านเกี่ยวกับคนที่มีปัญหาคล้ายกัน

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

ถ้าฉันหมายถึง: "ศูนย์บั๊กขณะเขียนโค้ด" -> นั่นเป็นเป้าหมายที่ดี แต่เป็นไปไม่ได้

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

สิ่งที่คุณต้องมีคือ: คุณภาพของรหัสสูงอย่างไม่น่าเชื่อและอยู่ใกล้การทดสอบ 100% (การทดสอบหน่วย + การทดสอบการยอมรับ + ​​การทดสอบการรวม)

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

ก่อนอื่นคุณต้องมีหัวหน้าที่สนใจในคุณภาพและเต็มใจที่จะจ่ายให้

ทางออกของโปรแกรมเมอร์:

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

ทางออกของผู้ใช้:

• หยุดใช้คอมพิวเตอร์
• ทำทุกอย่างด้วยตนเอง
• ให้บุคคลที่สองตรวจสอบผลลัพธ์เสมอ

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

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