คนที่ทำ TDD จะจัดการกับการสูญเสียงานเมื่อทำ refactoring สำคัญได้อย่างไร

ในขณะที่ฉันพยายามเรียนรู้การเขียนการทดสอบหน่วยสำหรับรหัสของฉัน

ตอนแรกฉันเริ่มต้นทำ TDD จริงซึ่งฉันจะไม่เขียนโค้ดใด ๆ จนกว่าฉันจะเขียนการทดสอบที่ล้มเหลวก่อน

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

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

ฉันอดไม่ได้ที่จะคิดว่าฉันได้ลองใช้เวลา 3 หรือ 4 วันในการเขียนแบบทดสอบเมื่อฉันสามารถใส่รหัสเข้าด้วยกันเพื่อพิสูจน์แนวคิดแล้วเขียนการทดสอบหลังจากนั้นเมื่อฉันมีความสุขกับวิธีการของฉัน

คนที่ฝึกฝน TDD รับมือกับสถานการณ์เช่นนี้ได้อย่างไร? มีกรณีสำหรับการดัดกฎในบางกรณีหรือคุณมักจะเขียนแบบทดสอบก่อนเสมอแม้ว่ารหัสนั้นอาจไร้ประโยชน์หรือไม่?

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

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

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

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

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

ตัวอย่างเช่นถ้าฉันต้องการเขียน PDE (สมการเชิงอนุพันธ์ย่อย) ฉันจะเขียนการทดสอบสองสามพยายามแก้ปัญหาที่ฉันสามารถแก้ปัญหาทางคณิตศาสตร์ได้ นี่คือการทดสอบ "หน่วย" ครั้งแรกของฉัน - อ่าน: การทดสอบการใช้งานทำงานเป็นส่วนหนึ่งของกรอบ xUnit สิ่งเหล่านั้นจะไม่เปลี่ยนแปลงขึ้นอยู่กับว่าฉันใช้อัลกอริทึมใดในการแก้ PDE ทั้งหมดที่ฉันสนใจคือผลลัพธ์ การทดสอบหน่วยที่สองจะมุ่งเน้นไปที่ฟังก์ชั่นที่ใช้ในการเขียนอัลกอริธึมและดังนั้นจึงเป็นขั้นตอนวิธีที่เฉพาะเจาะจง - บอกว่า Runge-Kutta หากฉันพบว่า Runge-Kutta นั้นไม่เหมาะสมฉันก็จะยังคงมีการทดสอบระดับสูง (รวมถึงการทดสอบที่แสดงว่า Runge-Kutta นั้นไม่เหมาะสม) ดังนั้นการทำซ้ำครั้งที่สองจะยังคงมีการทดสอบจำนวนมากเหมือนกับการทดสอบครั้งแรก

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

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

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

ฉันคิดว่าคุณพูดด้วยตัวเอง: คุณไม่แน่ใจเกี่ยวกับวิธีการของคุณก่อนที่จะเริ่มเขียนบททดสอบทั้งหมด

สิ่งที่ฉันได้เรียนรู้เปรียบเทียบโครงการ TDD ในชีวิตจริงที่ฉันทำงานด้วย (ไม่มากในความเป็นจริงเพียง 3 ครอบคลุม 2 ปีของการทำงาน) กับสิ่งที่ฉันได้เรียนรู้ในทางทฤษฎีคือการทดสอบอัตโนมัติ! = การทดสอบหน่วย แต่เพียงผู้เดียว)

กล่าวอีกนัยหนึ่ง T ใน TDD ไม่จำเป็นต้องมี U ด้วย ... มันเป็นแบบอัตโนมัติ แต่มีการทดสอบหน่วยน้อยกว่า (เช่นในชั้นเรียนการทดสอบและวิธีการ) น้อยกว่าการทดสอบการทำงานอัตโนมัติ: อยู่ในระดับเดียวกัน การทำงานที่ละเอียดเป็นสถาปัตยกรรมที่คุณกำลังทำงานในปัจจุบัน คุณเริ่มต้นในระดับสูงด้วยการทดสอบเพียงเล็กน้อยและมีเพียงภาพใหญ่ที่ใช้งานได้และในที่สุดคุณก็จะจบลงด้วย UT หลายพันรายการและคลาสทั้งหมดของคุณได้รับการกำหนดไว้อย่างดีในสถาปัตยกรรมที่สวยงาม ...

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

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

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

คนที่ฝึกฝน TDD รับมือกับสถานการณ์เช่นนี้ได้อย่างไร?

1. โดยพิจารณาว่าเมื่อใดที่จะต้องสร้างต้นแบบเทียบกับเมื่อถึงรหัส
2. โดยตระหนักว่าการทดสอบหน่วยนั้นไม่เหมือนกับ TDD
3. โดยการเขียนการทดสอบ TDD เพื่อตรวจสอบคุณสมบัติ / เรื่องไม่ใช่หน่วยการทำงาน

Conflation ของการทดสอบหน่วยที่มีการพัฒนาที่ขับเคลื่อนด้วยการทดสอบนั้นเป็นที่มาของความปวดร้าวและความฉิบหายมากมาย ดังนั้นเรามาทบทวนอีกครั้ง:

• การทดสอบหน่วยเกี่ยวข้องกับการตรวจสอบแต่ละโมดูลและฟังก์ชั่นในการดำเนินการ ; ใน UT คุณจะเห็นความสำคัญของสิ่งต่าง ๆ เช่นการวัดความครอบคลุมของรหัสและการทดสอบที่ดำเนินการอย่างรวดเร็ว
• การพัฒนาที่ขับเคลื่อนด้วยการทดสอบนั้นเกี่ยวข้องกับการตรวจสอบแต่ละคุณสมบัติ / เรื่องราวในข้อกำหนด ; ใน TDD คุณจะเห็นความสำคัญกับสิ่งต่าง ๆ เช่นการเขียนการทดสอบก่อนเพื่อให้แน่ใจว่าโค้ดที่เขียนนั้นไม่เกินขอบเขตที่ตั้งใจไว้และการปรับปรุงคุณภาพ

