Esiste un anti-pattern formale per descrivere lo scenario?

Lava flow?

In computer programming jargon, lava flow is a problem in which computer code written under sub-optimal conditions is put into production and added to while still in a developmental state.

From the Perl Design Wiki: Lava Flow is "when code ... spews forth and becomes permanent, it becomes an architectural feature of the archaeological variety. Things are built atop the structure without question and without hope of changing what is beneath them. The existing code is seen as an historical curiosity."

Often, putting the system into production results in a need to maintain backward compatibility (as many additional components now depend on it) with the original, incomplete design.

Lava flows are often exacerbated by changes in the development team working on a project. As workers cycle in and out of the project, knowledge of the purpose of aspects of the system can be lost, and rather than clean up these pieces, they are worked around, increasing the complexity and mess of the system.

Lava flow is considered an anti-pattern, a commonly encountered phenomenon leading to poor design.

Non sono sicuro che si tratti di un anti-modello. Come con tutti gli anti-schemi, dobbiamo prendere la tua parola che chiunque abbia pensato che fosse una buona idea era sbagliato, ma in questo caso sembra plausibile e ti prendo in parola, quindi non è questo il problema.

Il problema è che per essere utile un anti-pattern deve descrivere una sorta di trappola generale e come può essere evitato. In questo caso, immagino che sarebbe trovare un work-around per il codice che si comporta male quando si poteva semplicemente farlo funzionare meglio.

Il problema con questo come anti-pattern, IMHO, è che la conoscenza di esso sembra improbabile che abbia molto valore. Chiunque abbia fatto questo presumibilmente già capito che sarebbe bello sapere come farlo funzionare meglio, quindi non devono sapere come farlo. Quindi avere sentito parlare della situazione generale come un anti-modello non avrebbe davvero aiutato.

Per quanto riguarda un termine generico per descriverlo, "fallimento a cascata", come hai suggerito, funziona piuttosto bene. Il termine che mi piace per le persone non qualificate in una missione che non aveva senso in primo luogo è snark hunting , ma sembra troppo duro per questa situazione. (Ma in qualche modo scaricherò in qualche modo gratuitamente il link, poiché è la miglior rappresentazione di un'impresa condannata che conosco).

Non è sicuro se questo aiuti, ma l'automazione dell'ufficio è spesso un caso speciale:

L'automazione di ufficio viene solitamente eseguita in questo modo se deve essere automatizzata da un desktop utente (specialmente per i siti Web .net perché i documenti di automazione dell'ufficio avvertono correttamente che ci saranno perdite di dati negli strumenti di interoperabilità degli uffici se vengono eseguiti senza headless. Quando sono stato costretto a scrivere processi headless per generare documenti d'ufficio con quel toolkit, abbiamo chiamato i servizi sacrificali perché dovevi ucciderli periodicamente per riavere la memoria.

Oltre all'archiviazione, ciò che stai descrivendo è, sfortunatamente, una buona pratica in alcuni casi.

Link: link