เรื่องที่ 26 ที่นักพัฒนาควรรู้ และ เข้าใจก็คือ The Three Laws of Test-Driven Development
มาทำ TDD เถอะครับ !!
พูดแบบนี้ไม่ถูกนะ … เรามาพัฒนาระบบตามแนวคิด TDD กันเถอะครับ
แล้วคุณจะพบสิ่งดีๆ (เหมือนขายอะไรนะ)
Test-Driven Development (TDD) มันคือ
วินัยสำหรับการพัฒนา software
โดยนักพัฒนาจะต้องพัฒนาระบบมาจาก
การออกแบบ และ สร้าง code ต่างๆ มาจาก unit test เสมอ
โดยมีกฎง่ายๆ 3 ข้อ คือ
- คุณต้องเขียน fail test ขึ้นมาก่อนที่จะเขียน production code เสมอ
- คุณจะไม่เขียน test code มากเกินไป นั่นคือเขียน test ให้มัน fail ก็พอ หรือ compile ไม่ผ่าน
- คุณจะไม่เขียน production code มากเกินไป นั่นคือเขียน code เพียงให้ test มันผ่าน
ถ้าคุณทำตามกฎ 3 ข้อนี้แล้ว
ในแต่ละรอบของการทำงานจะใช้เวลาไม่นานเกิน 30 วินาที
แน่นอนว่า ใครความคิดแรกคือ บ้าหรือเปล่าว่ะ !! โง่ ไร้สาระสุดๆ !!
แต่ก่อนอื่นให้คุณลองทำตามดูสิ
แล้วจะพบว่ามีสิ่งดีๆ เกิดขึ้นกับคุณ ดังนี้
Debugging !!
มันจะดีไหม ถ้าคุณใช้เวลาเพียงไม่กี่นาที เพื่อทำให้มั่นใจว่าระบบมันทำงานได้ตามที่ต้องการนะ ?
มันจะดีไหม ถ้าคุณใช้เวลาเพียงไม่กี่นาที เพื่อหาจุดที่ทำงานผิดพลาดในระบบ ?
แต่ในปัจจุบันคุณจะรู้ได้อย่างไรล่ะ ?
ต้อง debug ใช่ไหมล่ะ ?
มันสนุกไหมล่ะ ?
คุณเก่งกับการใช้ hot key สำหรับการ debug ไหม เพื่อเพิ่ม productivity ?
ดังนั้น ลด ละ เลิก การ debug ด้วยการเขียน code ตามแนวคิด TDD ดีกว่าไหม ?
Courage
ความรู้สึกแรกเมื่อคุณเห็น code แย่ๆ นั้น
ความคิดแรกของคุณที่แว่บขึ้นมาเลยคืออะไร ?
… ฉันจะต้องแก้ไขให้ code มันดีขึ้นใช่ไหม ?
…ต่อจากนั้นก็คือว่า อย่าไปแตะ หรือ ยุ่งเกี่ยวกับ code มันเลย
… เพราะว่ามันทำงานได้ดีอยู่แล้ว !!
คำถาม
ทำไมเราถึงมีความคิดแบบนี้กันนะ ? แปลกไหม ?
คำตอบ
เพราะว่ากลัวว่าเมื่อไปแก้ไขแล้ว มันจะทำงานผิดพลาดไงล่ะ
ยังไม่พอกลัวระบบอื่นๆ มันทำงานผิดพลาดด้วยนะสิ
แล้วจะทำอย่างไรให้ความกลัวเหล่านี้หายไปล่ะ ?
ถ้าความกลัวนี้ไม่หายไป คิดว่า code ที่มันแย่ๆ จะหายไปหรือ ?
ลองคิดเล่นๆ
ถ้าคุณมีชุดของการทดสอบที่น่าเชื่อถือได้
แล้วทำให้คุณจะไม่กลัวการแก้ไข code
มันจะส่งผลให้คุณกล้าแก้ไข code ที่แย่ๆ ให้มันดีขึ้น
โดยที่เมื่อแก้ไขเสร็จแล้ว ให้ทำการทดสอบทั้งหมดว่ามันผ่านหรือไม่
ถ้าผ่านทั้งหมดเรามั่นใจได้ว่า การเปลี่ยนแปลงของเรามันดีล่ะ
ดังนั้น ชุดของการทดสอบมันก็น่าจะช่วยให้คุณกล้าต่อการแก้ไขใช่ไหม ?
ดังนั้น ถ้าคุณต้องการให้ระบบงานที่คุณพัฒนามันยึดหยุ่นแล้ว
ก็ควรต้องมีชุดของการทดสอบใช่ไหม ?
แต่ถ้าระบบงานของคุณมีการออกแบบที่สวยงาม
มี architecture ที่สมบูรณ์แบบ
แต่ไม่สามารถทดสอบ หรือ ไม่มีชุดการทดสอบแล้ว
คุณก็ยังคงกลัวต่อการแก้ไขใช่ไหม ?
แต่ถ้าคุณมีชุดของการทดสอบที่มีค่า coverage สูงๆ
แล้วคุณก็จะกล้าต่อการแก้ไข design และ architecture
เมื่อมันเกิดปัญหาขึ้นมาใช่ไหม ?
ซึ่งคุณต้องตอบคำถามเหล่านี้มาให้ได้ว่า ว่าคุณจะตอบและเลือกทางไหน ?
Documentation
คุณเคยต้องใช้งานพวก 3-party library ไหม ?
โดยที่พวก 3-party library นั้นมักจะมีคู่มืออธิบายที่เขียนมาอย่างดี
และท้ายๆของคู่มือการใช้งานจะมีสิ่งเล็กๆ ที่เรียกว่า code ตัวอย่าง
คำถามก็คือ จุดแรกที่คุณจะอ่านคือที่ไหน ?
คำตอบก็คือ code ตัวอย่างใช่ไหม ?
ทำไมล่ะ ?
ก็เพราะว่า code มันคือความจริง ข้อเท็จจริงนะสิ
และ unit test ที่เขียนขึ้นมาตามแนวคิด TDD นั้น
มันก็คือ code ตัวอย่างนี่แหละ
ซึ่งถ้าคุณต้องการรู้ว่าเรียกใช้ method ใน class นี้อย่างไร
คุณสามารถดูที่ unit test ได้เลย
โดยที่แต่ละ unit test จะต้องเล็ก ชัดเจนว่าทดสอบอะไร
เพื่อที่จะใช้อธิบายว่า จะใช้งาน production code อย่างไร
วิธีการนี้ เป็นการออกแบบเอกสาร ด้วยการเขียน code
ด้วยภาษาที่นักพัฒนาเข้าใจได้ง่าย
มันไม่กำกวม
มันสามารถประมวลผลได้
มันทำให้เราทำงานอยู่กับ production code ได้อย่างมีความสุขขึ้น
Design
ถ้าคุณปฏิบัติตามกฎ 3 ข้อแล้ว code ที่ได้มามันจะง่ายต่อการทดสอบ
นั่นหมายถึงว่า code ของคุณมันจะไม่ผูกมัดกันแน่นใช่ไหม ?
นั่นหมายถึงมันง่ายต่อการเปลี่ยนแปลงใช่ไหม ?
นั่นหมายถึงการออกแบบระบบมันยึดหยุ่นใช่ไหม ?
นั่นหมายถึงสามารถดูแลได้ง่ายใช่ไหม ?
Professionalism
ถ้าคุณต้องการเป็นนักพัฒนา software มืออาชีพแล้ว
สิ่งหนึ่งที่คุณจะต้องทำเลยก็คือ การพัฒนาตามแนวคิด TDD
ดังนั้น สิ่งที่คุณต้องทำก็คือ การ ฝึก ฝึก และ ฝึก
เพื่อนำมาใช้ในการพัฒนา software
เพื่อให้เกิดประโยชน์สูงสุดต่อตัวเราเอง และ ผู้อื่น ครับ
