Quando violare YAGNI?

Question

Il YAGNI "principio" afferma che non è necessario concentrarsi sulla funzionalità prima di averne bisogno, poiché "non ne avrete bisogno" comunque.

Di solito tendo ad usare il buon senso sopra qualsiasi regola, non importa cosa, ma ci sono alcune volte in cui ritengo che sia utile sovradimensionare il design o la prova futura se hai delle buone ragioni, anche se è possibile che non lo farai mai usalo

Il caso reale che ho tra le mani in questo momento è più o meno così:

Ho un'applicazione che deve correre più di un semplice proprietaria protocollo di comunicazione (livello OSI 4). Questo protocollo ha un insieme desiderabile di caratteristiche (come la seguente specifica NORM) che forniscono robustezza all'applicazione ma che non sono strettamente richieste (il multicast UDP potrebbe essere accettabile).

C'è anche il fatto che l'applicazione è probabilmente (ma non sicuramente) utilizzata da altri client in futuro che non avranno accesso alla soluzione proprietaria e, quindi, avrà bisogno di un'altra soluzione. So per certo che la probabilità di un altro client per l'applicazione è alta.

Allora, che ne pensi? Dovrei semplicemente progettare per il protocollo proprietario e lasciare il refactoring, l'estrazione dell'interfaccia e così via a quando ne ho davvero bisogno o dovrei fare il design ora pensando al futuro (non così lontano)?

Nota: Giusto per essere chiari, io sono interessato a sentire tutti i tipi di opinioni per la questione generale (quando a violare YAGNI), ma mi piacerebbe molto qualche consiglio o pensieri sul mio attuale dilemma :)

Answer 1

IMHO

• direi andare YAGNI prima. Funziona senza le specifiche NORM usando 'la cosa più semplice che potrebbe funzionare'.
• Avanti confrontare se il costo di rendere il 'design cambia' in futuro è significativamente maggiore rispetto a fare la modifica ora. La tua soluzione attuale è reversibile? Se puoi facilmente apportare il cambiamento domani o dopo un paio di mesi, non farlo ora. Se non hai bisogno di prendere una decisione di progettazione irreversibile ora ..ritardo fino all'ultimo momento responsabile (in modo da avere maggiori informazioni per prendere una decisione migliore)

Per chiudere se conosce con un notevole grado di Certezza che qualcosa è all'orizzonte e l'aggiunta in un secondo momento sta andando essere un dolore, non essere uno struzzo ... design per esso.
ad es. So che i log diagnostici sarebbero necessari prima della spedizione del prodotto. Aggiungere un codice di registrazione dopo un mese sarebbe molto più difficile che aggiungerlo oggi mentre scrivo ogni funzione ... quindi questo sarebbe un caso in cui ignorerei YAGNI anche se al momento non ho bisogno dei log.

Vedere anche: T. & M. I libri Lean di Poppendieck sono più adatti a spiegare il dilemma del punto 2 qui sopra.

Answer 2

Penso che YAGNI potrebbe essere inappropriato quando vuoi imparare qualcosa :) YAGNI è buono per i professionisti, ma non per gli studenti. Quando vuoi imparare, ne avrai sempre bisogno.

Answer 3

Non mi preoccuperei. Il fatto che tu sia a conoscenza di "YAGNI" significa che stai già pensando pragmaticamente.

Direi che, indipendentemente da qualsiasi post pubblicato qui, è statisticamente più probabile che venga fornito un codice migliore rispetto a qualcuno che non analizza le proprie pratiche allo stesso modo.

Answer 4

Strutturare bene il programma (astrazione, ecc.) Non è qualcosa a cui si applica YAGNI. Vuoi sempre strutturare bene il tuo codice.

Giusto per chiarire, penso che la tua attuale situazione sia dovuta all'eccessiva applicazione di YAGNI. Strutturare il codice in modo tale da disporre di una libreria riutilizzabile per l'utilizzo di questo protocollo è solo una buona pratica di programmazione. YAGNI non si applica.

