ข้อบกพร่องที่สามารถหลีกเลี่ยงได้ด้วยมาตรฐานการเข้ารหัส [ปิด]

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

มาตรฐานการเข้ารหัสด้วยตนเองจะไม่ลดข้อบกพร่อง มาตรฐานการเข้ารหัสซึ่งเป็นส่วนหนึ่งของกระบวนการพัฒนาซอฟต์แวร์เสียงช่วยลดข้อบกพร่อง

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

• การลดข้อบกพร่องของซอฟต์แวร์ Top 10 Listซึ่งสำรวจการปรับปรุงในด้านวิศวกรรมซอฟต์แวร์เชิงประจักษ์ตั้งแต่ปี 1987
• การวิเคราะห์ที่สำคัญของกระบวนการข้อมูล PSPซึ่งศึกษาสถิติที่รวบรวมจากกระบวนการซอฟต์แวร์ส่วนบุคคลและผลกระทบของ PSP ต่อสาเหตุของข้อผิดพลาดซอฟต์แวร์ทั่วไป

การเข้ารหัส "มาตรฐาน" ... มีหลายพื้นที่ของการพัฒนาที่สามารถเป็นมาตรฐานได้ เรากำลังพูดถึงอนุสัญญาการเข้ารหัสเช่นมาตรฐานการตั้งชื่อ ฯลฯ หรือไม่? หรือว่าเรากำลังพูดถึงสิ่งที่ลึกกว่าเช่น TDD / BDD, CI ฯลฯ

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

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

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

เท่าที่การประชุมพื้นฐานการเข้ารหัสเช่นชื่อตัวแปรมาตรฐาน ฯลฯ ฉันได้พบว่าส่วนใหญ่จะมีประโยชน์น้อยกว่าและน่ารำคาญกว่า นี่เป็นมาตรฐานที่ "ยอดเยี่ยมเพราะมีให้เลือกมากมาย" สิ่งที่คุณเห็นว่าเป็นความแตกต่างระหว่างตัวระบุ PascalCased และ camelCased อาจไม่ใช่สิ่งที่คนอื่นคิด ขีดเส้นใต้นำหน้าขีดจำกัดความยาวชื่อ (หรือข้อกำหนดที่ชื่อวิธีการ / ฟิลด์บอกเล่าเรื่องราว) นอกเหนือจากอนุสัญญาที่บังคับใช้โดยคอมไพเลอร์หรือที่พบเห็นได้ทั่วไปในรหัสไลบรารีเฉพาะภาษา IDE สมัยใหม่สามารถบอกทุกสิ่งที่คุณจำเป็นต้องรู้เกี่ยวกับตัวแปรหรือฟังก์ชั่นรวมถึงว่าคุณควรหรือไม่ควรลองใช้มันเป็นพิเศษ สถานการณ์. นอกจากนี้การเรียกใช้การตรวจสอบการประชุมรหัสมักจะส่งคืนปัญหาเกี่ยวกับรหัสที่คุณไม่สามารถหรือไม่ได้ ไม่ต้องการเปลี่ยนแปลงเช่นห้องสมุดบุคคลที่สามที่ใช้ชุดมาตรฐานอื่นหรือรหัส interop ซึ่งอาจเป็นไปตามมาตรฐานการตั้งชื่อ Win API แทนมาตรฐานภาษาท้องถิ่นของคุณ คุณจะเพิ่ม cruft ลงในโค้ดของคุณเพื่อบอกเครื่องมือของคุณให้ละเว้น cruft ในโค้ดของคุณ

ช่องโหว่การฉีด SQL ทุกข้อเป็นข้อบกพร่องที่สามารถป้องกันได้ด้วยมาตรฐานการเข้ารหัส สถิติเกี่ยวกับช่องโหว่การฉีด SQL คือ AFAIK พร้อมให้ใช้งาน

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