TDD กับ sex ในวัยเรียน

มีคำกล่าวว่า “TDD ก็เหมือน sex ในวัยเรียน เราต่างคนก็คิดว่า คนอื่นๆ ทำมัน แต่ความจริงแล้ว มีน้อยคนนักที่จะทำมันจริงๆ”

เหตุที่เป็นเช่นนั้นเพราะ ในโฆษณาชวนเชื่อ จะบอกถึงประโยชน์ของ TDD ซึ่งดูดีไปเสียหมด จนเราเข้าใจว่า ระดับโลกคงใช้มันไปหมดแล้ว แต่ความเป็นจริงนั้น TDD มีข้อจำกัดมากมายที่ปิดกั้น ทำให้มันไม่สามารถเป็นที่แพร่หลาย อย่างที่หลายคนพยายามทำให้เป็น

TDD นั้นทำได้ยาก กับโค้ดที่ไม่ได้ออกแบบมาเพื่อให้เป็น TDD

เหตุผลที่เกิดเทคนิคที่เรียกว่า TDD ขึ้นนั้น เป็นเพราะศาสดา Kent Beck เล็งเห็นว่า การเขียนโค้ดก่อนแล้วจึงเขียน unit-test ทีหลังนั้นยากลำบากจนเกือยเรียกว่าเป็นไปไม่ได้ ปัญหาคือโปรเจ็คซอฟแวร์ในโลกส่วนใหญ่ไม่ใช่การเขียนขึ้นใหม่ หากแต่เป็นการแก้โค้กเก่า ที่เรามักเรียกว่า lagacy code เพราะฉะนั้น การจะทำให้โค้ดเหล่านี้สามารถ TDD ได้ ก็เกือบเรียกได้ว่า ต้องเขียนใหม่ เกือบหมด เพราะ coupling ในโค้ดมีมากเกินกว่า จะ refactor เพียงบางส่วนได้

TDD นั้นมีค่า maintenance แพงระยับ

TDD ความจริงก็คือเทคนิคการเขียนโค้ดที่จะต้อง เขียนส่วนที่เป็น unit-test ก่อน เพื่อให้มั่นใจว่า ส่วนโค้ดนั้น มี unit-test รองรับเสมอ ในสถานการณ์จริงนั้น ส่วนที่เป็น business logic จะมีการเปลี่ยนแปลงตลอดเวลา ทำให้ ปริมาณโค้ดที่ต้อง maintain อาจจะเพิ่มขึ้น สองหรือสามเท่าเลยทีเดียว เรียกได้ว่า เทียบกับการ manual test แบบโบราณแล้ว อาจจะใช้เวลาไม่ต่างกันมากก็ได้

TDD นั้นเร็วจริง แต่คนที่ต้องการความเร็วระดับนั้นมีไม่มากขนาดที่เราคิด

จริงอยู่ถ้าหากไม่ใช่ TDD คงไม่สามารถ release ซอฟแวร์ ขึ้นโปรดักชั่นทุกสองถึงสามอาทิตย์ได้ แต่ความจริงคือ มีโปรเจ็คซอฟแวร์สักกี่โปรเจ็คที่ต้องการความเร็วระดับนั้น ความจริงแล้วการ release ได้ทุกสองถึงสามเดือน ก็เป็นที่พอใจมากแล้วสำหรับ โปรเจ็คส่วนใหญ่ ซึ่งด้วยความเร็ซระดับนี้ การใช้ manual testing ก็ไม่ได้เป็นอุปสรรคอะไรมากมาย

ROI ของ TDD จะเกิดขึ้นคุ้มค่าเมื่อเวลาผ่านไปนานระดับหนึ่ง

ความจริงแล้ว ต้นทุนของ TDD นั้นไม่ใช่เพียงแค่เวลาเพียงอย่างเดียว แต่มีอีกส่วนคือเรื่อง skill ของ developer เนื่องจาก การจะทำได้ต้องใช้ developer ที่มี skill สูงกว่าปกติ ทำให้ค่าตัวแพงตามไปด้วย ซึ่งโปรเจ็คส่วนใหญ่ไม่สามารถลงทุนได้มากขนาด และที่สำคัญกว่า การลงทุนนี้จะคืนกลับมาคุ้มค่า ก็ต่อเมื่อโปรเจ็คเติบโตขึ้นถึงระดับหนึ่ง ที่ไม่สามารถมีคนสองสามคนรู้ทุกเรื่องใน codebase หรือ คนที่รู้ทุกเรื่องไม่ได้อยู่กับองค์กรแล้ว ซึ่งปกติ ต้องใช้เวลา 3-5 ปีเป็นอย่างน้อย แต่สำหรับ โปรเจ็คทั่วไป โดยเฉพาะ ในเมืองไทย โปรเจ็คส่วนใหญ่ จะจบลงภายใน 1-2 ปีเท่านั้น ทำให้ คนที่ได้ผลประโยชน์จาก TDD นั้นกลับไม่ใช่คนที่ริเริ่มทำ TDD ขึ้น เพราะเปลี่ยนตัวคนทำไปแล้ว

TDD ต้องการความรู้เกี่ยวกับ business logic มาก

ในหลายธุรกิจ มี business logic ที่ซับซ้อน หรือเปลี่ยนแปลงบ่อย จนงง ตัวอย่างเช่น สาย finance หรือ telecom ทำให้ การที่ developer จะมีความเข้าใจถ่องแท้ ถึง test cases และ scenarios อย่างครบถ้วนด้วยตัวเองนั้นเป็นไปได้ยาก กล่าวคือ จะต้องมี business user เข้าประกบ ในการทำ TDD ด้วย แต่ทว่า ค่าตัวหรือเวลาที่คนเหล่านี้สามารถให้กับทีมได้นั้น ไม่ได้มีมากมายนัก ทำให้ พวกเขาไม่สามารถ contribute ให้กับทีมได้อย่างเพียงพอ จึงไม่สามารถ TDD อย่างต่อเนื่องได้ สุดท้ายทำให้การทำ SIT และ UAT กลับมีความคุ้มค่าทาง business สูงกว่า

ลองถามตัวเองง่ายๆ ว่า เคยเห็น โปรเจ็คจริงๆ ที่ไม่ใช่ workshop หรือ training ใช้ TDD หรือไม่? ถ้าเคยมีมากน้อยเพียงใด

ปล. TDD และ การมี unit-test นั้น อาจจะดูคล้ายกัน แต่ความจริง แตกต่างที่ลำดับการทำงาน ว่าเขียนโค้ดก่อนหรือเขียน test ก่อน ซึ่งในทางปฏิบัติจะแตกต่างกันเป็นอย่างมาก

Advertisements

ใส่ความเห็น

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s