Confirmation Bias กับ Test-first Strategy
เรื่องนี้มีที่มาจากการนั่งฟัง Podcast ของ อ.นพดล เรื่องกับเรื่อง ของ bias ตัวหนึ่ง แล้วระลึกถึงเรื่องที่พี่ประธาน ของสยามชำนาญกิจพูดขึ้นมาเกี่ยวกับเรื่องการทำ Test Driven Development เลยมาเขียนเชื่อมที่มาที่ไปกันสักหน่อย
ปัญหา Wason 2–4–6
ก่อนอื่นของยกปัญหาเรื่องหนึ่งซึ่งถูกคิดโดย ดร. Peter Cathcart Wason สิ่งที่ ดร. Wason ถามนั้นง่ายมากๆ โดยเขาตั้งคำถามกับผู้ทดสอบของเขาว่า ถ้าเขาให้ลำดับตัวเลขมา 3 ตัว ขอให้หากฎที่ตรงรูปแบบที่บอก โดยเขาเริ่มด้วย
2,4, 6 ถูกต้องตามกฎ
สิ่งที่ผู้ทดสอบสามารถทำได้หลังจากนี้ คือ ห้ามถามกฎกับเขา แต่สามารถทดสอบลำดับตัวเลขกับเขาแล้วเขาจะตอบว่า ลำดับนี้ตามกฎหรือไม่
และแน่นอนส่วนตัวเชื่อว่า หลายท่าน(รวมถึงตัวผมเองด้วย) ก็จะคิด sequence ถัดไป ว่า 8,10,12 และนั่นก็ถูกตามกฎเช่นเดียวกัน
เมื่อผ่านไปหลายรอบแล้ว ก็จะมีหลายคนก็จะมั่นใจว่า กฎที่ว่านั้นคือ ลำดับของจำนวนที่บวก 2 ไปเรื่อยๆ
แน่นอนว่า…
มันไม่ใช่
เพราะจริงๆแล้ว กฎที่ดร. Wason ตั้งขึ้นมาคือ ลำดับอะไรก็ได้ที่มากกว่าลำดับที่ผ่านมา
แล้วเกิดอะไรขึ้นกับการคิดที่ผ่านมากัน
ก่อนอื่นอยากให้ดูหลักคิดที่อาจจะทำให้เจอกฎที่ถูกตั้งไว้กันครับ
สิ่งที่แตกต่างจาก การคิดโดยปกติ คือ การคิดรอบนี้ จะมีผลที่ไม่ตรงกับกฎครับ
นอกจากนี้จะเห็นว่า ตัวอย่างของ Sequence ไม่ได้มีการย้ำลำดับเลขคู่อยู่กับที่ตลอดเวลา
ทำไมเราถึงไม่คิดถึงผลที่ไม่ตรงกับกฎ
เพราะว่าคนเราจะพยายามหาวิธีการในการสนับสนุนความเชื่อของตัวเอง มากกว่าจะพยายามดูว่าเราอาจจะผิดก็ได้ ดังนั้นจึงพยายามที่จะหาข้อมูลที่มาช่วยยืนยันแนวความคิดของเรา (e.g., Darley & Gross, 1983).
สิ่งนี้เองที่เรียกว่า Confirmation Bias
จึงไม่น่าแปลกใจที่เมื่อเราเอา sequence ที่เป็น ลำดับบวก 2 แล้วได้ ก็จะพยายามหา ลำดับที่บวก 2 อันอื่นมาช่วยยืนยันความถูกต้องอีกที จึงทำให้มีความมั่นใจมากขึ้น
วิธีหลีกเลี่ยง Confirmation Bias
อย่างแรกสุด สิ่งที่เรากำลังคิดว่าเป็นกฎในตอนแรกนั้น เรียกว่า สมมติฐาน
สมมติฐานจำเป็นที่จะต้องมีการทดสอบ ซึ่งในการทดสอบจะมีอยู่สองอย่างคือ ตรวจสอบว่ามันเป็นไปตามสมมติฐาน และไม่เป็นไปตามสมมติฐาน
ถ้าจากตัวอย่างเราจะเห็นเรื่องนึงคือ พยายามหาสิ่งที่ไม่เป็นไปตามกฎ เพื่อที่จะตรวจสอบสมมติฐานว่าเราเข้าใจผิดหรือไม่
อย่างเช่นการเริ่ม 5,10,15 เป็นการท้าทายสมมติฐานเดิม คือถ้าลำดับ +2 มันควรจะไม่ถูกตามกฏ แต่มันดันถูกจึงมีสมมติฐานใหม่ เป็น ลำดับ+X แทน
แต่การทดสอบถัดไปก็ทำการทดสอบทันทีแล้วพบว่า ไม่ใช่อีกรอบ
ดังนั้น ความพยายามในการทำให้สมมติฐานผิด เป็นสิ่งที่สำคัญในการต่อสู้กับ Confirmation Bias มาก
The only way to show you’re right, is to try and show you’re wrong.
กลับมาที่ Test Driven Development
ถ้าใครไม่คุ้นเคยกับคำๆ นี้ Test Driven Development คือการพัฒนาโปรแกรมที่ใช้วิธีการค่อยๆ ทำ feature ไปทีละเล็กทีละน้อย โดยมีการเขียนเทสเพื่อนำทางว่า เราจะทำ feature อะไร
ซึ่งถ้าเราเขียนเทสก่อน โดยยังไม่ได้เขียนโค้ดเลย จะทำให้การเทสไม่ผ่าน หลังจากที่เราเห็นว่าเทสไม่ผ่านแล้ว จึงเขียนโค้ดตาม และทดสอบให้มันผ่านโดยใช้ effort น้อยที่สุด เมื่อผ่านแล้วก็จะมาทำการ Refactor หรือจัดสรรโครงสร้างของโค้ดให้สวยงามและเข้าใจง่ายขึ้น
จากที่กล่าวมาคำถามก็มาสู่เรื่องที่ว่า ทำไมเราต้องเขียนเทสและทดสอบว่ามัน Fail ก่อน ที่จะเขียนโค้ดจริงๆ
ซึ่งส่วนตัวก็เชื่อว่า หลายๆคน เวลาที่รีบๆ ก็เขียนเทสแล้วก็เขียนโค้ดต่อเลย แล้วเวลาเทสก็รอให้มันถูกทีเดียว ก็จะประหยัดเวลาไปได้พอสมควร
Feature นั้นจำเป็นต้องโค้ดจริงๆใช่ไหม ??
ผมจำไม่ได้แล้วว่าวันไหนที่ไปฟังพี่ประธานพูดเรื่องของ TDD
สิ่งหนึ่งที่พี่ประธานพูดให้ฟังในวันนั้นคือ คุณมั่นใจใช่ไหมว่า Code นั้นจำเป็นต้องเขียน
ตรงนี้สำคัญมาก ไม่ได้บอกว่า Feature ไม่ต้องมีนะครับ แต่ Feature นี้ต้องโค้ดหรือไม่
ถ้าเราเขียนเทสก่อน แล้วเทสมันผ่าน…
คำตอบที่ดูจะชัดเจนที่สุดคือ Feature ที่คาดว่าจะมีมันมีอยู่แล้ว แล้วเราจะไป code ต่อทำไม
Test ที่เขียนไว้ มันมีไว้เพื่อจะบอกเราว่า งานนี้ต้องออกแรงหรือไม่ออกแรง
- ถ้า Test มันไม่ผ่าน เราก็ออกแรง
- ถ้า Test มันผ่าน เราก็ไม่ต้องออกแรง ไป Test อื่นต่อเลย
นี่คือ Essence ที่สำคัญของ Test Driven Development เลย คือ Test เพื่อขับเคลื่อนการพัฒนา
สิ่งที่เราจะเห็นอีกอย่างคือ เมื่อเราทำเสร็จแล้ว เราจะเห็นหลักฐานเชิงประจักษ์ที่ชัดเจนว่า ก่อนหน้านี้ Feature นี้ยังไม่มีจะหน้าตาเป็นยังไง Feature หลังจากที่ implement แล้วผลเป็นยังไง
ซึ่งจะมาเชื่อมกับ Confirmation Bias ตรงที่หลายคนมีสมมติฐานว่า มันเป็น Feature ที่เพิ่มมาจากเดิม ดังนั้น Test ที่เขียนมันก็ต้อง Fail อยู่แล้ว ก็ไปเทสทีเดียวเลยหล่ะกัน
ซึ่งมันคงจะใช้ได้ดีในตอนเริ่มต้นซึ่งซอฟท์แวร์ยังมีขนาดเล็กอยู่ เราสามารถดูแลและจัดการด้วยสายตาได้
แต่ถ้าเกิดซอฟท์แวร์มีขนาดใหญ่ขึ้น ก็อาจจะมีความผิดพลาดได้
ดังนั้นการรักษาวินัยตามลำดับของการพัฒนาโดยใช้ TDD จึงมีความสำคัญ ในการที่จะหลีกเลี่ยง Confirmation Bias ในมุมนึงด้วย
ส่งท้าย
ก็หวังว่าหลายคนจะเข้าใจเรื่องของการ Challenge สมมติฐานมากขึ้นและลำดับในการทำ TDD มีความสำคัญยังไง
อย่างไรก็ตาม แม้ว่าเราจะสามารถรักษาวินัยในการโค้ดได้แล้ว ก็ยังมี Confirmation Bias อีกเรื่องหนึ่งที่ส่งผลต่อ การใช้ Test Driven Development เดี๋ยวคงจะมาเขียนเพิ่มเติมในไม่ช้า
ที่มา
- http://www.devpsy.org/teaching/method/confirmation_bias.html
- Nopadol’s Story, EP 992 (MB 12) แค่คิดก็ผิดแล้ว ตอนที่ 3