ผมตรวจระบบของตัวเอง แล้วเจอบั๊ก 11 ตัว

เจ้าของสถาบันถามคำถามที่ตอบยากกว่าที่คิด: "ระบบมันทำงานถูกจริงหรือเปล่า"

เทสต์ผ่านหมด production ก็ไม่ล่ม แต่คำถามของเขาไม่ได้แปลว่า "มี exception ไหม" เขากำลังถามว่า "กฎในหัวฉัน กับกฎในโค้ด มันตรงกันหรือเปล่า"

ซึ่งเทสต์ตอบไม่ได้ เพราะเทสต์ยืนยันแค่ว่าโค้ดทำสิ่งที่ผมคิดว่าควรทำ ไม่ได้ยืนยันว่าสิ่งที่ผมคิดนั้นถูก

วิธีที่ใช้

ผมนั่งอ่าน route, lib และ middleware ของ backend ทั้งหมด ทีละไฟล์ แล้วเขียนลงเอกสารว่า "ในโค้ดจริง ฟีเจอร์นี้ตัดสินใจยังไง" — ไม่ใช่ว่าควรตัดสินใจยังไง

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

ผลคือบั๊กที่ยืนยันได้ 11 ตัว ที่ผมไม่เคยรู้มาก่อน ตัวที่หนักสุด:

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

ทุกตัวคือเรื่องเงินหรือสิทธิ์การเข้าถึงข้อมูล ไม่มีตัวไหนที่ทำให้ระบบ crash — ซึ่งเป็นเหตุผลว่าทำไมมันถึงรอดสายตามาได้นาน

ส่วนที่ไม่ใช่บั๊ก

นอกจากบั๊ก ผมได้คำถามอีก 7 ข้อที่ไม่ใช่ปัญหาทางเทคนิค แต่เป็นการตัดสินใจทางธุรกิจที่ไม่มีใครเคยตอบ เช่น

นักเรียนขาดเรียนโดยไม่มีแพ็กเกจ จะคิดเงินไหม
เรียนชดเชยแบบตัวต่อตัว ครูได้ค่าสอนเท่าไร

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

สิ่งที่ตามมา

บั๊กทั้ง 11 ตัวถูกแก้ในวันเดียวกัน พร้อม regression test ที่ยิงกับฐานข้อมูลจริง คำถามทั้ง 7 ข้อถูกตอบและเขียนลงโค้ด เอกสาร audit ยังอยู่ใน repo พร้อมตารางสถานะของทุกข้อ

และคู่มือผู้ใช้ก็กลายเป็น GitBook 38 หน้า ที่มีหมวด "Logic ของระบบ" อธิบายว่าแต่ละฟีเจอร์ตัดสินใจยังไงจริง ๆ — อ่านจากโค้ด ไม่ใช่จากความทรงจำ

บทเรียน

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

ถ้าระบบของคุณเกี่ยวกับเงิน ผมแนะนำให้ทำอย่างน้อยปีละครั้ง