Spaghetti Driven Development มันเป็นอย่างไร ?
เป็นอีกหนึ่งวิธีการของการพัฒนา software !!
โดยมีขั้นตอนดังนี้
- เขียน code โครตแย่ออกมา
- ทำการ refactor code ให้ code ดีขึ้นและเข้าใจได้ง่ายขึ้น
- ทำการเขียนชุดการทดสอบ
ฟังแล้วมันดูดีมาก
แต่ส่วนใหญ่มักจะทำเพียงขั้นตอนแรกเท่านั้น
จึงทำให้เกิด Spaghetti code ออกมาจำนวนมาก
และไม่มีใครกล้าแตะต้องมัน
ใจร้ายกันมาก ๆ
ดังนั้นจึงมีวิธีการและแนวคิดไหม่ ๆ ขึ้นมา
เพื่อทำให้ code ออกมามีคุณภาพ
หนึ่งในนั้นคือ Test-Driven Development (TDD)
เพื่อความเข้าใจมากขึ้นมาวิวัฒนาการของสิ่งเหล่านี้กันดีกว่า
เริ่มในยุค 80
เป็นยุคของ Spaghetti Driven Development
นั่นคือเขียน code แย่ ๆ ยุ่งเหยิงออกมาก่อน
จากนั้นทำการ refactor code จนกระทั่ง code เข้าใจได้ง่ายขึ้น
และเขียน test ออกมา
ถามว่า มี automated test ไหม ?
ตอบได้เลยว่าไม่
ลองคิดถึงตัวเราเองตอนสมัยเรียนการเขียน program สิ
คุณเรียนรู้ว่า จะเขียน code อย่างไรเท่านั้นใช่ไหม ?
ต่อมาในยุค 80 ถึง 90
เริ่มมีตำแหน่ง Analyst/Programmer เพื่อทำการวิเคราะห์และออกแบบระบบ
ก่อนเริ่มเขียน programg เล็กน้อย
ซึ่งนี่คือจุดกำเนิดของ Small Up Front Design !!
มีขั้นตอนการทำงานดังนี้
- ทำการออกแบบระบบ
- ทำการเขียน program
- ทำการทดสอบแบบ manual
ในยุคนี้คำสั่ง goto ใน code เป็นสิ่งที่ดีมาก ๆ
แน่นอนว่าสำหรับยุคนี้ภาษา COBOL มันไม่ใช่ Legacy code นะ
ต่อมาในยุค 90 ถึงปี 2000
เป็นยุคแห่ง Big Design Up Front !!
เพราะว่ามีขั้นตอนจำนวนมาก
รวมทั้งในแต่ละขั้นตอนเรามีตำแหน่ง และ แผนกแยกกันทำงาน เช่น
- Business Analyst
- Software Analyst
- Programmer
- QA/Tester
- Database Administrator
- System Admin
เริ่มมีการทดสอบแบบอัตโนมัติ (Automated Testing)
แต่เป็นการทดสอบหลังจากที่เขียน program เสร็จแล้วทั้งหมด
บ่อยครั้งที่มีทีมทดสอบแยกออกมาจากทีมพัฒนา !!
ผลที่ตามมาคือ ปัญหามากมาย
เป็นยุคที่ Object-Oriented Programming และ Design ได้รับความนิยมสูงมาก ๆ
และทำให้เกิด Design Pattern ขึ้นมา
เริ่มมีการพูดถึง Functional Programming กันด้วยนะ
แถมมีแนวคิด DevOps ขึ้นมา ซึ่งเป็นแนวคิด Back to basic กลับไปในยุคก่อนหน้า !!
ต่อมาในช่วงต้นของยุค 2000
เริ่มกลับไปสู่ Small Design Up Front
กลับมาสู่การทำงานแบบเป็นรอบสั้น ๆ (Interative and Incremantal Development)
แต่ยังเขียนชุดการทดสอบแบบอัตโนมัติหลังจากเขียน program เสร็จ
มีขั้นตอนการทำงานดังนี้
- เขียนโปรแกรม
- ทำการ refactor code
- ทำการเขียนชุดการทดสอบแบบอัตโนมัติ
มาถึงยุคปัจจุบันกันบ้าง
มีแนวคิดต่าง ๆ ที่ได้รับการยอมรับและนิยมนำมาใช้งาน
ประกอบไปด้วย
- Test-Driven Development (TDD)
- Behaviour-Driven Development (BDD)
- Acceptance Test-Driven Development (ATDD)
โดยแนวคิดต่าง ๆ นั้นถูกแนะนำมาจากแนวคิด Continuous Delivery และ Continuous Integration
มีขั้นตอนการทำงานดังนี้
- เริ่มต้นจากการคิด และ เข้าใจภาพรวมของปัญหา
- ทำการพัฒนาเป็นรอบสั้น ๆ
- ก่อนที่จะเขียน program ให้เริ่มด้วยการเขียนชุดการทดสอบแบบอัตโนมัติ
- ทำการเขียน program เพื่อให้ชุดการทดสอบผ่าน
- ทำการ refactor code
- สนกลับไปเขียนชุดการทดสอบแบบอัตโนมัติใหม่
- วนแบบนี้ไปเรื่อย ๆ
ซึ่งเป็นวิธีการพัฒนาที่เป็นธรรมชาติอย่างมาก
แต่มันก็ไม่ใช่เรื่องง่ายเช่นกัน
ดังนั้นจึงต้องทำการฝึกฝนเพื่อให้ชำนาญ
มาถึงตรงนี้น่าจะพอทำให้เราเห็นวิวัฒนาการ
จาก Spaghetti Driven Development ถึง Test-Driven Development กันได้ชัดเจนขึ้น
สุดท้ายแล้ว TDD มันไม่ใช่สิ่งใหม่
แต่มันคือความสามารถที่นักพัฒนาทุกคนต้องมี
และไม่ใช่สิ่งที่จะเอามาอ้างว่า
ถ้าทำ TDD แล้วต้องใช้เวลาเพิ่ม !!!
คำถามตอนนี้เราพัฒนา software กันแบบไหนระหว่าง
Spaghetti Driven Development ?
Test-Driven Development ?
สรุปเนื้อหามาจากหนังสือ Test-Driven Development by Examples