โดยสรุป: การทดสอบหน่วยมีการมุ่งเน้นการใช้งาน TDD มีการมุ่งเน้นข้อกำหนด พวกเขาไม่เหมือนกัน

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

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

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

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

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

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

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

ฉันไม่แน่ใจเกี่ยวกับสาเหตุที่วิธีการของคุณกลายเป็นข้อบกพร่องหลังจาก 3 วัน คุณอาจพิจารณาเปลี่ยนกลยุทธ์การทดสอบของคุณทั้งนี้ขึ้นอยู่กับความไม่แน่นอนของคุณในสถาปัตยกรรม:

• หากคุณไม่แน่ใจเกี่ยวกับประสิทธิภาพคุณอาจต้องการเริ่มต้นด้วยการทดสอบการรวมสองสามอย่างที่ยืนยันประสิทธิภาพ

• เมื่อความซับซ้อนของ API คือสิ่งที่คุณกำลังตรวจสอบอยู่ให้เขียนการทดสอบหน่วยเปล่าและการทดสอบหน่วยเล็ก ๆ เพื่อหาสิ่งที่จะเป็นวิธีที่ดีที่สุด อย่าไปสนใจการนำอะไรมาใช้เพียงแค่ทำให้คลาสของคุณคืนค่าที่กำหนดไว้อย่างแรงหรือทำให้พวกมันทิ้ง NotImplementedExceptions

สำหรับฉันการทดสอบหน่วยยังเป็นโอกาสที่จะทำให้อินเทอร์เฟซภายใต้การใช้งาน "ของจริง" (เช่นเดียวกับการทดสอบตามหน่วยจริง!)

หากฉันถูกบังคับให้ตั้งค่าการทดสอบฉันต้องฝึกการออกแบบของฉัน สิ่งนี้จะช่วยให้สิ่งต่าง ๆ มีสติ (ถ้าบางสิ่งบางอย่างมีความซับซ้อนมากที่การเขียนการทดสอบสำหรับมันเป็นภาระสิ่งที่มันจะชอบที่จะใช้?)

สิ่งนี้ไม่ได้หลีกเลี่ยงการเปลี่ยนแปลงในการออกแบบ แต่เป็นการเปิดเผยถึงความต้องการของพวกเขา ใช่การเขียนใหม่ทั้งหมดเป็นความเจ็บปวด เพื่อ (พยายาม) หลีกเลี่ยงมันฉันมักจะตั้งค่าต้นแบบ (หนึ่งหรือมากกว่า) อาจเป็น Python (กับการพัฒนาขั้นสุดท้ายใน c ++)

จริงอยู่ที่คุณไม่ได้มีเวลาสำหรับสารพัดทั้งหมดเหล่านี้ เหล่านี้เป็นอย่างแม่นยำกรณีที่คุณจะต้องมีขนาดใหญ่ปริมาณของเวลาเพื่อให้บรรลุเป้าหมายของคุณ ... และ / หรือเพื่อให้ทุกอย่างภายใต้การควบคุม

ยินดีต้อนรับสู่นักพัฒนาความคิดสร้างสรรค์ของคณะละครสัตว์

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

- เขียนด้วยสัญชาตญาณของคุณ ไม่ใช่ด้วยจิตและจินตนาการของคุณ
- และหยุด
- ใช้แว่นขยายและตรวจสอบทุกคำที่คุณเขียน: คุณเขียน "ข้อความ" เพราะ "ข้อความ" อยู่ใกล้กับสตริง แต่ "คำกริยา", "คำคุณศัพท์"
หรือสิ่งที่ถูกต้องมากขึ้นเป็นสิ่งจำเป็นอ่านอีกครั้งและปรับวิธีการด้วยความรู้สึกใหม่.. หรือคุณเขียนโค้ดเกี่ยวกับอนาคต ลบออก
- แก้ไขทำงานอื่น ๆ (กีฬาวัฒนธรรมหรือสิ่งอื่น ๆ นอกธุรกิจ) กลับมาอ่านอีกครั้ง
- ทั้งหมดเข้ากันได้ดี
- ถูกต้องทำงานอื่นกลับมาอ่านอีกครั้ง
- ทั้งหมดเข้ากันได้ดีส่งผ่านไปยัง TDD
- ตอนนี้ทุกอย่างถูกต้องดี
- ลองใช้เกณฑ์มาตรฐานเพื่อชี้ให้เห็นสิ่งที่จะปรับให้เหมาะสมทำ

มีอะไรปรากฏขึ้น:
- คุณเขียนโค้ดเกี่ยวกับกฎทั้งหมด
- คุณได้รับประสบการณ์วิธีใหม่ในการทำงาน
- มีอะไรเปลี่ยนแปลงในใจคุณจะไม่มีวันกลัวการกำหนดค่าใหม่

และตอนนี้ถ้าคุณเห็น UML ดูเหมือนด้านบนคุณจะสามารถพูดว่า
"บอสฉันเริ่มต้นด้วย TDD สำหรับสิ่งนี้ .... "
มันเป็นอีกสิ่งใหม่หรือไม่?
"เจ้านายฉันจะลองทำอะไรบางอย่างก่อนตัดสินใจว่าฉันจะเขียนรหัสอย่างไร" ขอ

แสดงความนับถือจาก PARIS
Claude