บทความ IT เจ๋งๆ

ทำไมถึงควรทำ Test-Driven Development

10-เม.ย.-18

คัมภีร์เทพ IT

ถ้าคุณเป็นคนไอทีที่ต้องพัฒนา Software อยู่ อยากแนะนำให้อ่านบทความนี้ เพราะคุณ Matthew Kane Parker ได้อธิบายถึงประโยชน์ของ Test-Driven Development และยังเป็นเหตุผลที่คุณไม่ควรกลัวการ Refactoring เรามาดูกันว่า ทำไมถึงควร Test-Driven Development กันครับ

ก่อนอื่นลองดูกราฟของความเร็วกับเวลา ซึ่งเปรียบเทียบกันระหว่าง 2 ทีม ถ้าเป็นคุณจะเลือกทีมใด

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

ทีมงานที่ใช้ Extreme Programming (XP) เชื่อว่า Software ที่ดีที่สุดถูกสร้างขึ้นผ่านกระบวนการเรียนรู้ซึ่งจำเป็นต้องให้พวกเขาส่งมอบ Software ให้กับ User, รับ Feedback จาก User และทำเช่นนี้ซ้ำๆ กับ Product อย่างต่อเนื่อง แต่คุณไม่สามารถทำเช่นนั้นได้หากทีมของคุณเป็นอย่างแบบแรก คุณควรมีทีมที่เป็นแบบที่ 2 ซึ่งต้องทำงานได้รวดเร็วไปตลอด

มีเหตุผลหลายอย่าง ที่ทำให้ทีมทำงานช้าลง แต่มีสิ่งหนึ่งที่ทำให้ทีมงานของเราทำงานช้าลงอยู่เสมอคือ Code ที่แย่ๆ (Bad Code)

ทีมงานที่เป็นอย่างกราฟแรกเป็นเหมือนทีมที่ทำงานแบบส่งๆ แบบขอไปที (เช่น ไม่ได้ Clean Code หรือ พวกเขาสร้างข้อผิดพลาดต่างๆ ไว้มากมาย เป็นต้น) ถ้าคุณทำงานแบบส่งๆ แน่นอนว่างานจะไปเร็วมาก แต่ก็เร็วได้ไม่นาน ซึ่งถือเป็นการทำงานที่ผิดพลาดมาก ที่สำคัญคือ มันจะไม่สามารถไปได้อย่างรวดเร็วในระยะยาว และการพัฒนา Codebase อย่างรวดเร็วเกินไปก็เหมือนกับ Software ที่ขาดสถาปัตยกรรมที่ดี จนในที่สุดก็ถึงจุดที่ไม่สามารถแก้ไขได้ และ Software Engineer เหล่านั้นจะไม่มีทางเลือก คือจะต้องเริ่มต้นใหม่และลองทำมันอีกครั้ง

ถ้าคุณต้องการทำงานได้รวดเร็วไปตลอด คุณต้องมี Clean Code แต่คุณไม่ควร Clean Code เพียงครั้งเดียว แต่ต้องทำอยู่เรื่อยๆ การทำ Clean Code ของคุณก็เหมือนกับการอาบน้ำ คือต้องอาบน้ำอย่างสม่ำเสมอ ยิ่งคุณปล่อยไว้นานเท่าไร คุณก็ต้องใช้วเลาทำความสะอาดยากและนานขึ้น

เพื่อให้ Code ของคุณ Clean คุณต้อง Refactor มันอย่างต่อเนื่อง ทุก Feature ใหม่ที่คุณเพิ่มลงใน Codebase ของคุณ มันเหมือนเป็นการท้าทายสมมติฐานของการ Design Code และคุณก็มีทางเลือก 2 ทางคือ คุณจะหาวิธีแก้ไขปัญหาการ Design ที่ไม่ถูกต้องใน Code ของคุณ หรือคุณจะใช้เวลาในการแก้ไขปัญหา เพื่อที่จะ Refactor มันซะใหม่ ในกราฟแรกแม้จะเร็วตอนต้นแต่สุดท้ายก็มีโอกาสทำให้ทีมล้มเหลวได้ง่าย แต่การทำ Refactoring จะทำให้คุณเป็นแบบกราฟที่ 2 คือ มีความเร็วสม่ำเสมอ ด้วยการควบคุม Behavior ของ system ไว้อย่างต่อเนื่องในขณะที่ Clean up การ Design ที่จำเป็นหรือสำคัญๆ

