Esiste un modello anti con nome per il software storicamente sviluppato? [chiuso]

Fai riferimento a debito tecnico .

Tutti noi accumuliamo debito tecnico nei prodotti che sviluppiamo nel tempo; il refactoring è uno dei metodi più comuni ed efficaci per ridurre questo debito tecnico, sebbene molte aziende non paghino mai il loro debito tecnico. Queste aziende tendono a trovare i loro software estremamente instabili per anni e il debito tecnico diventa così macabro da non poterlo ripagare in modo incrementale, perché richiederebbe troppo tempo per ripagarlo in quel modo.

Il debito tecnico ha il termine, perché segue gli stessi comportamenti del debito. Ottenete il debito, e finché continuate a spendere (creando caratteristiche) e non pagate quel debito, crescerà soltanto. Proprio come il debito, quando diventa troppo grande si arriva a punti in cui si potrebbe desiderare di eliminarlo interamente con compiti pericolosi come riscritture a tutto campo. Inoltre, come il debito reale, poiché raggiunge un certo punto, ostacola la tua capacità di spesa (creando le caratteristiche) del tutto.

Solo per aggiungere un altro termine nel mix, coesione si riferisce a quanto bene un sistema, da micro a livello di linea o macro a livello di sistema, combaci. Un sistema altamente coeso farà combaciare tutti i suoi pezzi molto bene e sembra che un ingegnere abbia scritto tutto questo. Il tuo riferimento sopra a qualcuno che sta incollando il loro 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 è di ripagarlo frequentemente. Sfortunatamente, come il debito reale, a volte è un'idea migliore acquisirne di più per un breve periodo, dove ad esempio il time to market per una funzionalità può raddoppiare o triplicare le entrate. La parte difficile è la valutazione di queste priorità in competizione e l'identificazione di quando il ROI dei debiti non vale la pena per la funzionalità specificata . quando è.

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

• refactoring
  • Questo ti permette di prendere pezzi di codice che sono stati realizzati solo per essere smarriti a metà o dopo l'implementazione è stata completata, e metterli nel loro posto corretto (o comunque più corretto).
• Rewrite
  • È come una bancarotta. Pulisce la lavagna, ma non si inizia con nulla e si ha l'opportunità di commettere gli stessi errori, o anche più grandi. Approccio high risk high reward al debito tecnico, ma a volte è l'opzione solo . Anche se è più raro che ve lo diranno molti.
• Panoramica sull'architettura
  • Questo è più di un approccio di riduzione del debito tecnico attivo. Ciò avviene facendo in modo che qualcuno abbia autorità sui dettagli tecnici per fermare un'implementazione a prescindere dei piani e dei programmi del progetto per garantire che accuvi meno debiti tecnici.
• Blocco codice
  • Il congelamento del codice delle modifiche può permetterti di respirare dove il tuo debito non sale o scende. Questo ti dà il tempo di pianificare il tuo approccio alla riduzione del debito tecnico con la speranza di avere il ROI più alto sul tuo approccio.
• La modularizzazione
  • Questo è come un approccio tier-2 disponibile solo quando si utilizza una panoramica dell'architettura per avere un sistema modulare già, o Refactoring per spostarsi verso uno. Quando si dispone di un sistema modulare, è quindi possibile pagare il debito in parti intere del sistema in modo isolato. Ciò ti consente di eseguire il refactoring parziali , parziali , oltre a ridurre al minimo il tasso di indebitamento tecnico in quanto l'isolamento mantiene il debito solo in quelle aree in cui le caratteristiche sono andate in, al contrario di diffondersi nel sistema.
• Test automatici
  • I test automatizzati possono aiutare a gestire il debito tecnico, perché possono aiutarti a identificare i punti problematici nel sistema, sperando che il debito in quelle aree sia cresciuto molto, ma anche dopo che possono ancora rendere gli ingegneri consapevoli di quelli aree pericolose che potrebbero non aver già realizzato. Inoltre, una volta che hai effettuato test automatici, puoi più facilmente refactoring delle cose senza preoccuparti di rompere troppo. Non perché gli sviluppatori non non rompono le cose, ma perché scopriranno quando si rompono le cose , fare affidamento su tester manuali in sistemi altamente indebitati tende ad avere una traccia scadente registrare per trovare problemi.

La tua descrizione si adatta a Big Ball of Mud di Foote e Yoder

Over the last several years, a number of authors... have presented patterns that characterize high-level software architectures... In an ideal world, every system would be an exemplar of one or more such high-level patterns. Yet, this is not so. The architecture that actually predominates in practice has yet to be discussed: the BIG BALL OF MUD.

A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems...

Why does a system become a BIG BALL OF MUD? Sometimes, big, ugly systems emerge from THROWAWAY CODE. THROWAWAY CODE is quick-and-dirty code that was intended to be used only once and then discarded. However, such code often takes on a life of its own, despite casual structure and poor or non-existent documentation. It works, so why fix it? When a related problem arises, the quickest way to address it might be to expediently modify this working code, rather than design a proper, general program from the ground up. Over time, a simple throwaway program begets a BIG BALL OF MUD.

Even systems with well-defined architectures are prone to structural erosion. The relentless onslaught of changing requirements that any successful system attracts can gradually undermine its structure. Systems that were once tidy become overgrown as PIECEMEAL GROWTH gradually allows elements of the system to sprawl in an uncontrolled fashion.

If such sprawl continues unabated, the structure of the system can become so badly compromised that it must be abandoned. As with a decaying neighborhood, a downward spiral ensues. Since the system becomes harder and harder to understand, maintenance becomes more expensive, and more difficult. Good programmers refuse to work there. Investors withdraw their capital. And yet, as with neighborhoods, there are ways to avoid, and even reverse, this sort of decline. As with anything else in the universe, counteracting entropic forces requires an investment of energy. Software gentrification is no exception. The way to arrest entropy in software is to refactor it. A sustained commitment to refactoring can keep a system from subsiding into a BIG BALL OF MUD...

• ...One of mud's most effective enemies is sunshine. Subjecting convoluted code to scrutiny arrow can set the stage for its refactoring, repair, and rehabilitation. Code reviews are one mechanism one can use to expose code to daylight.