จากหนังสือ TDD by Example ทำการอธิบายวิธีการแก้ไขปัญหา
เพื่อย้ายจากสถานะ RED ไปยัง GREEN ตาม life cycle ของ TDD ไว้ 3 วิธีการคือ
- Obvious implementation
- Fake it until you make it
- Triangulation
ซึ่งการจะเลือกใช้วิธีการใดนั้น
มันขึ้นอยู่กับความรู้ความเข้าใจต่อปัญหาของ developer
มันขึ้นอยู่กับแนวทางในการแก้ไขปัญหาของ developer
มันขึ้นอยู่กับความสามารถของ developer
จึงทำการสรุปพร้อมตัวอย่างไว้นิดหน่อย
เพื่อทำให้เราสามารถเดินไปข้างหน้าได้อย่างสม่ำเสมอ
จนสามารถแก้ไขปัญหาต่าง ๆ ได้
มาเริ่มกันเลย
1. Obvious implementation
มันคือเขียน code สำหรับแก้ไขปัญหานั้นได้ทันที
ดังนั้นผู้แก้ไขปัญหาจำเป็นต้องมีความรู้เกี่ยวกับปัญหาอย่างชัดเจน
รู้ว่าจะแก้ไขปัญหาอย่างไร
รู้ว่าต้องเขียน code อย่างไรเป็นอย่างดี
ทำให้สามารถเขียน code เพื่อแก้ไขปัญหาได้ทันที
เช่นการคำนวณหาพื้นที่สี่เหลี่ยม
สามารถเขียน code ได้ดังนี้
เริ่มต้นจากการเขียน test ก่อนเสมอ
ซึ่งถ้าเราใช้วิธีการแก้ไขปัญหาแบบแรก
สามารถเขียน code ได้ดังนี้
แต่ลองคิดดูสิว่า ถ้าปัญหาที่เราต้องการแก้ไขมันยากและซับซ้อนล่ะ ?
การจะเขียน code ออกมาทีเดียวทั้งหมดไม่น่าจะเป็นเรื่องที่ดีแน่ ๆ
เนื่องจากต้องใช้เวลาแก้ไขนานมาก ๆ
ดังนั้นมาดูวิธีการต่อไป
2. Fake it until you make it
ถ้าคุณรู้ปัญหา และ วิธีการแก้ไขปัญหา
แต่ยังไม่มั่นใจในการเขียน code
แนะนำให้ทำการ Fake ผลการทำงานก่อน
เพื่อทำการการทดสอบผ่าน
จากนั้นจึงหยุด และกลับมาดู code เพื่อวิเคราะห์ว่า
ทำไมเราถึง fake คำตอบไว้ ?
การ fake มีที่มาจากอะไรบ้าง ?
มาดูตัวอย่างของการหาพื้นที่สี่เหลี่ยมเหมือนเดิม
สามารถเขียน code ชุดแรกได้ดังนี้
ผลก็คือทดสอบผ่านแน่นอน
จากนั้นลองมาคิดหน่อยสิว่า สูตรการหาพื้นที่สี่เหลี่ยมคืออะไร ?
มันคือกว้างคูณยาวใช่หรือไม่ ?
ดังนั้นสามารถแก้ไข code ได้ดังนี้
ผลก็คือทดสอบผ่านแน่นอน
จากนั้นให้เริ่มแทนที่ค่าที่ Fake ขึ้นมาด้วยตัวแปรซะ
จะทำให้ได้ code ที่สามารถแก้ไขปัญหาได้
แต่ถ้า developer ไม่รู้ว่าจะแก้ไขปัญหาอย่างไรล่ะ ?
จะทำอย่างไรดี ?
3. Triangulation
เป็นวิธีการที่ผมใช้บ่อยมาก ๆ สำหรับการแก้ไขปัญหาที่เรายังไม่รู้วิธีการจริง ๆ
แต่ใช้ test case เป็นตัวช่วยนำทาง
รวมเข้ากับข้อมูลในการทดสอบ
จากตัวอย่างการหาพื้นที่สี่เหลี่ยม
เราสามารถเริ่มด้วยข้อมูลต่าง ๆ เหล่านี้ได้
- Case 1 : width = 0, height = 0 ผลที่ได้คือ 0
- Case 2 : width = 1, height = 1 ผลที่ได้คือ 1
- Case 3 : width = 1, height = 2 ผลที่ได้คือ 2
ถ้าเขียน code จะได้ดังนี้
เริ่มที่ case 1
เพื่อทำให้ผ่านก็ทำการ fake ผลการทำงานได้เลย
มาที่ case 2
เป็นการเปลี่ยนค่า input เพื่อใช้แก้ไขปัญหาเดิม
เพียงแค่ต่างมุมมองเท่านั้นเอง
ถ้าต้องการให้ผ่านทั้ง 2 case จึงเกิดการสร้างตัวแปร width ขึ้นมาเก็บค่า
มาที่ case 3
เป็นการบังคับให้เราต้องสร้างตัวแปร height ขึ้นมา
ซึ่งทำให้เกิดวอธีการแก้ไขปัญหาจริง ๆ ขึ้นมา
เป็นวิธีการที่ดูเหมือนโง่ แต่ก็โง่จริง ๆ
แต่สิ่งที่เราได้รับกลับมาคือ ได้รู้ลำดับขั้นตอนการแก้ไข
รวมทั้งเหตุผลของการสร้างตัวแปรชนิดต่าง ๆ ขึ้นมา
ซึ่งเหมาะมากสำหรับการแก้ไขปัญหาที่ซับซ้อน
สังเกตุไหมว่า การแก้ไขปัญหาแบบที่ 3 เหมือนดังรูป
สุดท้ายแล้ว ในการแก้ไขปัญหาต่าง ๆ
ขอให้เริ่มแบบ step-by-step
โดยเริ่มจาก test case ที่ง่ายสุด ๆ ก่อน
จากนั้นก็ค่อย ๆ เพิ่มความซับซ้อนเข้ามา
เพื่อทำให้เรามีกำลังใจในการแก้ไขปัญหา
แต่ปัญหาหลักของ developer คือ ไม่สามารถแยกปัญหาใหญ่ ๆ ออกเป็นปัญหาย่อย ๆ ได้นะสิ !!
