สามคนในคลาสที่นั่งได้คนเดียว

เจ้าของสถาบันทักมาว่า คาบฟิสิกส์ตัวต่อตัวของครูคนหนึ่ง เช้าวันเสาร์ ขึ้นว่ามีนักเรียนเข้าเรียนสามคน

คลาสตัวต่อตัวมีความจุเท่ากับหนึ่ง ตัวเลขนี้จึงเป็นไปไม่ได้

สมมติฐานแรกผิด

ผมเคยแก้บั๊กเรื่องการรวม roster ผิดไปแล้วเมื่อห้าวันก่อน สิ่งแรกที่คิดคือมันกลับมา

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

ความจริงคือ มีคนกดเช็กชื่อแบบ bulk ผิด: Win (คาบ 9 โมงของเขาเอง — ถูกต้อง) ถูกเช็กชื่อพร้อมกับ Mark และ Don ที่จริง ๆ เรียนคาบ 12:00 กับ 16:30 ทั้งสามคนถูกบันทึกเข้าไปในคาบของ Win

แล้วผมเจอคาบผีอีกหนึ่งคาบที่ 14:30 ที่ไม่มีใครเรียนจริง ๆ สักคน มีชื่อสามคนเดียวกันติดอยู่ สร้างขึ้นหลังคาบแรก 0.3 วินาที — คือพลาดชุดเดียวกัน

สิ่งที่ทำ (และลำดับที่ทำ)

ก่อนแตะอะไรทั้งสิ้น ผมยืนยันกับเจ้าของก่อนว่านี่คือการกดผิด ไม่ใช่การเข้าเรียนจริง เพราะถ้าลบผิด แปลว่าผมเพิ่งลบหลักฐานว่ามีคนเรียนไปแล้ว

จากนั้น:

ลบ record การเข้าเรียนที่ผิด 5 รายการ พร้อมคืนจำนวนคาบในแพ็กเกจให้นักเรียนแต่ละคนให้ถูกต้อง
ลบคาบผีที่ 14:30
รัน audit ทั้งระบบ

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

เหตุการณ์เดี่ยว ไม่ใช่รูปแบบ

เครื่องมือที่ใช้แล้วทิ้ง

ผมแก้ด้วยการเพิ่ม admin route ชั่วคราวขึ้นมาใช้ครั้งเดียว แล้วลบทิ้งทันทีหลังใช้เสร็จ เป็นแพตเทิร์นเดียวกับที่ใช้ตอนต้อง resync rich menu ทั้งระบบ

ข้อดีคือได้เครื่องมือที่พอดีกับงาน ทำงานบนข้อมูลจริงพร้อม transaction และไม่ทิ้งประตูหลังค้างไว้ใน production

สิ่งที่เรียนรู้

ยืนยันกับคนก่อนแก้ข้อมูล ความเร็วในการแก้ไม่ได้มีค่าอะไรเลยถ้าแก้ผิดด้าน

แก้แล้วต้องกวาดต่อ คำถามที่สำคัญกว่า "แก้ได้ไหม" คือ "มีที่อื่นอีกหรือเปล่า" และคำตอบนั้นควรเป็นตัวเลข ไม่ใช่ความรู้สึก

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