Esiste un termine di programmazione comune per i problemi legati all'aggiunta di funzionalità a un programma già ricco di funzionalità?

0

Sto cercando un termine di programmazione comunemente usato per descrivere un fenomeno di ingegneria del software, che (per mancanza di un modo migliore per descriverlo) illustrerò prima con un paio di esempi, per analogia:

Scenario 1: Vogliamo costruire / estendere un sistema di metropolitana alla periferia di una piccola città nel Wyoming. Ovviamente ci sono i soliti problemi della metropolitana da risolvere (assumere la giusta compagnia di costruzione, scegliere il percorso migliore, acquistare le auto della metropolitana), ma a parte questo è abbastanza semplice implementare il sistema perché non c'è un numero enorme di vincoli da soddisfare.

Scenario 2: come sopra, tranne che ora abbiamo bisogno di costruire / estendere il sistema di metropolitana nel centro di Los Angeles. Qui affrontiamo tutti i problemi che abbiamo riscontrato nel caso (1), ma anche problemi addizionali - la maggior parte dello spazio applicabile è già in uso, e ha un collegio elettorale che protesta rumorosamente se li scomodiamo riutilizzando, ridisegnando o altrimenti modificando l'infrastruttura su cui si basano. Per questo motivo, le estensioni del sistema avvengono in modo molto lento e costoso, oppure non si verificano affatto.

A volte vedo un modello simile con lo sviluppo del software - l'aggiunta di una nuova funzionalità a un programma piccolo / semplice è semplice, ma man mano che il programma cresce, l'aggiunta di ulteriori nuove funzionalità diventa sempre più difficile, se non altro perché è difficile integrare la nuova funzionalità senza influire negativamente sul numero elevato di casi d'uso esistenti o circoscrizioni dell'utente. (anche con un design di programma robusto e adattabile, ti imbatti nel problema dell'interfaccia utente che diventa così elaborata che il programma diventa difficile da imparare o da usare)

Esiste un termine per questo fenomeno?

    
posta Jeremy Friesner 02.06.2014 - 01:01
fonte

3 risposte

3

Caratteristica creep o featurism strisciante :

  1. Describes a systematic tendency to load more chrome and features onto systems at the expense of whatever elegance they may have possessed when originally designed. See also feeping creaturism. “You know, the main problem with BSD Unix has always been creeping featurism.”

  2. More generally, the tendency for anything complicated to become even more complicated because people keep saying “Gee, it would be even better if it had this feature too”. (See feature.) The result is usually a patchwork because it grew one ad-hoc step at a time, rather than being planned. Planning is a lot of work, but it's easy to add just one extra little feature to help someone ... and then another ... and another.... When creeping featurism gets out of hand, it's like a cancer. The GNU hello program, intended to illustrate GNU command-line switch and coding conventions, is also a wonderful parody of creeping featurism; the distribution changelog is particularly funny. Usually this term is used to describe computer programs, but it could also be said of the federal government, the IRS 1040 form, and new cars. A similar phenomenon sometimes afflicts conscious redesigns; see second-system effect. See also creeping elegance.

- Dal file Jargon , un compendio della sottocultura degli hacker (originariamente) degli anni '70 del MIT e di Stanford. Quindi sì, si potrebbe dire che è un termine stabilito ...

    
risposta data 02.06.2014 - 01:03
fonte
0

Placcatura dell'oro: da wikipedia continuando a lavorare su un progetto o compito ben oltre il punto in cui lo sforzo extra vale il valore aggiunto (se esiste).

link

La maggior parte della placcatura in oro che ho visto / ascoltato non è esattamente adatta allo scenario che offri (estendendo una semplice metropolitana a LA), ma è una buona definizione.

    
risposta data 02.06.2014 - 02:24
fonte
0

Basandoti sui tuoi due esempi - questa è semplice estensione del programma - ed è tutto qui - non importa se il tuo programma è semplice (Wyoming) o complesso (LA), in entrambi i casi hai identificato un bisogno aziendale per le nuove funzionalità e le progetteremo in. La funzionalità di scorrimento implicherebbe funzionalità di valore discutibile - o forse coinvolgerà funzionalità meglio implementate da un software separato.

Non so se c'è un fraseggio specifico per descrivere l'estensione di un software già complesso - ma questo sarebbe dove la documentazione (blueprints) e la gestione del codice / progetto cominceranno ad essere davvero utili. Anche i test di regressione (nessun reale analogo alla costruzione della metropolitana) sarebbe estremamente utile qui.

    
risposta data 02.06.2014 - 04:04
fonte

Leggi altre domande sui tag