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

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

ตัวเลขที่เป็นรูปธรรมเพียงอย่างเดียวที่มีอยู่มาจากหนังสือปี 1995 โดย Dr. Flaviu Cristian ซึ่งประเมินว่าการจัดการข้อผิดพลาดมักจะคิดเป็นมากกว่าสองในสามของโค้ดในระบบที่ใช้งานจริง เกือบสามทศวรรษต่อมา นี่ยังคงเป็นจุดอ้างอิงเชิงปริมาณเพียงจุดเดียวในอุตสาหกรรมที่มีความซับซ้อนและกระจายตัวมากขึ้น

สstatisticsหลักจากงานวิจัยที่มีอยู่:

• การจัดการข้อผิดพลาดคิดเป็นมากกว่าสองในสามของโค้ดในระบบที่ใช้งานจริง (การศึกษาปี 1995 โดย Dr. Flaviu Cristian )
• นักพัฒนาใช้เวลาประมาณ 11% ในการดีบักและแก้ไขบักโดยเฉลี่ย
• บางวันใช้เวลาถึง 32% สำหรับงานดีบัก
• กิจกรรมการทดสอบสามารถใช้เวลาของนักพัฒนาได้ถึง 16%
• บริษัทต่างๆ อ้างว่าสูญเสีย 2 ล้านล้านดอลลาร์สหรัฐฯ เนื่องจากบักในปี 2020

บริษัทหลีกเลี่ยงการวัดสิ่งที่ไม่ต้องการให้ทุน

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

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

ความท้าทายในการวัดไปไกลกว่าการติดตามแบบง่ายๆ

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

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

แนวทางการจัดการข้อผิดพลาดที่แตกต่างกัน:

• Result Types: ต้องพิจารณาความล้มเหลวในทุกขั้นตอน การพัฒนาในช่วงแรกใช้เวลานานกว่า แต่ได้โค้ดที่แข็งแกร่งกว่า
• Exception-Based: มุ่งเน้นที่เส้นทางที่ราบรื่นก่อน จัดการข้อผิดพลาดเมื่อพบระหว่างการทดสอบ
• ปัจจัยที่ต้องชั่งน้ำหนัก: ต้นทุนของความล้มเหลว ความยากในการบำรุงรักษาในอนาคต ความง่ายในการปรับใช้การแก้ไข

อุตสาหกรรมให้ความสำคัญกับความเร็วมากกว่าความยืดหยุน

พลวัตตลาดปัจจุบันสนับสนุนการพัฒนาฟีเจอร์อย่างรวดเร็วมากกว่าการเสริมความแข็งแกร่งของซอฟต์แวร์ ในสภาพแวดล้อมที่ขับเคลื่อนด้วย venture capital บริษัทมักเลือกที่จะขยายโครงสร้างพื้นฐานแทนการปรับปรุงโค้ด เพิ่มกลไกการลองใหม่แบบง่ายๆ แทนการใช้ fault tolerance ที่เหมาะสม และพึ่งพา bug bounties แทนการลงทุนในความปลอดภัยตั้งแต่เริ่มต้น

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

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

การวิจัยมุ่งเน้นปัญหาทางวิชาการในขณะที่เพิกเฉยต่อคำถามเชิงปฏิบัติ

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

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

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

อ้างอิง: Time Spent on Hardening