ใช่ การพัฒนาที่ขับเคลื่อนด้วยการทดสอบนั้นมีประโยชน์ในด้านวิทยาศาสตร์ข้อมูล

Nov 29 2022
จากพื้นฐานด้านการวิเคราะห์และวิทยาศาสตร์ข้อมูล ฉันเคยมองว่าการทดสอบการเขียนเป็นสิ่งที่เจ็บปวด ฉันรู้ว่ามันสำคัญ แต่ฉันไม่เคยรู้ว่าจะเริ่มต้นที่ไหน และมักจะผัดวันประกันพรุ่งจนจบโครงการ

จากพื้นฐานด้านการวิเคราะห์และวิทยาศาสตร์ข้อมูล ฉันเคยมองว่าการทดสอบการเขียนเป็นสิ่งที่เจ็บปวด ฉันรู้ว่ามันสำคัญ แต่ฉันไม่เคยรู้ว่าจะเริ่มต้นที่ไหน และมักจะผัดวันประกันพรุ่งจนจบโครงการ อะไรจะน่าเบื่อไปกว่าการทดสอบโค้ดที่ใช้งานได้อยู่แล้ว

เมื่อเร็ว ๆ นี้ฉันเริ่มเห็นสิ่งต่าง ๆ ฉันค้นพบการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ: เขียนการทดสอบของคุณก่อนที่คุณจะเขียนโค้ดในส่วนที่ใช้งานได้จริงของโค้ด เป็นแนวทางปฏิบัติที่ดีที่สุดในวิศวกรรมซอฟต์แวร์ซึ่งสมควรนำไปใช้กับโครงการวิทยาศาสตร์ข้อมูลบ่อยขึ้น

Test-Driven Development (TDD) คืออะไร ?

วิธีง่ายๆ คือการใส่กรอบ Red / Green / Refactor ทุกครั้งที่คุณต้องการเพิ่มฟังก์ชันให้กับโค้ด คุณสามารถทำตามขั้นตอนสามขั้นตอน:

  1. สีแดง สร้างการทดสอบที่ล้มเหลว คือเขียนความต้องการการทำงานของรหัสของคุณ
  2. สีเขียว เขียนรหัสการผลิตที่ทำให้การทดสอบผ่าน คือตอบสนองความต้องการการทำงานของรหัส
  3. ปรับปรุงโครงสร้าง. ทำความสะอาดความยุ่งเหยิงที่คุณเพิ่งทำ เช่น ทำความสะอาดโค้ดของคุณโดยไม่ต้องเปลี่ยนฟังก์ชันการทำงาน

ลองอธิบายสิ่งนี้ด้วยตัวอย่างในชีวิตจริง ในขั้นตอนหลังการประมวลผลสำหรับโครงการNamed Entity Recognitionเราต้องการสร้าง ฟังก์ชัน การประมวลผลเพื่อแยกหน่วยระยะเวลา (วัน/ สัปดาห์/ เดือน/..) และค่าระยะเวลาในข้อความ

  1. ลองเขียนการทดสอบหน่วยที่ตรงกับความต้องการด้านการทำงานและฟังก์ชันว่าง
  2. ฟังก์ชั่น
    การทดสอบหน่วย

2.เราเขียนโค้ดที่ผ่านการทดสอบ

ข้อสอบเป็นสีเขียว ไชโย!! เดี๋ยวก่อน.. แน่ใจนะว่า DRY, SOLID, pep8??

3. เรา ปรับโครงสร้าง ฟังก์ชันใหม่เพื่อให้แน่ใจว่าแนวทางปฏิบัติที่ดีที่สุดในการเขียนโค้ด

ที่นี่เราได้เพิ่มคำอธิบายประกอบประเภท สร้างฟังก์ชันทั่วไปเพื่อแปลงเลขตัวอักษรเป็นทศนิยม (ด้วยการทดสอบหน่วยของมันเองด้วย) และปรับโครงสร้างวิธีที่เราเติมพจนานุกรม

