บักสุดแสบทำเอกสารสคอฟฟิลด์ 90 ไฟล์ค้างสถานะไม่เสร็จชั่วนิรันดร์
นักพัฒนาพบข้อผิดพลาดจากเทมเพลตเอกสารที่เขียนเงื่อนไขการทำงานขัดแย้งกับตัวเอง ทำให้ไฟล์ที่เสร็จแล้วกว่า 37 ไฟล์ถูกระบบตีตกเป็นงานค้างนานหลายเดือน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- เอกสารสคอฟฟิลด์ 90 ไฟล์ถูกระบบตีตราค้างไว้ทั้งหมดเนื่องจากเงื่อนไขการตรวจสอบเป็นโมฆะ
- คำอธิบายวิธีใช้งานในเอกสารดันมีเครื่องหมายตรวจจับซ่อนอยู่ ทำให้ระบบตรวจพบว่ายังมีงานค้างเสมอ
- การแก้ไขทำได้เพียงบรรทัดเดียวโดยการเปลี่ยนไปอธิบายชื่อเครื่องหมายแทนที่จะใส่ค่าจริงเข้าไป
- ปัญหาลักษณะนี้เรียกว่า In-band signaling ซึ่งเคยเกิดขึ้นกับเครือข่ายโทรศัพท์ยุค 1960 มาก่อน
นักพัฒนาซอฟต์แวร์รายหนึ่งต้องเผชิญกับปัญหาชวนปวดหัว เมื่อระบบไปพลายน์ (pipeline) สำหรับสร้างโครงร่างเอกสารหรือสคอฟฟิลด์ (scaffold) จำนวน 90 ไฟล์ แสดงผลสถานะค้างว่าเป็นงานที่ยังไม่เสร็จสิ้นชั่วนิรันดร์ แม้ว่าเอกสารเหล่านั้นจะถูกมนุษย์กรอกข้อมูล ตรวจทาน และเผยแพร่ไปล่วงหน้าแล้วหลายสัปดาห์ก็ตาม ตัวเลขบนแดชบอร์ดที่แสดงงานค้างจำนวนมากนี้ไม่เคยลดลงเลย จนทำให้ผู้ดูแลระบบเริ่มชินชาและเพิกเฉยไปโดยปริยาย
ต้นตอของปัญหาซ่อนอยู่ในคำแนะนำการใช้งานที่ถูกสร้างขึ้นมาพร้อมกับไฟล์ ซึ่งเขียนระบุไว้ว่าให้ผู้ใช้งานทำตามรายการตรวจสอบเพื่อลบบรรทัดความคิดเห็น HTML ที่กำหนดสถานะร่างออกไป แต่ความผิดพลาดคือประโยคคำสั่งดังกล่าวดันบรรจุเครื่องหมายตรวจจับและอิโมจิรูปดินสอเอาไว้ตรงๆ ทำให้ทันทีที่ผู้ใช้งานปฏิบัติตามคำสั่งโดยการลบบรรทัดคอมเมนต์ทิ้งไป ระบบตรวจสเตจ (stage_of()) กลับยังคงตรวจพบสัญลักษณ์ดังกล่าวหลงเหลืออยู่ในประโยคคำอธิบายที่บอกว่าห้ามมีเครื่องหมายนั้นอยู่
เงื่อนไขการออกจากสถานะ (exit condition) ในกรณีนี้จึงกลายเป็นเงื่อนไขที่เป็นโมฆะอย่างสมบูรณ์ เพราะตัวเอกสารไม่สามารถอธิบายเกณฑ์ความสำเร็จของตัวเองได้โดยไม่ละเมิดเงื่อนไขนั้นเสียเอง ปัญหาดังกล่าวจัดอยู่ในประเภท In-band signaling หรือการส่งข้อมูลควบคุมผ่านช่องทางเดียวกับข้อมูลจริง ซึ่งมีลักษณะคล้ายคลึงกับปัญหาเสียงความถี่ 2600 Hz ในเครือข่ายโทรศัพท์เมื่อช่วงทศวรรษ 1960 ที่ระบบไม่สามารถแยกแยะระหว่างสัญญาณควบคุมสายว่างจากชุมสายกับเสียงที่มนุษย์เป่าปากใส่โทรศัพท์ได้
ปรากฏการณ์ In-band signaling มักเกิดขึ้นเมื่อระบบพยายามใช้งานช่องทางสื่อสารช่องทางเดียวสำหรับทั้งคำสั่งควบคุม (Control) และข้อมูลเนื้อหา (Payload) พร้อมๆ กัน ในมุมมองของการพัฒนาซอฟต์แวร์ บทเรียนนี้ชี้ให้เห็นความอันตรายของการออกแบบระบบที่ให้ 'ตัวข้อมูล' บรรยาย 'สถานะ' ของตัวเอง ซึ่งมักนำไปสู่เงื่อนไขวนลูปหรือ Bug ที่หายากเพราะโค้ดทำงานถูกต้องตามตัวอักษรแต่ขัดแย้งในเชิงตรรกะระดับระบบ การเขียน Unit Test ตรวจสอบพฤติกรรมจำลองจึงมีความสำคัญมากกว่าการพึ่งพาตรรกะที่ซับซ้อนเกินจำเป็น
แนวทางการแก้ไขทำได้ง่ายอย่างไม่น่าเชื่อโดยใช้เวลาแก้โค้ดเพียงบรรทัดเดียว ด้วยการปรับแก้คำอธิบายใหม่ให้บอกเล่าถึงลักษณะของเครื่องหมายแทนการใส่ค่าตัวอทันที เช่น การระบุให้ลบบรรทัดคอมเมนต์ระบุสถานะร่างที่อยู่ส่วนบนสุดของไฟล์แทนการใส่สัญลักษณ์ลงไปตรงๆ ผลลัพธ์จากการรันโปรแกรมตรวจสอบใหม่อีกครั้งทำให้ไฟล์จำนวน 37 จากทั้งหมด 90 ไฟล์พลิกสถานะจากยังไม่เสร็จเป็นเสร็จสิ้นทันที โดยที่ตัวเนื้อหาภายในไฟล์ไม่ได้มีการเปลี่ยนแปลงใดๆ เลย
"A freshly generated file must be completable by following its own instructions."
ผู้พัฒนาโปรเจกต์
สำหรับการป้องกันในระยะยาว นักพัฒนาแนะนำทางเลือกในการจัดการสถานะไว้ 3 ระดับความน่าเชื่อถือ ได้แก่ การแยกสถานะออกจากเพย์โหลดไปไว้ในไฟล์ไซด์คาร์ (sidecar) หรือฟรอนต์แมตต์เทอร์, การเลือกใช้สัญลักษณ์ที่ไม่สามารถเขียนขึ้นมาได้โดยบังเอิญสำหรับมนุษย์, หรือการยกเว้นพื้นที่บล็อกโค้ดไม่ให้ระบบเข้ามาตรวจจับ พร้อมทั้งแนะนำให้เขียนชุดทดสอบ (Unit Test) ตรวจสอบว่าไฟล์ที่ถูกสร้างขึ้นมาใหม่จะต้องสามารถทำตามคำแนะนำในตัวเองจนจบกระบวนการได้จริง เพื่อป้องกันไม่ให้เกิดปัญหาตัวเลขงานค้างทิพย์กวนใจในอนาคต
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น