Esiste un modello anti nome per software cresciuto storicamente? [chiuso]

Esiste un modello anti che descrive un sistema software storicamente sviluppato in cui più sviluppatori hanno appena aggiunto nuove funzionalità al sistema ma nessuno ha davvero tenuto d'occhio l'architettura generale e non sono mai stati fatti refactoring?

Penso che ciò accada quando il management / cliente richiede costantemente nuove funzionalità e nessuno rifatta mai nulla, ma aggiunge semplicemente ciò che altri sviluppatori non hanno mai fatto prima.

Un motivo potrebbe anche essere che lo sviluppatore è semplicemente sopraffatto dal sistema software e non capisce davvero come funziona attualmente e quindi aggiunge / incolla il suo codice alla fine (invece di refactoring il codice e cambiarlo.)

Quindi con il passare del tempo diventa sempre più difficile mantenere il sistema.

(Mi chiedo se ci sono immagini per questo tipo di anti-pattern per renderlo più chiaro a nessuno programmatori - come un'auto che è stata costruita semplicemente aggiungendo sempre più funzionalità senza pensare al design generale. Come se qualcuno avesse la necessità di rimorchiare rimorchi mentre cavalcava all'indietro e poi un ingegnere salda semplicemente un gancio di traino nella parte anteriore della macchina. Lavoro fatto. Ma ora la calandra non si apre più.)

Ti riferisci al debito tecnico .

Tutti accumuliamo debito tecnico nei prodotti che sviluppiamo nel tempo; il refactoring è uno dei modi più comuni ed efficaci per ridurre questo debito tecnico, sebbene molte aziende non paghino mai il proprio debito tecnico. Queste aziende tendono a trovare il loro software anni estremamente instabili lungo la strada e il debito tecnico diventa così raccapricciante che non è possibile pagarlo in modo incrementale, perché ci vorrebbe troppo tempo per ripagarlo in quel modo.

Il debito tecnico ha il termine, perché segue gli stessi comportamenti del debito. Ottieni il debito, e finché continui a spendere (creando funzionalità) e non pagando quel debito, crescerà solo. Proprio come il debito, quando diventa troppo grande si arriva a punti in cui si potrebbe desiderare di versarlo interamente con compiti pericolosi come riscritture complete. Inoltre, come il debito reale, poiché si accumula fino a un certo punto, ostacola la tua capacità di spendere (creando funzionalità) del tutto.

Solo per aggiungere un altro termine al mix, coesione si riferisce a come un sistema, un micro a livello di linea o una macro a livello di sistema, si uniscono. Un sistema altamente coeso avrà tutti i suoi pezzi perfettamente combinati e sembrerà che un ingegnere abbia scritto tutto. Il tuo riferimento sopra a qualcuno che ha appena incollato il proprio codice alla fine violerebbe la coesione di quel sistema.

Gestione del debito tecnico

Ci sono molti modi per gestire il debito tecnico, anche se come il debito reale l'approccio migliore è quello di ripagarlo frequentemente. Sfortunatamente come il debito reale, a volte è meglio accumulare di più per un breve periodo, dove ad esempio il time to market per una funzione può raddoppiare o triplicare le entrate. La parte difficile è soppesare queste priorità concorrenti e identificare quando il ROI dei debiti non vale la pena per la caratteristica data rispetto a quando lo è.

Quindi a volte vale la pena accumulare il debito per un breve periodo, ma raramente è così, e come per tutti i debiti, più breve è il periodo, meglio è. Quindi alla fine (preferibilmente rapidamente ) dopo aver accumulato debito tecnico, devi pagarlo, questi sono approcci comuni:

• refactoring
  • Ciò consente di prendere frammenti di codice che sono stati realizzati solo per essere collocati in modo errato a metà o dopo il completamento dell'implementazione e di metterli nel loro posto corretto (o comunque uno più corretto).
• Riscrivere
  • Questo è come un fallimento. Pulisce l'ardesia, ma inizi con niente e hai tutte le possibilità di fare gli stessi errori, o anche quelli più grandi. Approccio ad alto rischio e alto rendimento al debito tecnico, ma a volte è la tua unica opzione. Anche se questo è più raramente il caso di quello che molti ti diranno.
• Panoramica sull'architettura
  • Questo è più di un approccio attivo di pagamento del debito tecnico. Questo viene fatto avendo qualcuno con autorità sui dettagli tecnici per fermare un'implementazione indipendentemente dai piani di progetto e dai programmi per garantire che accumuli meno debito tecnico.
• Blocco del codice
  • Il congelamento del codice delle modifiche può consentire di respirare dove il debito non aumenta o diminuisce. Ciò ti dà il tempo di pianificare il tuo approccio alla riduzione del debito tecnico nella speranza di avere il ROI più elevato sul tuo approccio.
