คำถามที่มักได้ยินมาเสมอ
ฟังดูแล้ว TDD (Test-Driven Development) มันเป็นแนวคิดที่ดีนะ
แต่เราควรนำมาใช้หรือเปล่านะ ?
มันเหมาะสมกับเราหรือเปล่านะ ?
ก่อนที่จะตอบนั้น ผมแนะนำให้ทดลองก่อนไหม
ว่าแนวคิด และ เทคนิคของ TDD
มันช่วยปรับปรุง code และ การพัฒนาระบบงานหรือไม่ ?
คำถามต่อมาคือ
แล้วจะทดลองกันอย่างไรดีล่ะ ?
คำตอบสำหรับผมคือ
- ในช่วงเวลาหนึ่ง ๆ ให้ทำหรือแก้ไขปัญหาเพียงอย่างเดียว
- แต่ละ commit หรือ การเปลี่ยนแปลงต้องเล็ก ๆ
- ลองบังคับตัวเองให้ฝึกแบบนี้ดูกัน
จากนั้นลองนำแนวคิดนี้ไปแนะนำ และ พาทีมลองทำกันดูไหม
ง่าย ๆ คือ
- ใน commit แรกให้ทำการเขียน test
- ใน commit ที่สองให้ทำการเขียน code เพื่อทำให้ test ผ่าน
แต่ว่ามันยากเกินไปสำหรับนักพัฒนาหรือเปล่านะ ?
ดังนั้นลองไปถามทีมดูสิว่า
เราจะนำแนวคิด และ เทคนิคของ TDD มาใช้งานกันไหม ?
คำตอบที่มักได้ยินก็คือ
- เขียนก็ได้นะ แต่ขอเวลาเพิ่ม !!
- การพัฒนาจะช้ากว่าเดิมนะ !!
- แค่เขียน code ให้ทำงานได้ และ เสร็จก็ยากแล้วนะ นี่ต้องเขียน test อีกไม่รอดแน่นอน !!
- ต้องเพิ่มค่าใช้จ่ายเพิ่มขึ้นมากนะ 2-5 เท่าตัวเลย !!
ดังนั้นถ้าต้องการให้พัฒนาเร็ว ๆ ก็อย่าเอาแนวคิด TDD มาใช้เลยนะ !!
คำถามที่น่าสนใจคือ ทำไมการเขียน code โดยไม่มี test ถึงเร็วกว่าล่ะ ?
คำตอบคือคำถาม ลองตอบดูสิ
- เราทำการฝึกฝนแนวคิด TDD แล้วหรือยัง ?
- เราทำการฝึกฝนแนวคิด TDD เพียงพอแล้วหรือยัง ?
- เราทำการฝึกฝนแนวคิด TDD บ่อยเพียงใด ? ทุกวันหรือไม่ ?
หรือว่าเราไม่เคยฝึกฝนเลย !!
เพราะว่าถ้าเราเรียนรู้ และ ฝึกฝนสิ่งใหม่ ๆ แล้ว
มันจะทำให้เราทำงานอื่น ๆ ได้ช้าลง
หัวหน้า และ ฝ่าย management ก็กดดันมากอีก
ดังนั้น อย่าไปฝึก อย่าไปเรียนรู้อะไรใหม่เลยนะ ทำให้มันเสร็จก่อนเถอะ !!
ปล. ที่บอกว่าเขียนเร็วนั้น
ได้รวมเวลาแก้ bug หรือยัง ?
ได้รวมเวลาที่ต้องรอการทดสอบหรือยัง ?
ดังนั้นก่อนที่จะเลือกใช้หรือไม่นั้น ให้ทำการทดลองก่อนดีไหม
เพื่อทำให้
- คุณและทีมได้ฝึกฝนร่วมกัน เพื่อเรียนรู้ไปด้วยกัน
- คุณและทีมได้ลองทำอะไรในรูปแบบใหม่นั่นคือ ลองเขียน test ก่อน จากนั้นจึงเขียน code
- คุณและทีมได้ลองคิดว่า เราควรที่จะทำอะไรก่อนดี
- ทำให้คุณเข้าใจการ review code เพราะว่า คุณต้องทำการอ่านและเขียน code ทั้ง test code และ production code อยู่เสมอ
- ทำการเรียนรู้ว่าเราควรแยก What ออกจาก How นั่นคือ การเขียน test บอกว่าคุณกำลังจะทำอะไร และการเขียน code เพื่อให้ test ผ่านนั่นคือ การบอกว่าคุณทำอย่างไร สุดท้ายสิ่งที่ได้กลับมาคือ เอกสารสำคัญการอธิบาย code
คำถามต่อมาคือ แบบนี้มันไม่ทำให้เราช้าหรือ ?
ตอบได้เลยว่า ช้า
แต่มันจะช้าในช่วงเริ่มต้น
เพราะว่าคุณต้องเรียนรู้ในสิ่งใหม่
เพราะว่าคุณต้องเรียนรู้ในสิ่งที่ไม่เคยทำ
เพราะว่าคุณต้องเรียนรู้ขั้นตอนการทำงานใหม่ที่แตกต่างไปจากเดิม
ซึ่งทุกอย่างมันคือ การลงทุน (Effort = Cost)
เพื่อทำให้คุณมีความมั่นใจในการพัฒนา
ว่าทำงานได้ถูกต้องและไม่ส่งผลกระทบต่อส่วนอื่น
เพื่อทำให้ code มีเอกสารอธิบาย
เพื่อทำให้ code มีการปรับปรุงอยู่ตลอดเวลา โดยที่เราไม่กลัว
โดยการลงทุนนั้นมันย่อมมีความเสี่ยงเสมอ
แต่ว่ามันก็น่าลองนะเออ
มาถึงตรงนี้ คุณพร้อมที่จะปรับปรุงและเปลี่ยนแปลงแล้วหรือยัง ?
เพราะว่ายังมีอีกหลายสิ่งที่ต้องทำการปรับปรุงนะ
