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

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ระบบ Audit รายงานผลเป็น AHEAD ทั้งที่ตรวจสอบไป 0 ไฟล์และ 0 คลัสเตอร์
- สาเหตุจากตัวส่วนเป็นศูนย์ทำให้ตรรกะประเมินผลกลายเป็นจริงโดยอัตโนมัติ
- ทางแก้ต้องแยกการตรวจสอบการแจกแจงออกจากผลการตัดสินด้วยสถานะ VOID
- ฝากข้อคิดก่อนเชื่อผลทดสอบว่าควรตรวจสอบจำนวนข้อมูลตั้งต้นเสมอ
นักพัฒนาซอฟต์แวร์รายหนึ่งได้ออกมาเปิดเผยบทเรียนราคาแพงเกี่ยวกับระบบตรวจสอบโค้ดหรือ Audit ของตนเอง ซึ่งแสดงผลการทำงานออกมาเป็น AHEAD ทั้งที่มีการตรวจสอบ 0 ไฟล์ 0 คลัสเตอร์ และไม่มีไฟล์สรุปผลปรากฏอยู่เลย โดยระบบระบุข้อมูลว่า clusters=0, files=0, judged=0/0, open=0 และ claim=AHEAD สรุปผลว่าเฟสการทำงานนั้นล้ำหน้ากว่าระบบที่นำมาเทียบเคียง
ข้อผิดพลาดนี้ไม่ได้เกิดจากบั๊กในการเปรียบเทียบข้อมูลแต่อย่างใด เนื่องจากตัวเลขทุกตัวถูกต้องตามหลักการคำนวณ การที่ judged=0/0 เป็นจริงสำหรับสิ่งที่มีจำนวนศูนย์ชิ้น ส่งผลให้ open=0 ตามมา และกฎที่กำหนดว่าระบบจะล้ำหน้าเมื่อไม่มีรายการที่ค้างอยู่ก็ทำงานบนชุดข้อมูลว่างเปล่าได้อย่างถูกต้องตามที่เขียนไว้ทุกประการ มีเพียงเฟสเดียวที่รอดพ้นจากปัญหานี้เนื่องจากมีบล็อกโค้ดให้ตรวจสอบถึง 603 บล็อก ทำให้ค่า open มากกว่าศูนย์และไม่สามารถสร้างคำกล่าวอ้างดังกล่าวได้
ในทางวิทยาศาสตร์ข้อมูลและวิศวกรรมซอฟต์แวร์ ปรากฏการณ์นี้เรียกว่า Vacuous Truth หรือความจริงเชิงสุญญากาศ ซึ่งเกิดขึ้นเมื่อเงื่อนไขตรรกะเป็นจริงได้โดยอัตโนมัติเนื่องจากขอบเขตข้อมูลเป็นศูนย์ การที่ระบบอัตโนมัติไม่แยกแยะระหว่าง 'การตรวจสอบแล้วไม่พบข้อผิดพลาด' กับ 'ไม่ได้ทำการตรวจสอบเลย' ถือเป็นหลุมพรางอันตรายที่มักตบตาผู้พัฒนาได้ง่ายที่สุดเพราะตัวเลขทางคณิตศาสตร์ไม่มีความผิดพลาดให้เห็น
ปัญหาที่น่ากลัวกว่าผลลัพธ์ที่ผิดพลาดทั่วไปคือ หน้าตาของรายงานไม่มีจุดไหนที่ดูผิดปกติเลย ไม่มีตัวเลขที่สูงเกินจริงหรือผลลัพธ์ที่ดูน่าสงสัย ตัวเลขศูนย์คือรายงานที่ตรงไปตรงมาของรอบการรันที่ว่างเปล่า และผลการตัดสินถูกสร้างขึ้นจากกฎที่ไม่เคยตรวจสอบด้วยซ้ำว่ารอบการรันนั้นเกิดขึ้นจริงหรือไม่ จนกระทั่งผู้พัฒนาเผลอนำผลลัพธ์ดังกล่าวไปอ้างอิงต่อในที่อื่น

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
แนวทางแก้ไขที่ผู้พัฒนาเสนอคือการเพิ่มสถานะ VOID หรือสถานะที่ไม่ผ่านการวัดผลแยกออกมาต่างหาก เพื่อไม่ให้ปะปนกับสถานะผ่านหรือล้มเหลว โดยแยกกระบวนการตรวจสอบออกเป็นสองส่วนอย่างเด็ดขาด ได้แก่:
- enumerate(): ตรวจสอบว่ามีซอร์สโค้ดอยู่จริงและอ่านได้หรือไม่ โดยไม่สนใจว่าข้างในมีเนื้อหาอะไร
- judge(): ประเมินว่าจากข้อมูลที่แจกแจงมา มีสัดส่วนที่ผ่านการตรวจสอบมากน้อยแค่ไหน
บทเรียนสำคัญจากเหตุการณ์นี้คือ ระบบสีเขียวหรือผลลัพธ์ที่แสดงว่าผ่านคือสิ่งที่เราต้องตั้งคำถามมากที่สุด ระบบตรวจสอบที่ไม่เคยล้มเหลวเลยแปลว่ามันไม่เคยทำงานจริง และก่อนที่จะเชื่อถือผลการตรวจสอบใด ๆ คำถามสำคัญไม่ใช่การดูว่าตัวเลขถูกต้องหรือไม่ แต่คือตัวเลขนั้นมาจากข้อมูลจำนวนเท่าไหร่ และผลลัพธ์จะเปลี่ยนเป็นอย่างไรเมื่อจำนวนข้อมูลตั้งต้นเท่ากับศูนย์
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น