มีรูปแบบการต่อต้านอย่างเป็นทางการเพื่ออธิบายสถานการณ์หรือไม่

มีการเขียนโค้ดบางส่วนเพื่อสร้าง Excel Spreadsheets (Office Interop)

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

สิ่งนี้ทำให้เดือดร้อนเป็นปัญหาเดียว รหัสต้นฉบับทำงานได้ไม่ดีเกินกว่าที่จะเรียกใช้ในสภาพแวดล้อมการใช้งานจริงได้

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

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

ลาวาไหล?

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

จาก Perl Design Wiki: Lava Flow คือ "เมื่อโค้ด ... พ่นออกมาและกลายเป็นถาวรมันกลายเป็นคุณสมบัติสถาปัตยกรรมของความหลากหลายทางโบราณคดีสิ่งต่าง ๆ ถูกสร้างขึ้นบนโครงสร้างโดยไม่มีคำถามและไม่มีความหวังในการเปลี่ยนแปลงสิ่งที่อยู่ข้างใต้ รหัสที่มีอยู่ถูกมองว่าเป็นความอยากรู้ทางประวัติศาสตร์ "

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

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

การไหลของลาวาถือเป็นรูปแบบต่อต้านซึ่งเป็นปรากฏการณ์ที่พบได้ทั่วไปซึ่งนำไปสู่การออกแบบที่ไม่ดี

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

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

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

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

ไม่แน่ใจว่าสิ่งนี้ช่วยได้หรือไม่ แต่ระบบอัตโนมัติในสำนักงานมักเป็นกรณีพิเศษ:

Office Automation มักจะทำเช่นนี้หากจะต้องปิดเครื่องเดสก์ทอปของผู้ใช้โดยอัตโนมัติ (โดยเฉพาะสำหรับเว็บไซต์. net เนื่องจากเอกสาร Office Automation ถูกต้องเตือนคุณว่าจะมีการรั่วไหลที่ไม่ดีในเครื่องมือ interop office หากพวกเขาเรียกใช้หัวเมื่อฉัน ถูกบังคับให้เขียนกระบวนการหัวขาดเพื่อสร้างเอกสารสำนักงานด้วยชุดเครื่องมือที่เราเรียกว่าบริการการเสียสละเพราะคุณต้องฆ่าพวกเขาเป็นระยะเพื่อให้ได้หน่วยความจำกลับมา

นอกเหนือจากการเก็บถาวรสิ่งที่คุณอธิบายไว้แล้วน่าเสียดายที่แนวทางปฏิบัติที่ดีที่สุดในบางกรณี

ลิงก์: http://support.microsoft.com/kb/257757