ข้อ จำกัด ของการพัฒนาระบบขับเคลื่อนทดสอบ (และโดยทั่วไป Agile) มีความเกี่ยวข้องกันจริงหรือไม่?

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

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

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

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

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

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

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

ฉันสามารถจินตนาการถึงสถานการณ์ที่สิ่งนี้สามารถเกิดขึ้นได้ในความเป็นจริง: เมื่อคุณเลือกสถาปัตยกรรมที่ผิดในแบบที่คุณต้องสร้างการทดสอบที่มีอยู่ทั้งหมดของคุณอีกครั้งตั้งแต่เริ่มต้น ให้บอกว่าคุณเริ่มใช้กรณีทดสอบ 20 ข้อแรกในการเขียนโปรแกรมภาษา X บนระบบปฏิบัติการ A โชคไม่ดีที่ข้อกำหนดที่ 21 ระบุว่าโปรแกรมทั้งหมดต้องทำงานบนระบบปฏิบัติการ B โดยที่ X ไม่สามารถใช้งานได้ ดังนั้นคุณต้องทิ้งงานส่วนใหญ่ของคุณและปรับใช้ภาษา Y ใหม่ (แน่นอนคุณจะไม่ทิ้งรหัสทั้งหมด แต่ส่งไปยังภาษาและระบบใหม่)

สิ่งนี้สอนเราแม้ว่าจะใช้ TDD เป็นความคิดที่ดีที่จะทำการวิเคราะห์และออกแบบโดยรวมก่อน อย่างไรก็ตามสิ่งนี้ก็เป็นจริงสำหรับวิธีการอื่นใดดังนั้นฉันไม่เห็นว่านี่เป็นปัญหา TDD โดยธรรมชาติ และสำหรับงานการเขียนโปรแกรมส่วนใหญ่ในโลกแห่งความเป็นจริงคุณสามารถเลือกสถาปัตยกรรมมาตรฐาน (เช่นภาษาโปรแกรม X, ระบบปฏิบัติการ Y, ระบบฐานข้อมูล Z บนฮาร์ดแวร์ XYZ) และคุณสามารถมั่นใจได้ว่าวิธีการทำซ้ำหรือเปรียวเช่น TDD จะไม่นำคุณไปสู่ความตาย

การอ้างถึง Robert Harvey: "คุณไม่สามารถสร้างสถาปัตยกรรมจากการทดสอบหน่วยได้" หรือ pdr: "TDD ไม่เพียง แต่ช่วยฉันในการออกแบบขั้นสุดท้ายที่ดีที่สุดเท่านั้น แต่ยังช่วยให้ฉันไปถึงที่นั่นด้วยความพยายามน้อยลง"

ดังนั้นสิ่งที่คุณเขียน

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

อาจกลายเป็นจริง - เมื่อคุณเลือกสถาปัตยกรรมที่ไม่ถูกต้องคุณจะไม่สามารถเข้าถึงโซลูชันที่ต้องการได้

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

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

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

1. ครบถ้วนปัญหา: วิธีการหลายการทดสอบมีความจำเป็นที่จะสมบูรณ์อธิบายระบบหรือไม่? "การเข้ารหัสตามตัวอย่างกรณี" เป็นวิธีที่สมบูรณ์ในการอธิบายระบบหรือไม่?

2. แข็งปัญหา: สิ่งที่ทดสอบอินเตอร์เฟซที่จะต้องมีอินเตอร์เฟซที่เปลี่ยนไม่ได้ การทดสอบแสดงถึงความจริงที่ไม่เปลี่ยนแปลงจำได้ น่าเสียดายที่ความจริงเหล่านี้ไม่เป็นที่รู้จักสำหรับรหัสส่วนใหญ่ที่เราเขียนเท่านั้นที่ดีที่สุดสำหรับวัตถุที่หันเข้าหาภายนอก

3. ความเสียหายทดสอบปัญหา: เพื่อให้ยืนยันทดสอบเราอาจจำเป็นต้องเขียนโค้ดด้อย (performant น้อยตัวอย่างเช่น) เราจะเขียนการทดสอบอย่างไรเพื่อให้รหัสนั้นดีเท่าที่ควรจะเป็น?

แก้ไขเพื่อแก้ไขความคิดเห็น: นี่เป็นตัวอย่างของการกระตุ้นค่าสูงสุดในท้องถิ่นสำหรับฟังก์ชั่น "double" ผ่านการรีแฟคเตอร์

ทดสอบ 1:เมื่ออินพุทเป็น 0 ให้คืนศูนย์

การดำเนินงาน:

function double(x) {
  return 0; // simplest possible code that passes tests
}

