Mi chiedo quale sarebbe una buona definizione di termine "over-engineering" applicata allo sviluppo del software. L'espressione sembra essere utilizzata molto durante le discussioni sulla progettazione del software, spesso in concomitanza con "un'eccessiva impermeabilità futura" e sarebbe bello definire una definizione più precisa.Cosa si intende per "over-engineering" applicato al software?
penso che le migliori risposte alla tua domanda può essere trovato in this other qestion
C'è questa discussione in Joel on Software che inizia con,
creando ampie gerarchie di classi per un problema futuro immaginato che ancora non esiste, è una sorta di over-engineering, ed è quindi, male.
E, si entra in una discussione con esempi.
Ecco un altro su over engineering of framework: http : //discuss.joelonsoftware.com/default.asp? joel.3.219431.12 –
La mia definizione di massima sarebbe 'fornendo funzionalità che isnt necessaria per soddisfare le esigenze specifiche'
Che cosa si tratta dei requisiti non detti? Spesso non sono nelle specifiche, ma devono essere soddisfatti per fornire una soluzione solida. –
Se non sono chiari come fai a sapere quando li hai soddisfatti? – PaulJWilliams
sovrascrive l'ingegneria spesso nella fase dei requisiti. Ricordo un progetto SSADM che generò circa 5000 pagine di documenti richiesti prima ancora di scrivere una singola riga di codice. –
penso che siano gli stessi Gold plating e di essere colpiti dal Golden hammer :)
In sostanza, ci si può sedere giù e ha passato troppo tempo a cercare di creare un design perfetto, senza mai scrivere un codice per verificare come funziona. Qualunque metodo agile ti dirà di non creare tutto il tuo design in anticipo e di creare pezzi di design, implementarlo, reiterarlo, riprogettare, andare di nuovo, ecc ...
Nei casi in cui abbiamo considerato le cose sopra ingegnerizzate, è sempre stato descrivere un software che è stato progettato per essere così generico da perdere di vista il compito principale che era stato inizialmente progettato per funzionare, ed è quindi diventato non solo difficile da usare, ma fondamentalmente non intelligente .
Quoting from here: "... Implementare cose quando si realtà bisogno di loro, mai quando hai appena prevedi che ne avete bisogno."
Solo per favore non sviluppare software per reattori nucleari con questa filosofia in mente;) – 0scar
Punto preso, ma vorrei discutere la semantica qui e dire che * in realtà * serve praticamente ogni possibile salvaguardia quando si tratta di software che potrebbe influire sulla sicurezza o salute. – JosephStyons
La risposta agile a questa domanda è: ogni pezzo di codice che non contribuisce alla funzionalità richiesta.
Per me, l'over-engineering include tutto ciò che non ti serve e che non lo sei conoscere che ti servirà. Se ti rendi conto che una funzionalità potrebbe essere utile se i requisiti cambiano in un certo modo, potresti essere troppo ingegnoso. Fondamentalmente, l'over-engineering sta violando YAGNI.
La bellezza della programmazione Agile è che è difficile sovrastidire se si fa bene.
Ma si può finire con una suite di test massicciamente sovradimensionata :) (anatre per copertina) –
Se scrivi un manifesto che definisce cosa è "giusto" e cosa è "sbagliato" e poi seguilo, allora sì, probabilmente è piuttosto difficile farlo Qualcosa non va". – 0scar
@ 0scar: questo è il punto con Agile: tu definisci ciò che è giusto. :) –
Over-engeneering significa progettare e progettare l'applicazione con più componenti di quelle che dovrebbero realmente avere secondo la lista dei requisiti.
C'è una grande differenza tra il sovraingegnerizzazione e la creazione di un applcaiton estensibile, che può essere aggiornato al variare dei requisiti. Se riesco a pensare ad un esempio, modificherò il post.
Se si spende così tanto tempo a pensare alle possibili ramificazioni di un problema che si finisce per interferire con la risoluzione del problema stesso, si può essere troppo ingegneristici.
C'è un sottile equilibrio tra "migliori pratiche di ingegneria" e "applicabilità del mondo reale". Ad un certo punto devi decidere che anche se una particolare soluzione potrebbe non essere "pura" dal punto di vista ingegneristico come potrebbe essere, farà il lavoro.
Ad esempio:
Se si progetta un sistema di gestione degli utenti per l'uso di una volta in una riunione di scuola superiore, probabilmente non c'è bisogno di aggiungere il supporto per i nomi incredibilmente lungo, o set di caratteri funky. Impostare una lunghezza massima ragionevole e fare un po 'di sanificazione di base dovrebbe essere sufficiente. D'altra parte, se stai creando un sistema che verrà distribuito per centinaia di eventi simili, potresti voler dedicare più tempo al problema.
Si tratta di un livello di sforzo appropriato per l'attività in corso.
Ho paura che una definizione precisa non sia probabilmente possibile in quanto dipende fortemente dal contesto. Ad esempio, è molto più facile sovra-ingegnerizzare un sito web che mostra pony scintillanti di quanto non sia un sistema di controllo di una centrale nucleare. Le ridondanze, il controllo eccessivo degli errori, le strutture di registrazione altamente strumentate sono tutte over-engineering per un'app di pony luccicanti, ma non per un sistema di controllo di centrali nucleari. Penso che il meglio che puoi fare sia avere una sensazione quando stai applicando troppo overhead alle tue funzionalità per lo scopo dell'applicazione.
Nota che vorrei distinguere tra doratura e sovrastruttura. Nella mia mente, la doratura sta creando caratteristiche che non sono state richieste e non saranno mai utilizzate. L'over-engineering riguarda più la "sicurezza" che si crea nell'applicazione, codificando i controlli attorno al codice o utilizzando una progettazione eccessiva per un'attività semplice.
Per me è tutto ciò che aggiungerebbe più grasso al codice. La carne sarebbe un codice che farà il lavoro secondo le specifiche e il grasso sarebbe un codice che gonfierà il codice in un modo che aggiunge semplicemente più complessità. Il programmatore avrebbe potuto aspettarsi una futura espansione della funzionalità; ma comunque è grasso!
Contrariamente alla maggior parte delle risposte, non credo che la "funzionalità attualmente non necessaria" sia eccessiva; o è la forma meno problematica.
Come hai detto tu, il peggior tipo di over-engineering è generalmente impegnata in nome del futuro-proofing e l'estensibilità - e raggiunge l'esatto contrario:
La verità è che il design più facilmente adattato alle nuove e mutevoli esigenze (ed è quindi il più a prova di futuro ed estensibile) è il progetto che è il più semplice possibile.
Interessante pensiero che l'over-engineering può accadere quando si cerca di trovare un problema tecnicamente interessante invece di implementare qualcosa di noioso. Qualcosa di cui essere cauto credo. –
Mi piace l'ultimo paragrafo! –
Over-engineering sta semplicemente creando un prodotto con maggiore funzionalità, qualità, generalità, estensibilità, documentazione o qualsiasi altro aspetto di quanto richiesto.
Ovviamente, potresti avere requisiti al di fuori di un progetto specifico - ad esempio, se prevedi di fare future applicazioni simili, potresti avere requisiti aggiuntivi per l'estendibilità, dipendenti dai costi, che aggiungi ai requisiti specifici del progetto .
Contrariamente alla credenza popolare, l'over-engineering è davvero un fenomeno che appare quando gli ingegneri ottengono "hubris" e pensano di capire l'utente.
Ho fatto un semplice diagramma per illustrare questo:
Sembra un cancro. – Calmarius
Bella illustrazione. Che cosa hai usato per metterlo insieme se posso chiedere? – TheLegendaryCopyCoder
Ciò si riferisce alla mia discutibile parere programmazione di "The simplest approach is always the best approach".
Quando il tuo design rende le cose più complesse invece di semplificare le cose, sei un ingombro.
Maggiori info su questo a:
Diniego # 1: Sono un BA big-picture. Non conosco alcun codice. Ho letto questo sito tutto il tempo. Questo è il mio primo post.
Divertente Mi è stato appena detto dal mio capo che ho sovra-ingegnerizzato un nuovo software che stiamo progettando per il mentoring (target HR persone del mercato). Quindi sono venuto qui per cercare il termine.
Vogliono ottenere qualcosa sul posto per vendere ora, ri-mirando gli strumenti esistenti. Non posso fare a meno di sedermi e pensare, meno iscrizioni, ritenzione inferiore, se non consente una certa flessibilità di cui abbiamo parlato. E soprattutto, avere un'interfaccia utente altamente visiva che una scimmia potrebbe usare.
Ha detto che potremmo pianificare le fasi future per migliorare il prodotto, in particolare l'interfaccia utente. Abbiamo clienti attuali che aspettano "miglioramenti futuri" che ancora non stiamo facendo. Ne hanno bisogno, ne hanno davvero bisogno.
Sono in procinto di dimettermi, quindi non ho respinto.
Ma la mia definizione sarebbe ............. facendo in modo che faccia solo il meno possibile, per il più economico possibile, e sia ancora passabile per la cosa che dici che è. Oltre a ciò c'è l'ingegneria.
Disclaimer n. 2: questo sito mi ha aiutato a trovare il mio prossimo lavoro implementando un software più configurabile.
Probabilmente dovresti applicare il tag "soggettivo" a questo. –
non correlato alla programmazione – abmv
@abmv Non sono affatto d'accordo. Le domande sul processo di sviluppo del software sono completamente legittime. – Pwninstein