• La modularizzazione
  • Questo è come un approccio di livello 2 disponibile solo quando si utilizza Panoramica dell'architettura per avere già un sistema modulare o Refactoring per spostarsi verso uno. Quando si dispone di un sistema modulare, è quindi possibile ripagare il debito in parti intere del sistema in modo isolato. Ciò consente di effettuare riscritture parziali , refactoring parziale , nonché di ridurre al minimo il tasso di indebitamento tecnico dovuto al fatto che l'isolamento mantiene il debito solo nelle aree in cui sono state introdotte le funzionalità, anziché diffondersi nel sistema.
• Test automatizzati
  • I test automatizzati possono aiutarti a gestire il tuo debito tecnico, perché possono aiutarti a identificare i punti problematici nel sistema, si spera prima che il debito in quelle aree sia cresciuto molto, ma anche dopo il fatto possono ancora rendere gli ingegneri consapevoli di quelle aree pericolose che potrebbe non essersi già reso conto. Inoltre, una volta che hai i test automatizzati, puoi più liberamente riformattare le cose senza preoccuparti di rompere troppo. Non perché gli sviluppatori non rompano le cose, ma perché lo scopriranno quando si rompono le cose , fare affidamento su tester manuali in sistemi altamente indebitati tende ad avere scarsi risultati per trovare problemi.

La tua descrizione è adatta per Foote e Yoder's Big Ball of Mud :

Nel corso degli ultimi anni, un certo numero di autori ... hanno presentato schemi che caratterizzano architetture software di alto livello ... In un mondo ideale, ogni sistema sarebbe un esempio di uno o più di tali schemi di alto livello. Tuttavia, non è così. L'architettura che in realtà predomina nella pratica deve ancora essere discussa: la GRANDE SFERA DEL FANGO .

A BIG BALL OF MUD è strutturato a casaccio, tentacolare, sciatto, nastro isolante e filo da cauzione, la giungla degli spaghetti code. Li abbiamo visti tutti. Questi sistemi mostrano segni inconfondibili di crescita non regolamentata e riparazione ripetuta e opportuna. Le informazioni sono condivise in modo promiscuo tra elementi distanti del sistema, spesso al punto in cui quasi tutte le informazioni importanti diventano globali o duplicate. La struttura complessiva del sistema potrebbe non essere mai stata ben definita. Se lo fosse, potrebbe essersi eroso oltre il riconoscimento. I programmatori con un pizzico di sensibilità architettonica evitano questi pantani. Solo coloro che non si preoccupano dell'architettura e, forse, si sentono a proprio agio con l'inerzia del lavoro quotidiano di rattoppare i buchi in queste dighe carenti, sono contenti di lavorare su tali sistemi ...

Perché un sistema diventa una GRANDE SFERA DI FANGO? A volte, i sistemi grandi e brutti emergono dal codice THROWAWAY . THROWAWAY CODE è un codice rapido che doveva essere usato una sola volta e poi scartato. Tuttavia, tale codice assume spesso una vita propria, nonostante la struttura casuale e la documentazione scadente o inesistente. Funziona, quindi perché ripararlo? Quando si presenta un problema correlato, il modo più rapido per risolverlo potrebbe essere quello di modificare opportunamente questo codice di lavoro, piuttosto che progettare un programma generale adeguato da zero. Nel tempo, un semplice programma usa e getta genera una GRANDE SFERA DI FANGO.

Anche i sistemi con architetture ben definite sono inclini all'erosione strutturale. L'assalto implacabile del mutare dei requisiti che attira qualsiasi sistema di successo può minare gradualmente la sua struttura. I sistemi che una volta erano ordinati diventano troppo cresciuti man mano che CRESCITA PIECEMEALE consente gradualmente agli elementi del sistema di espandersi in modo incontrollato.

Se tale espansione continua senza sosta, la struttura del sistema può essere così gravemente compromessa che deve essere abbandonata. Come in un quartiere in declino, ne consegue una spirale discendente. Poiché il sistema diventa sempre più difficile da comprendere, la manutenzione diventa più costosa e più difficile. I bravi programmatori si rifiutano di lavorare lì. Gli investitori ritirano il loro capitale. Eppure, come con i quartieri, ci sono modi per evitare e persino invertire questo tipo di declino. Come per qualsiasi altra cosa nell'universo, contrastare le forze entropiche richiede un investimento di energia. La gentrificazione del software non fa eccezione. Il modo per arrestare l'entropia nel software è di riformattarlo. Un impegno prolungato nel refactoring può impedire a un sistema di placarsi in una GRANDE SFERA DI FANGO ...

• ... Uno dei nemici più efficaci del fango è il sole. Sottoporre il codice contorto alla freccia di controllo può preparare il terreno per il suo refactoring, riparazione e riabilitazione. Le revisioni del codice sono un meccanismo che è possibile utilizzare per esporre il codice alla luce del giorno.