เราจะใช้ Test-Driven Development ใน Data Science ได้ที่ใด

Test Driven Development ไม่เกี่ยวข้องกับทุกขั้นตอนของโครงการวิทยาศาสตร์ข้อมูล ตัวอย่างเช่น มันไม่คุ้มค่าระหว่างการสำรวจ ข้อมูลหรือโมเดล ที่คุณไม่แน่ใจว่ากำลังมองหาอะไร: การเขียนแบบทดสอบโดยไม่ทราบผลลัพธ์ที่คาดหวังอาจเกินความจำเป็น

มันจะมีประโยชน์มากเมื่อใดก็ตามที่คุณต้องการสร้างไปป์ไลน์การผลิตที่แข็งแกร่ง

ในบริบทนี้ เราจำเป็นต้องใช้การทดสอบหลายประเภท:

  • การทดสอบหน่วย:การทดสอบรหัสแต่ละส่วนของโครงการ
  • การทดสอบแบบจำลอง : ตรวจสอบให้แน่ใจว่าแบบจำลองมีประสิทธิภาพที่ดีและทำงานได้อย่างถูกต้อง
  • การทดสอบการรวมระบบ : ตรวจสอบให้แน่ใจว่ามีความเชื่อมโยงที่ดีระหว่างโค้ดแต่ละส่วน

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

สุดท้ายสำหรับการทดสอบการรวมจะใช้ได้ดีกับชิ้นส่วนของโค้ดที่ไม่มีการคาดการณ์โมเดล หากมีการคาดคะเนแบบจำลอง การทดสอบในรูปแบบของเอาต์พุตจะดีกว่าการทดสอบผลลัพธ์จริง

แนวทางปฏิบัติที่ดีคือการรวมการทดสอบเหล่านั้นไว้ในCI/CDของโครงการของคุณ ดังนั้นเมื่อใดก็ตามที่มีข้อเสนอฟังก์ชันการทำงานใหม่ จะต้องแน่ใจว่าไม่มีการหยุดฟังก์ชันการทำงานอื่นๆ

ทำไมมันถึงเปลี่ยนเกม?

การใช้ Test-Driven Development เปลี่ยนแปลงวิธีการจัดระเบียบเซสชันการเขียนโค้ดของคุณอย่างแท้จริง และมีประโยชน์มากมาย:

  • ตรวจสอบความถูกต้องของธุรกิจและข้อกำหนดทางเทคนิคได้ทันที นอกจากนี้ยังเป็นเอกสาร ที่ยอดเยี่ยม สำหรับนักวิทยาศาสตร์ข้อมูลที่ค้นพบโครงการและจำเป็นต้องเข้าใจว่าโครงการทำงานอย่างไร
  • มันให้ ความมั่นใจ ในรหัส ทุกกรณีการใช้งานครอบคลุมโดยการทดสอบ และคุณหรือเพื่อนร่วมทีมของคุณสามารถเพิ่มฟังก์ชันเพิ่มเติมได้โดยไม่ต้องกลัวว่าจะทำลายสิ่งที่ทำไปแล้ว
  • เป็นการประหยัดเวลา เราสามารถมองว่าเป็นสิ่งที่ชะลอการพัฒนา แต่นั่นไม่ใช่ มันบังคับให้คุณต้องคิดล่วงหน้าเกี่ยวกับความต้องการด้านการใช้งานและคาดการณ์ขอบเคส เชื่อฉันเถอะว่าท้ายที่สุดแล้ว มันช่วยประหยัดเวลาในการดีบั๊กและการวนซ้ำไปได้มาก
  • มันยิ่ง ทำให้ การพัฒนาสนุกยิ่งขึ้น ! มันแบ่งโค้ดออกเป็นความท้าทาย ใน การแก้ปัญหา เล็กๆ และเหมาะอย่างยิ่งสำหรับการเข้ารหัสเพื่อน ..