แต่ทีมส่วนใหญ่มักไม่ทำ Refactor เพราะพวกเขากลัวที่จะทำมัน ที่จริงพวกเขาก็รู้ว่า Code ของพวกเขามันแย่ แต่ไม่แน่ใจว่าทุกอย่างจะยังคงทำงานอยู่หรือไม่หลังจากได้ Clean Code แล้ว และในการ Refactor Code ของคุณอย่างต่อเนื่อง คุณควรต้องมี ความมั่นใจและเชื่อมั่น (Confidence) ว่าการ Refactoring จะทำให้ Software ของคุณยังคงทำงานได้ดีอยู่ และคุณจะไม่ทำให้มันแย่ลงกว่าเดิมแน่นอน

แต่น่าเสียดายที่คุณไม่มีไม้กายสิทธิ์ที่จะโบกแล้ว ไปพิสูจน์ว่าระบบของคุณยังคงทำงานอยู่หรือไม่ คุณต้องทำมันด้วยตัวเอง หากงานนั้นมันดูหนักเกินไป หรือต้องใช้เวลานานเกินไป คุณก็อาจจะไม่อยากทำมัน นั่นเป็นสาเหตุที่ทีม QA ถึงไม่ต่อยอยากทำ มันต้องใช้เวลานานกว่าที่ Engineer จะทราบว่าการเปลี่ยนแปลงที่เกิดขึ้นนั้น ส่งผลต่อการทำงานของ Software หรือไม่ วิธีเดียวที่จะทำให้มั่นใจได้อย่างรวดเร็ว คือการเขียน Test นั่นเอง การ Test จะทำให้คุณมั่นใจ ในการทำ Refactor Code ของคุณเพื่อให้ Clean ซึ่งจะทำให้คุณสามารถทำงานได้รวดเร็วไปตลอด

ดังนั้น ทำให้เกิดคำถามใหม่คือ คุณจะทำมันเมื่อไร คุณจะเขียน Test ตอนไหน และคำตอบมันก็ชัดเจนว่า ทุกอย่างขึ้นอยู่กับการ Test ซึ่งเป็นสิ่งที่สำคัญมาก ดังนั้น คุณจะทำสิ่งที่สำคัญที่สุดตอนไหนล่ะ แน่นอนว่าต้องทำมันก่อนน่ะสิ นั่นคือเหตุผลที่ว่า ทำไมถึงควรทำ Test-Driven Development

มีเหตุผลหลายอย่าง ที่ทำให้เราเขียน Test ก่อน แทนที่จะภายหลังจากที่เราเขียน Production Code การเขียน Test ก่อนจะช่วยให้เราหาข้อผิดพลาดและคิดเกี่ยวกับ API ของเรา มันจะบังคับให้เรามีความชัดเจนเกี่ยวกับ Behavior ที่เรากำลังพยายามสร้างขึ้น เนื่องจากเราไม่สามารถเขียน Test ได้โดยปราศจากความชัดเจน และยังช่วยให้เราทราบเมื่อเราทำมันเสร็จแล้ว นอกจากนี้มันยังช่วยให้เราวัดผลได้ง่ายขึ้น รวมทั้ง Maintain การ Implement โดยการสร้าง Test เพื่อให้มันผ่านไปทีละขั้น และเขียน Code ที่เพียงพอเพื่อให้การ Test แต่ละครั้งผ่านไปได้อย่างเหมาะสม นอกจากนี้การเขียน Test ก่อนการใช้งาน จะทำให้เรามั่นใจว่า ชุดการ Test ไม่ได้ให้ข้อมูลผิดพลาดแก่เรา ในช่วงแรกเราอาจพบว่าการ Test เกิดความล้มเหลวด้วยเหตุผลที่เราคาดเดาเอาไว้ แต่จากนั้นเราจะทำสิ่งที่ง่ายที่สุดเพื่อที่เราจะสามารถทำให้มน่ชชันผ่านไปได้

ที่มา:  https://builttoadapt.io/

 

 

รับตำแหน่งงานไอทีใหม่ๆ ด้วยบริการ IT Job Alert

 

อัพเดทบทความจากคนวงในสายไอทีทาง LINE ก่อนใคร
อย่าลืมแอดไลน์ @techstarth เป็นเพื่อนนะคะ

เพิ่มเพื่อน

 

บทความที่เกี่ยวข้อง

ประเภทบทความ