Answer 5

Penso che sia piuttosto semplice e ovvia:

Violare YAGNI quando si sa che, in piena certezza, che si sta per bisogno

Answer 6

Il motivo YAGNI vale per il codice è che la il costo del cambiamento è basso Con un codice buono e ben refactato l'aggiunta di una funzionalità in seguito è normalmente economica. Questo è diverso da dire costruzione.

Nel caso di protocolli, l'aggiunta di modifiche in seguito non è generalmente economica. Le vecchie versioni si interrompono, possono portare a problemi di comunicazione e una matrice di test N^2, come si deve testare ogni versione contro ogni altra versione. Confrontalo con le singole codebase in cui le nuove versioni devono funzionare solo con se stesse.

Quindi nel tuo caso, per la progettazione del protocollo, non consiglierei YAGNI.

Answer 7

Sono d'accordo con Gishu e Nick.

Progettare parte di un protocollo di porta in seguito spesso a pensieri come "accidenti, ho dovuto fare questo in quel modo, ora devo usare questa brutta soluzione alternativa"

ma dipende anche da chi si interfaccerà con questo protocollo .
Se entrambi i controlli terminano e cambiano versione allo stesso tempo, è possibile rifattorizzare il protocollo in un secondo momento, come si farebbe con una normale interfaccia di codice.

Informazioni sull'esecuzione delle funzionalità aggiuntive del protocollo in seguito, ho scoperto che l'implementazione del protocollo aiuta molto a convalidare il suo design, quindi potresti almeno voler fare un semplice esempio di codice fuori produzione per testarlo, se bisogno che il design sia ufficiale

Answer 8

Ci sono alcuni casi in cui ha senso andare contro l'intuizione YAGNI.

Eccone alcuni:

seguendo le convenzioni di programmazione. Contratti di base e di interfaccia in particolare. Ad esempio, se una classe base ereditata fornisce un GetHashCode e un metodo Equals, l'override di Equals ma non GetHashCode interrompe le regole documentate dalla piattaforma che gli sviluppatori devono seguire quando eseguono l'override di Equals. Questa convenzione dovrebbe essere seguita anche se si scopre che GetHashCode non verrebbe effettivamente chiamato. GetHashCode non è un errore, anche se non esiste un modo attuale per provocarlo (a parte un test forzato). Una versione futura della piattaforma potrebbe introdurre chiamate a GetHashCode.Oppure, un altro programmatore che ha esaminato la documentazione (in questo esempio, la documentazione della piattaforma per la classe base che si sta ereditando) potrebbe legittimamente aspettarsi che il codice aderisca senza esaminare il codice. Un altro modo di pensare a questo è che tutto il codice e la documentazione applicabile devono essere coerenti, anche con la documentazione scritta da altri come quella fornita dal fornitore della piattaforma.

Personalizzazione supportata. In particolare, da sviluppatori esterni che non modificheranno il codice sorgente. Devi capire e implementare punti di estensione adatti nel tuo codice in modo che questi sviluppatori possano implementare tutti i tipi di funzionalità di aggiunta che non ti sono mai passate per la testa. Sfortunatamente, è ovvio che aggiungerai alcune funzionalità di estensibilità che pochi, se non addirittura nessuno sviluppatore esterno, utilizzerà. (Se è possibile discutere i requisiti di estensibilità con tutti gli sviluppatori esterni in anticipo o utilizzare cicli frequenti di sviluppo/rilascio, ottimo, ma questo non è fattibile per tutti i progetti.)

Asserzioni, verifiche debug, fail-safe , ecc. Tale codice non è effettivamente necessario per il corretto funzionamento della tua applicazione, ma ti aiuterà a fare in modo che il tuo codice funzioni correttamente ora e in futuro quando vengono apportate le revisioni.