วันแรกของงาน Agile Singapore 2014
เข้า session เรื่อง You Can’t be Great without Technical Excellence
พูดโดยคุณ James Grenning ซึ่งเป็นหนึ่งใน 17 คนที่ร่วมประกาศ Agile Manifesto
ดังนั้น session นี้พลาดไม่ได้เลย ซึ่งสามารถสรุปเรื่องที่น่าสนใจได้ดังนี้
เรื่องที่ยังติดหูติดตาอยู่ก็คือ
เรื่องของ Test-Driven Development (TDD)
เป็น technical practice ที่ขาดไปไม่ได้เลยในการพัฒนา software
ดังนั้น developer ทุกๆ คนควรที่จะเรียนรู้ไว้นะ
และหัวข้อที่น่าสนใจมากๆ คือ การเปรียบเทียบระหว่าง
Test-Driven Development (TDD) กับ Debug Later Programming (DLP)
ว่ามีโครงสร้างการทำงานอย่างไร
และมันแตกต่างกันอย่างไร ?
Debug Later Programming (DLP)
มีขั้นตอนการทำงานดังนี้
- ทำการเขียน code ให้เสร็จหลังจากที่ทำการออกแบบ
- หลังจากนั้นก็ทำการ debug เมื่อเจอปัญหา
- แก้ไขปัญหา
สิ่งที่น่าสนใจก็คือ การพัฒนาแบบนี้มันมีคำจัดความของคำว่าเสร็จอย่างไร ?
แต่ที่แน่ๆ เราได้ใส่ Definition of Fail ไปให้สิ่งที่เราสร้างขึ้นมาแล้วครึ่งหนึ่ง
มีคนพูดไว้ว่า
ถ้า developer ไม่สร้างความผิดพลาดขึ้นมา
ก็ไม่จำเป็นต้องการทดสอบ code ที่เขียนขึ้นมาอีกต่อไป
แต่ความเป็นจริงคืออะไรล่ะ ?
อย่างที่รู้กันว่า developer นั้นมักสร้างความผิดพลาดระหว่างการออกแบบ และ coding เสมอ !!
คำถาม
แล้วใน DLP นั้นมีการทดสอบไหมล่ะ ?
คำตอบ
มีนะ แต่ว่าเป็นการทดสอบของแต่ละคนไป เพื่อทำให้ตัวเองมั่นใจว่า
สิ่งที่กำลังสร้างขึ้นมานั้นถูกต้อง
ปัญหาที่ตามมาก็คือ มันไม่สามารถที่จะทำงานซ้ำๆ ที่อื่นได้เลย
หรือการทดสอบโดยรวมไม่สามารถทำได้
และเมื่อเวลาต่อมา มีความต้องการที่จะเปลี่ยนแปลง
ตอนนี้ล่ะ ปัญหาใหญ่ก็จะตามมา นั่นคือ Bug ต่างๆ มากมาย
ทั้งจากที่ทำการเพิ่มเข้าไป และ แก้ไข Bug
ถ้าจะทำการทดสอบแบบ manual เพื่อจับ Bug ให้ได้ทั้งหมด
มันก็เป็นเรื่องที่ไม่เหมาะสม หรือ ต้องใช้ค่าใช้จ่ายที่เยอะมากๆ
ซึ่งก็ยังจับไม่หมด ใช่ไหม ?
อีกทั้งยังมี bug ที่ถูกซ่อนเอาไว้ ยากต่อการค้นหาอีกด้วย
Debug Later Programming (DLP) มีขั้นตอนการทำงานดังนี้
คำอธิบาย
- Td คือเวลาในการค้นพบ Bug หรือ Defect
- T find คือเวลาในการค้นหา root cause ของ Bug หรือ Defect
- T fix คือเวลาในการแก้ไข Bug หรือ Defect
พบว่า Td กับ T find จะแปรผันตรงกัน นั่นก็คือ
ถ้า Td ใช้เวลานานแล้ว T find ก็ใช้เวลาในการค้นหา root cause นานเช่นกัน
แต่ Bug หรือ Defect บางตัวอาจจะใช้เวลาในการแก้ไข หรือ T fix น้อยหรือมาก ไม่ได้ขึ้นอยู่กับ Td
และถ้าทำการแก้ไขผิดที่แล้ว T fix ก็ยิ่งใช้เวลาสูงมากๆ
ปัญหาของ DLP คืออะไร ?
ปัญหาหลักคือ เรื่อง feedback เพื่อให้รู้ว่าสิ่งที่ทำมันผิดพลาดหรือไม่นะ
เพราะว่าอาจจะใช้เวลานานเป็นวัน สัปดาห์ เดือน หรือ ปี
จึงจะทำการส่ง feedback กลับไปให้ developer รู้
ยิ่งถ้าเวลาผ่านไปนานๆ สิ่งที่ developer จะต้องทำเมื่อเจอปัญหาคือ การ debug นั่นเอง
ซึ่งมันก่อให้เกิดเหตุการณ์ที่ไม่คาดฝันตามมาเพียบ
แล้ว TDD ล่ะ เป็นอย่างไร
โดย TDD นั้นจะได้ feedback กลับมาทันที
ดังนั้น คุณจะรู้ความผิดพลาดได้อย่างรวดเร็ว
ทำให้คุณสามารถป้องกันไม่ให้เกิดความผิดพลาดได้
แต่ใช่ว่าจะป้องกันได้ทั้งหมดนะครับ มันไม่ป้องกันทั้งหมดหรอกนะ
แต่มันทำให้คุณมั่นใจ และเชื่อว่าส่วนใหญ่ของระบบทำงานได้ถูกต้องตามที่คาดหวัง
มีขั้นตอนการทำงานดังรูป
คำอธิบาย
Td และ T find นั้นมีค่าเป็น 0
เนื่องจากต้องทำการเขียน test ก่อน เพื่อให้เกิด และ รู้ข้อผิดพลาด
ซึ่งไม่ต้องใช้แรง และ เวลาอะไรเลย
ส่วน T fix นั้นก็น้อยลงไป เนื่องจากคุณรู้ว่า root cause คืออะไร
มีคนบอกไว้ว่า Developer มักจะสร้างงานได้ดี ถ้ารู้และเข้าใจงานและปัญหาของงาน
ดังนั้น TDD ช่วยทำให้ developer รู้และเข้าใจในสิ่งที่ทำมากขึ้น
นั่นคือการลดความผิดพลาดลงไป
ทำไมต้อง TDD ด้วยล่ะ ?
บ่อยครั้งมักจะพบคำพูดว่า การเขียน test นั้นใช้เวลาเพิ่มใช่ไหม ?
คำตอบ คือ แน่นอน ใช้เวลาเพิ่มขึ้นสิ
ถ้ามนุษย์เราไม่สร้างความผิดพลาด
ก็ไม่จำเป็นต้องเขียน test ซึ่งมันเปลืองเวลา
แต่เผอิญว่า มนุษย์เรามักจะทำผิดพลาดอยู่อย่างเสมอ นะสิ !!
สิ่งหนึ่งที่ต้องเข้าใจก่อนว่า
เวลาในการเขียน test นั้นสามารถทำนาย หรือ กำหนดเขตได้
ส่วนเวลาในการค้นหา และ แก้ไข Bug หรือ Defect นั้นไม่สามารถทำนายหรือกำหนดได้เลย
ลองกลับไปดูว่า คุณใช้เวลาแก้ไข Bug หรือ Defect แต่ละตัวนานเท่าไร ?
ใช้เวลาในการค้นหาเท่าไร ?
ใช้เวลาในการแก้ไขเท่าไร ?
ถ้าใช้เวลาที่นานเกินระดับนาที แสดงว่า ถึงเวลาที่คุณควรปรับปรุงแล้วนะ
หนึ่งในเทคนิที่ดีนั่นก็คือ TDD ครับ ลองดูกันได้เลยครับ
Reference Website
http://www.renaissancesoftware.net/blog/archives/16
