Ambiente amnesico [chiuso]

Ci sono termini che sono vicini a descrivere ciò che vuoi, ma forse non esattamente giusto.

• Il termine Codice legacy (citato nei commenti alla domanda) viene spesso usato come termine dispregiativo perché è stato hackerato ed è diventato fragile e difficile da capire e con cui lavorare.

• Il termine Lava Flow (citato anche nei commenti alla domanda) viene utilizzato per indicare gruppi di codice che è stato lì per eoni e nessuno osa toccarli perché lavorano (o nessuno li ha mai toccati senza rompere il mondo).

Ma il "codice legacy" implica semplicemente il vecchio, e il "flusso di lava" implica piccoli blob all'interno di un sistema, non il tutto.

Quindi ... Con la lingua ben piantata in una guancia, le checche inventano un termine: "Deposito di basalto?" Un deposito di basalto consiste in flussi di lava (spesso multipli) che si sono solidificati in corrispondenza o in prossimità della base di un vulcano attivo lungo. Come la cera solidificata che correva lungo il lato di una candela e si raccoglieva alla base. È una roccia dura, e dopo che il vulcano si è estinto e l'erosione ha fatto il suo corso, di solito è la caratteristica dominante nel paesaggio.

Uso: "Vuoi davvero scavare lì dentro? È un deposito di basalto, e tu spezzerai la tua pala."

Ovviamente, invece di un termine conciso, potresti semplicemente pubblicare segnali di avvertimento ai confini che spiegano quali sono i pericoli del codice:)

La creazione del nuovo ambiente di test rappresenterà una sfida perché esiste una quantità significativa di debito tecnico. Gli angoli sono stati tagliati e lo sviluppo è stato orientato verso limiti di tempo rispetto al controllo di qualità. Abbandonando il lavoro necessario richiesto per un progetto (documentazione, refactoring, test di regressione, revisioni del codice), rimandano l'investimento in futuro. Hanno raccolto un vantaggio al momento in cambio di un debito tecnico. Ma questo debito cresce con interesse. Col passare del tempo, lo spazio mentale degli sviluppatori è stato dedicato altrove e le ragioni di questo cambiamento qui o quell'aggiunta sono andate perse. E con quella perdita, il compito di documentare e ripulire il progetto è diventato molto più difficile. Arriva un punto in cui il debito è ingestibile e dovresti semplicemente ricominciare daccapo. Questo è compensato dal modo in cui il progetto è strettamente collegato al resto della vostra attività e quanto di questo cruft sia una conoscenza aziendale legittima. Anche per progetti estremamente crudi, la retroingegnerizzazione dei dettagli potrebbe essere una soluzione migliore rispetto a partire da zero.

Ma sarà difficile perché devi iniziare a pagare un debito enorme. La maggior parte del pagamento (vale a dire, il tempo impiegato per il reverse engineering di questa cosa) interesserà piuttosto che il principio (documenteremo e refactoring più di quanto stiamo aggiungendo nuovo codice o test). Almeno all'inizio.