ในปลั๊กอิน 8-habit-ai-dev เครื่องมือที่คมที่สุดตัวหนึ่งชื่อ cross-verify มันคือเช็กลิสต์ 17 คำถามที่ไล่ถามก่อน ship งาน ว่าคิดครบหรือยัง บทความนี้เล่าว่ามันคืออะไร มีประโยชน์อย่างไร ควรใช้ตอนไหน พร้อมผลที่เรารันจริงกับบล็อกนี้
มันคืออะไร
cross-verify เอา 8 habits มากางเป็น 17 คำถาม แบ่งเป็น 4 มิติ คือ Body (วินัย) Mind (วิสัยทัศน์) Heart (ความใส่ใจ) และ Spirit (มโนธรรม) ครอบตั้งแต่ "ไล่ caller ครบหรือยัง" "มีเกณฑ์สำเร็จที่วัดได้ไหม" ไปจนถึง "งานนี้ช่วยคนถัดไปหรือเปล่า" แต่ละข้อตอบได้สี่แบบ คือ PASS FAIL N/A และ OPEN_VERIFICATION_DEBT (หลักฐานยังค้าง) แล้วคิดคะแนนเป็นเปอร์เซ็นต์เทียบกับเกณฑ์ ตั้งแต่ Well-prepared (เกิน 88%) ลงไปถึง Not ready (ต่ำกว่า 47%)
ของที่ทำให้มันต่างจากเช็กลิสต์ทั่วไปมีสามอย่าง อย่างแรกคือระดับความมั่นใจ กำกับทุกข้อว่า Verified (ตรวจแล้ว) Inferred (อนุมาน) หรือ Unverified (แค่สมมติ) อย่างที่สองคือ shadow self-check ที่บังคับให้เถียงคำตัดสินของตัวเองก่อนสรุป ว่าใครเดือดร้อนถ้าเราตัดสินผิด อย่างที่สามคือกฎว่า debt ไม่นับเป็น PASS และคะแนนดีแค่ไหนก็ลบล้างด่าน domain ที่บล็อกไม่ได้
ควรใช้ตอนไหน และตอนไหนควรข้าม
ควรใช้สามจังหวะ คือหลังเขียนแผนก่อนลงมือทำ ก่อนเปิด PR งานที่แตะหลายไฟล์ และตอนที่รู้สึกว่ามีอะไรผิดปกติแต่ชี้ไม่ถูกว่าคืออะไร ส่วนงานแก้บั๊กบรรทัดเดียว งานจัด format หรืองาน bump version ที่ CI ผ่าน ให้ข้ามไปได้เลย
เรารันจริงกับบล็อกนี้
เราลองรันทั้ง 17 ข้อกับงานบล็อกนี้ ผลคือ PASS 13 ข้อ N/A 3 ข้อ และ FAIL 1 ข้อ คิดเป็น 93% (13/14) อยู่ใน band Well-prepared ข้อที่ตกคือ Q3 เพราะบล็อกยังไม่มี README (มีแต่ CHANGES.log) วิธีแก้คือเขียน README สั้นๆ ให้ blog/ ส่วนข้อ N/A คือเรื่อง commit message error message และ issue ที่ยังไม่มีในงานนี้
สิ่งที่เช็กลิสต์จับได้และเรามองข้ามจริงๆ คือข้อนั้นแหละ งานดูเหมือนเสร็จ (เว็บขึ้น production ใช้งานได้) แต่เอกสารสำหรับคนถัดไปยังขาด นี่คือค่าของมัน มันไม่ได้ถามว่าเว็บรันได้ไหม แต่ถามว่าเราคิดครบหรือยัง
สรุป
cross-verify ไม่ได้ตรวจว่าโค้ดถูก แต่ตรวจว่ากระบวนการคิดครบถ้วน ราคาของมันคือเวลาตอบ 17 ข้อ ผลตอบแทนคือช่องโหว่แบบ Q3 ที่ไม่มี test ตัวไหนจับได้ ถ้าจะเริ่ม ใช้แค่สามจังหวะข้างบนก็พอ ไม่ต้องรันทุกงาน