Esiste un anti-modello formale per descrivere lo scenario?

Viene scritto del codice per generare fogli di calcolo Excel (Office Interop).

• Il codice funziona molto male.
  
  • Un sottosistema è progettato per generare i file durante la notte. Le prestazioni non sono un problema durante la notte.
    • Viene creata una funzione per selezionare il file corretto tra i 100 diversi file disponibili a seconda di un set di parametri scelto.
    • Poiché esistono file fisici, viene aggiunto un sistema di archiviazione per il backup di questi file (non vi è alcun motivo per archiviare. Questi file devono essere generati al volo).
    • Questo sistema non include un file di configurazione, ma ha una funzione "server picker" codificata che riflette semplicemente sul server su cui è in esecuzione il codice.
    • Un'attività pianificata è necessaria per supportare ed eseguire questo servizio.

Questo si riduce a un singolo problema. Il codice originale funziona troppo male per essere eseguito in un ambiente di produzione.

Se il problema di prestazioni fosse stato risolto, il sottosistema e successivamente il sistema di archiviazione, la "funzione di fabbrica del selettore di file", il punto di errore codificato e la manutenzione dell'attività pianificata e il suo punto di errore aggiunto non avrebbero dovuto esistere.

Questo è un "fallimento a cascata" se vuoi. Il problema originale ha portato a codice più cattivo, soluzioni più cattive e spese generali non necessarie. Esiste un termine formale o un termine generale per descriverlo?

Flusso di lava?

Nel gergo della programmazione informatica, il flusso di lava è un problema in cui il codice del computer scritto in condizioni non ottimali viene messo in produzione e aggiunto mentre si trova ancora in uno stato di sviluppo.

Dal Wiki Perl Design: Lava Flow è "quando il codice ... esce e diventa permanente, diventa una caratteristica architettonica della varietà archeologica. Le cose sono costruite in cima alla struttura senza dubbio e senza speranza di cambiare ciò che è sotto di loro. il codice esistente è visto come una curiosità storica ".

Spesso, la messa in produzione del sistema comporta la necessità di mantenere la retrocompatibilità (poiché molti componenti aggiuntivi ora dipendono da esso) con il design originale e incompleto.

I flussi di lava sono spesso esacerbati dai cambiamenti nel team di sviluppo che lavora a un progetto. Man mano che i lavoratori entrano e escono dal progetto, la conoscenza dello scopo degli aspetti del sistema può essere persa e, piuttosto che ripulire questi pezzi, vengono aggirati, aumentando la complessità e il disordine del sistema.

Il flusso di lava è considerato un anti-pattern, un fenomeno comunemente riscontrato che porta a un design scadente.

Non sono sicuro che questo sia un anti-pattern. Come con tutti gli anti-schemi, dobbiamo prendere la tua parola che chiunque abbia pensato che fosse una buona idea si è sbagliato, ma in questo caso sembra plausibile e prenderò la tua parola per questo, quindi non è questo il problema.

Il problema è che per essere utile un anti-schema deve descrivere una sorta di trappola generale e come può essere evitato. In questo caso, immagino che sarebbe trovare una soluzione per il codice che funziona male quando avresti potuto farlo funzionare meglio.

Il problema con questo come anti-pattern, IMHO, è che è improbabile che conoscerlo sia di grande valore. Chiunque abbia fatto questo presumibilmente ha già capito che sarebbe bello sapere come farlo funzionare meglio, quindi non devono aver saputo come farlo. Quindi aver sentito parlare della situazione generale come un anti-modello non avrebbe davvero aiutato.

Per quanto riguarda un termine generale 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 è caccia snark , ma sembra troppo duro per questa situazione. (Ma in qualche modo inserirò in qualche modo gratuitamente il collegamento, poiché è la migliore rappresentazione di un'impresa condannata che conosco).

Non sono sicuro se questo aiuta, ma l'automazione d'ufficio è spesso un caso speciale:

L'automazione dell'ufficio viene di solito eseguita in questo modo se deve essere automatizzata dal desktop di un utente (specialmente per i siti Web .net perché i documenti di automazione dell'ufficio ti avvisano correttamente che ci saranno cattive perdite negli strumenti di interoperabilità dell'ufficio se vengono eseguiti senza testa. costretti a scrivere processi senza testa per generare documenti d'ufficio con quel toolkit che abbiamo chiamato i servizi sacrificali perché dovevi ucciderli periodicamente per recuperare la memoria.

A parte l'archiviazione, ciò che stai descrivendo è purtroppo una buona pratica in alcuni casi.

Link: http://support.microsoft.com/kb/257757