เราทำอะไรกัน

• เพิ่มฟีเจอร์ใหม่บน ระบบที่มีคนใช้งานอยู่จริง
• เจอปัญหาจริงระหว่างทาง — แก้ทีละเคส
• โจทย์หลัก: เพิ่มของใหม่ โดยไม่ทำของเดิมพัง

หลักการเหล่านี้ใช้ได้ไม่ว่าธุรกิจคุณคืออะไร

วงจรการทำงาน (ทำซ้ำทุกครั้ง)

• อ่านก่อนเขียน · ใช้ของเดิมซ้ำก่อนสร้างใหม่
• ทดสอบจริงก่อนบอกว่า "เสร็จ"

สร้างของใหม่ จากของที่มีอยู่

แจกของให้ลูกค้า กดครั้งเดียวจบ

ปุ่มใช้ได้บางเครื่อง ไม่ได้บางเครื่อง

บทเรียน: ทดสอบบนอุปกรณ์จริงของลูกค้า ไม่ใช่แค่บนเครื่องเรา

ระบบอัตโนมัติ "ไม่ตอบสนอง"

ตั้งค่าภายนอกผิด — วินิจฉัยที่ปลายทาง

ปัญหาไม่ได้อยู่ที่โค้ดเสมอไป — บางทีอยู่ที่ การตั้งค่า

ส่งของถูก แต่ส่งผิดช่องทาง

ทำผลลัพธ์ให้ดู "มืออาชีพ"

กันการกดผิด — เลือกก่อนทำ

การกระทำที่ ย้อนไม่ได้ ควรมีจังหวะให้ยืนยันเสมอ

ลูกค้ากดลิงก์แล้ว Error

บทเรียน: debug = หาหลักฐาน ไม่ใช่เดา

ปรับ UX ให้ใช้ลื่นขึ้น

อาการ + ตั้งสมมติฐาน

หาหลักฐาน ตัดสาเหตุทีละข้อ

• ทดสอบทีละชิ้น → รู้ว่าชิ้นไหนปกติ ชิ้นไหนพัง
• ส่งลิงก์ทดสอบตรง ๆ → แยกว่าพังที่ "ปุ่ม" หรือ "หน้า"
• ตัดสาเหตุที่พิสูจน์แล้วว่าไม่ใช่ ออกไปเรื่อย ๆ

ยิ่งตัดทิ้งได้มาก ยิ่งเข้าใกล้ต้นตอจริง

ทางออก = ตัดต้นตอ ไม่ใช่หลบ

บทเรียน: กล้าลบความซับซ้อนที่ไม่จำเป็น ดีกว่าฝืนแก้ไปเรื่อย ๆ

เครื่องมือก็มีปัญหาของมัน

งานจริงมี ความติดขัดของเครื่องมือ ที่โค้ดอย่างเดียวแก้ไม่ได้

ส่งของผิด "ชนิด" ให้ลูกค้า

เลือกชนิดของที่ส่งให้ตรงกับสิ่งที่ลูกค้าจะทำกับมัน

เพิ่มฟีเจอร์ตามที่ลูกค้าขอ

ก่อนสร้างใหม่ — เช็คก่อนว่ามีอยู่แล้วไหม

เพิ่มข้อมูลใหม่ อย่างปลอดภัย

เทคนิค Debug (ใช้ได้กับทุกอย่าง)

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

ทำซ้ำได้ทุกโปรเจกต์

ปล่อยงาน + เก็บข้อมูล ให้ปลอดภัย

• เปลี่ยนข้อมูล: ทำเป็นขั้น ๆ + เผื่อย้อนกลับได้
• ปล่อยงาน: ทดสอบก่อน แล้วค่อยปล่อย
• บันทึกเวอร์ชัน: เก็บเฉพาะที่ตั้งใจ + เขียนว่าแก้อะไร
• มี backup เสมอ ก่อนแก้ของใหญ่