จากบทความเรื่อง Last Line Effect ทำการศึกษาผลกระทบที่มักเกิดกับการ Copy-and-Paste code ซึ่งแน่นอนว่า developer ส่วนใหญ่ชอบใช้งาน แถมใช้งานกันบ่อย ๆ อีกด้วย และบ่อยครั้งพบว่าการกระทำแบบนี้ก่อให้เกิดความผิดพลาดขึ้นมา หนึ่งในข้อผิดพลาดนั้นก็คือ code ใน block หรือบรรทัดท้าย ๆ นั่นเอง มาดูผลการศึกษากัน
จากหนังสือ TDD by Example ทำการอธิบายวิธีการแก้ไขปัญหา เพื่อย้ายจากสถานะ RED ไปยัง GREEN ตาม life cycle ของ TDD ไว้ 3 วิธีการคือ Obvious implementation Fake it until you make it Triangulation ซึ่งการจะเลือกใช้วิธีการใดนั้น มันขึ้นอยู่กับความรู้ความเข้าใจต่อปัญหาของ developer มันขึ้นอยู่กับแนวทางในการแก้ไขปัญหาของ developer มันขึ้นอยู่กับความสามารถของ developer จึงทำการสรุปพร้อมตัวอย่างไว้นิดหน่อย เพื่อทำให้เราสามารถเดินไปข้างหน้าได้อย่างสม่ำเสมอ จนสามารถแก้ไขปัญหาต่าง ๆ ได้ มาเริ่มกันเลย
วันนี้มาแนะนำการพัฒนาระบบงานด้วยแนวคิด TDD (Test-Driven Development) จึงทำการสรุปข้อดีและข้อเสียของแนวคิดนี้ไว้นิดหน่อย เพื่อทำให้เข้าใจกันมากขึ้น
วันนี้ช่วงพักกลางวันจากงาน Conference JCSSE2016 ได้นั่งลองเขียน code ตามแนวคิด TDD (Test Driven Development) เพื่อทบทวนความเข้าใจในเรื่อง Small step (Increamental step) นั่นคือการสร้างระบบให้โตขึ้นอย่างต่อเนื่อง และ เสถียร ด้วยการเขียนชุดการทดสอบนั่นเอง โดยได้ฝึกตามบทความเรื่อง The Right Tests in The Wrong Order สิ่งที่ได้เจอกับตัวเองคือ ถึงแม้ว่าชุดการทดสอบจะถูกต้องและสมเหตุสมผล แต่ถ้าลำดับของการทดสอบมันผิด ก็ส่งผลต่อประโยชน์ที่จะได้รับจาก TDD เช่นกัน
วันนี้ไปแบ่งปันเรื่อง Secure Test-Driven Development ในงาน IT Connect :: MiSS Day จัดที่มหาวิทยาลัยเกษตรศาสตร์ ซึ่งสามารถสรุปเนื้อหาหลัก ๆ ได้ดังนี้
คำถามที่มักได้ยินมาเสมอ ฟังดูแล้ว TDD (Test-Driven Development) มันเป็นแนวคิดที่ดีนะ แต่เราควรนำมาใช้หรือเปล่านะ ? มันเหมาะสมกับเราหรือเปล่านะ ? ก่อนที่จะตอบนั้น ผมแนะนำให้ทดลองก่อนไหม ว่าแนวคิด และ เทคนิคของ TDD มันช่วยปรับปรุง code และ การพัฒนาระบบงานหรือไม่ ? คำถามต่อมาคือ แล้วจะทดลองกันอย่างไรดีล่ะ
คำถามที่น่าสนใจเกี่ยวกับ Test-Driven Development (TDD) การเริ่มเขียนด้วย Failing test หมายถึงอะไร ? ทำไมต้องเริ่มด้วย Failing test ด้วย ? ลองมาหาคำตอบให้ตัวเองกันหน่อยไหม ? แน่นอนว่า เป็นวิธีการที่ต้องทำให้เราคิดก่อนว่า (Think before Act) เรากำลังจะทำอะไร เรากำลังจะแก้ไขสิ่งใด นั่นคือ เรารู้ และ ควบคุมตัวเราเองว่า กำลังทำอะไรอยู่ และในเวลาหนึ่ง ๆ ควรทำ หรือ แก้ไขปัญหาเพียงปัญหาเดียวเท่านั้น
Spaghetti Driven Development มันเป็นอย่างไร ? เป็นอีกหนึ่งวิธีการของการพัฒนา software !! โดยมีขั้นตอนดังนี้ เขียน code โครตแย่ออกมา ทำการ refactor code ให้ code ดีขึ้นและเข้าใจได้ง่ายขึ้น ทำการเขียนชุดการทดสอบ ฟังแล้วมันดูดีมาก แต่ส่วนใหญ่มักจะทำเพียงขั้นตอนแรกเท่านั้น จึงทำให้เกิด Spaghetti code ออกมาจำนวนมาก และไม่มีใครกล้าแตะต้องมัน ใจร้ายกันมาก ๆ
ผมเชื่อว่า Developer ทุกคนทำการทดสอบสิ่งที่ตัวเองสร้าง แต่ Developer บางคนอาจจะไม่เขียน test ขึ้นมา (Manual test) แต่ Developer หลายคนอาจจะเขียน test ขึ้นมา ( Automated test ) เพื่อทำการตรวจสอบสิ่งที่กำลังแก้ไข ว่าทำงานได้อย่างถูกต้อง เพื่อทำให้มีความมั่นใจต่อระบบที่กำลังพัฒนา แต่ปัญหาที่มักพบเจอมาก ๆ สำหรับ Testa ก็คือ Developer มักจะไม่ค่อยสนใจ test มากเท่าไร Developer มักจะไม่ทำการ refactor test เลย Developer ไปสนใจเพียง production code เท่านั้น สุดท้าย test มันกลับก่อให้เกิดปัญหาตามมา ดังนั้น เรามา refactor test กันหน่อยดีไหม
จาก VDO เรื่อง Test Driven Development(TDD) for iOS (and anything) ของคุณ Jon Reid ได้พูดถึงเรื่องการจัดการ dependency เพื่อทำให้ code ของเรานั้นมันไม่ผูกติดกันมากไป (Loose coupling) และสามารถทดสอบได้ง่าย จึงทำการสรุปไว้นิดหน่อย