Refactoring:ไม่จำเป็น

ทดสอบ 2:เมื่ออินพุทคือ 1 คืนค่า 2

การดำเนินงาน:

function double(x) {
  return x==0?0:2; // local maximum
}

Refactoring:ไม่จำเป็น

ทดสอบ 3:เมื่ออินพุทคือ 2 คืนค่า 4

การดำเนินงาน:

function double(x) {
  return x==0?0:x==2?4:2; // needs refactoring
}

refactoring:

function double(x) {
  return x*2; // new maximum
}

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

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

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

ในคำตอบของเขา @Sklivvz ให้เหตุผลว่าปัญหานั้นไม่มีอยู่จริง

ฉันต้องการที่จะยืนยันว่ามันไม่สำคัญ: สถานที่ตั้งพื้นฐาน (และ raison d'retre) ของวิธีการทำซ้ำโดยทั่วไปและ Agile และโดยเฉพาะอย่างยิ่ง TDD โดยเฉพาะอย่างยิ่งนั่นไม่เพียง แต่เป็นสิ่งที่ดีที่สุดในโลก ไม่เป็นที่รู้จัก ดังนั้นในคำอื่น ๆ : แม้ว่าจะเป็นปัญหาก็ไม่มีทางทำซ้ำได้ สมมติว่าคุณยอมรับหลักฐานขั้นพื้นฐาน

แนวทางปฏิบัติของ TDD และ Agile สามารถรับประกันได้ว่าจะสร้างทางออกที่ดีที่สุดได้หรือไม่? (หรือแม้แต่โซลูชันที่ "ดี")

ไม่แน่นอน แต่นั่นไม่ใช่จุดประสงค์ของพวกเขา

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

... [TDD] ตรงข้ามกับการพัฒนาซอฟต์แวร์ที่อนุญาตให้เพิ่มซอฟต์แวร์ที่ไม่ได้รับการพิสูจน์ว่าตรงตามข้อกำหนด ... Kent Beck ผู้ซึ่งให้เครดิตว่ามีการพัฒนาหรือ 'ค้นพบใหม่' เทคนิคระบุไว้ในปี 2003 ว่าTDD ส่งเสริมให้ง่าย การออกแบบและสร้างแรงบันดาลใจความมั่นใจ ( Wikipedia )

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

สำหรับกระบวนการเปรียว:

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

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

แต่นั่นก็โอเคเพราะคำถามนั้นผิด

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

อย่างน้อยที่สุดวิธีปฏิบัติของ TDD และ Agile ยอมรับความยากลำบากและพยายามปรับให้เหมาะสมสำหรับสองสิ่งที่มีวัตถุประสงค์และสามารถวัดได้: Working v. Not-WorkingและSooner v ภายหลัง

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

สิ่งที่คุณสามารถตีความว่าเป็นความพยายามในการผลิตโซลูชั่นที่ดีที่สุดรวมถึงสิ่งต่าง ๆ เช่น:

• หลักการที่เป็นของแข็ง
• ทำความสะอาดรหัส
• รูปแบบการออกแบบ
• จ้างคนที่มีทักษะและประสบการณ์ ...

ฯลฯ ..

_{ไม่ว่าแต่ละสิ่งเหล่านั้นจะสร้างทางออกที่ดีที่สุดจริง ๆ หรือไม่ก็เป็นคำถามที่ยอดเยี่ยมที่จะถาม!}

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

ในโลกแห่งความเป็นจริงการทดสอบของคุณโดยทั่วไปจะใช้และตรวจสอบกฎเกณฑ์ทางธุรกิจ:

ตัวอย่างเช่น - หากลูกค้าอายุ 30 ปีที่ไม่ได้สูบบุหรี่กับภรรยาและลูกสองคนประเภทพรีเมี่ยมคือ "x" เป็นต้น

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

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

ฉันไม่คิดว่ามันจะเข้าทาง ทีมส่วนใหญ่ไม่มีใครที่มีความสามารถในการหาทางออกที่ดีที่สุดแม้ว่าคุณจะเขียนมันลงบนไวท์บอร์ด TDD / Agile จะไม่เข้าทาง

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

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

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

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

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

การเคลื่อนไหวแบบว่องไวเป็นปฏิกิริยาต่อความเชื่อที่ว่าการพัฒนาซอฟต์แวร์สามารถวางแผนและทำนายด้วยวิธีการทางคณิตศาสตร์ได้ ไม่ว่าจะดีขึ้นหรือแย่ลงการพัฒนาซอฟต์แวร์ก็เหมือนงานฝีมือมากกว่าวิทยาศาสตร์