Fino a che punto si va con YAGNI? [chiuso]

https://stackoverflow.com/questions/2023638

19-09-2019
|

Domanda

Sto sviluppando una nuova applicazione web rivoluzionaria per il mercato enterprise. Certo, molti prima di me hanno pensato che la loro web app sarebbe rivoluzionaria solo per scoprire che non è. (O lo è, ma il business non è buona in ogni caso).

Quindi mi sto pensando, al fine di scoprire se la mia idea ha qualche trazione con il più basso costo, di seguire un YAGNI estrema:

Non ci sono caratteristiche di sicurezza (vale a dire, nessun utente, ecc). Per ogni nuovo cliente installa una nuova istanza di database e una nuova istanza webapp. Ogni istanza webapp è protetto da una password del server http (digerire o autorizzazione di base, forse su HTTPS).
No internazionalizzazione. Basta stringa inglese incorporato nel codice sorgente.
No disaccoppiamento. Basta pagine web che parlano al database.
Non ci sono trucchi prestazioni. No code, cache, temporizzatori, processi in background, le chiamate asincrone, ecc.
No scalabilità. No partizionamento del database, senza schegge, senza il clustering o la replica.
Inoltre, utilizzare YAGNI a livello micro ogniqualvolta adatto.

Voglio solo ad avviare il progetto e raggiungere il più velocemente possibile un punto in cui posso vendere (o cercare di vendere) le mie caratteristiche innovative con un semplice e coinvolgente interfaccia utente.

Se il piano fallisce, lo saprò presto. Se ci riesce, vedrò cosa vogliono i clienti, allora. Vogliono una versione francese? O vogliono gli utenti e ruoli all'interno dell'organizzazione?

E 'questo ciò che la gente intende per YAGNI, o si tratta di un esempio di patologico e esagerata di YAGNI?

Soluzione

Sono pienamente d'accordo con il principio YAGNI, ma ancora voglia di pianificare per il successo. Se un'applicazione ha bisogno di una riscrittura completa quando ha improvvisamente più di dieci utenti, allora è YAGNI preso troppo.

Alcune cose si sono gonna bisogno. Dal mio punto di vista, i due punti più importanti:

Non spararsi in un piede, non preparare la vostra applicazione per l'internazionalizzazione. Se l'applicazione è un bene, l'internazionalizzazione sta per essere sul tavolo un giorno. Inoltre, la capacità di gestire caratteri stranieri utilizzando UTF-8 è un requisito assoluto per la costruzione di un'applicazione da zero nel 2010. Internazionalizzazione può sembrare non così importante a un madrelingua inglese, ma credetemi, è essenziale e il dolore di internazionalizzazione un'applicazione tardi è orribile.
Pensateci due volte circa la cosa non funzioni di sicurezza. Che dire di un'organizzazione o di un gruppo che vuole lavorare con la tua applicazione con gli utenti su diversi livelli di sicurezza. E ' potrebbe essere che questa è una caratteristica che si può davvero fare a meno - Ho un sistema di sicurezza a grana fine integrato in molti dei miei prodotti che non è mai stato utilizzato al massimo delle sue potenzialità ancora. Ma pensa bene di se l'applicazione specifica può fare a meno, anche se è successo.

Altri suggerimenti

Questo è quello che chiamano "prototipi". Andare per esso.

C'è una sottigliezza tra YAGNI e prototipazione.

Quando è featuritis user-richiesto, e voi dite di no, che è YAGNI.
Quando si tratta di implementazione (I18N, "disaccoppiamento" (?), Code, cache, timer, etc.) e tu dici di no a te stesso. Che non è proprio YAGNI. Ecco la prototipazione.

La maggior parte di quello che avete qui non sembra essere doratura user-oriented. Non direi questo - appunto -. YAGNI

YAGNI sta ricordando di vedere la differenza tra ciò che si possono fare e che cosa dovete fare per soddisfare le vostre esigenze.

Per esempio, se il vostro requisito dice "lasciare che le persone creano account e log-in", basta usare i metodi di default auth del quadro e passare al requisito successivo.

Il tuo web app possono il supporto OpenID, Active Directory, database locale, file flat, e un triliardo di altri tipi di metodi di autenticazione, ma è possibile soddisfare il requisito implementando la più semplice. (Per me, YAGNI implica DTSTTCPW ).

"Posso fare qualsiasi cosa, dato abbastanza tempo"

- ogni programmatore che abbia mai incontrato

Non è un fan del principio YAGNI me stesso; Lo vedo usato troppo spesso nella giustificazione di software mal progettato. Over-progettato il software è un problema troppo, naturalmente, ma "YAGNI" in realtà non lascia molto spazio per l'analisi di impatto effettivo.

Si scopre che nel mondo del software, molte delle cose che si pensa che non si sta per necessità, in realtà si sta per necessità. E poi qualche. Who'dathunkit.

ho scritto una o due applicazioni che avrebbero dovuto essere le applicazioni usa e getta o tenere fuori campo che sono ancora in produzione dopo due anni. Essi sono un dolore per mantenere.

Soprattutto quando si tratta di qualcosa come la sicurezza - probabilmente sono avrà bisogno

YAGNI è un buon principio, ma non è l'unico principio di progettazione. Molti di quanto sopra ha senso per ottenere un prodotto di fronte a utenti in fretta. Ma se, per esempio, le pagine web che parlano direttamente al database iniziano a ogni codice aver duplicato che si sta per scoprire che la dipendenza servile su un principio (YAGNI) per l'esclusione di altri (in questo caso DRY) limiterà la vostra capacità per rispondere alla vostra spera crescente numero di richieste di funzionalità degli utenti.

Se avete intenzione di sviluppare un vero e applicazione web rivoluzionaria per il mercato enterprise non sono davvero sicuro che di quelle cose Y ou A int G onna N eed.

Anche i tuoi esempi sono abbastanza specifici. Per esempio quando si dice: "nessuna funzionalità di sicurezza" ... direi che gli utenti è una cosa che forse può fare a meno, ma sanificazione ingressi è uno che non si può. Anche "scalabilità" non è una questione di sharding database o la replica, queste sono decisioni che si prendono dopo ti rendi conto la vostra applicazione non scala bene.

io preferirei essere attenti quando si usano YAGNI come linee guida di progettazione di alto livello, si adatta di più quando si parla di caratteristiche del prodotto dispari o forse componenti software estrema flessibilità.

Solo il mio 0.2

Se si prende "YAGNI" a quella estrema (e io eludere discussioni sulla necessità o meno che sia una buona idea, così come le discussioni sulla necessità o meno che sia realmente "YAGNI"), si dovrebbe essere pronti per il refactoring senza pietà il vostro codebase di aggiungere in seguito quello che si lascia fuori ora senza creare una palla di fango.

Nella mia mente YAGNI è più comunemente usato nel contesto con uno sviluppatore pensando "Oh sarebbe intelligente se abbiamo aggiunto anche funzione di X. Ci potrebbe aver bisogno in futuro." Mai mai aggiungere funzionalità che non è un requisito.

Detto questo il codice deve essere sempre aperto per le modifiche se il cliente pensa caratteristica Y è assolutamente necessario. Una buona architettura è un must!

Per quanto riguarda per la scalabilità, le code, il caching: dipende. Quali sono i requisiti per l'applicazione? E 'un sito Intranet utilizzato da 10 utenti simultanei o è un popolare sito web con milioni di utenti. Dipende. Trova le esigenze e farlo - niente di più. YAGNI. Se il requisito cambiamento; cambiare la vostra applicazione -. dovrebbe essere aperta per le modifiche

YAGNI è buono se c'è una possibilità decente si non bisogno. Se non ne hai bisogno ora, ma sei quasi sicuro che avrai bisogno nel prossimo futuro, quindi è quasi sempre più facile per adattarsi in in anticipo che poi. Quando non giustificano implementare le cose che non ti servono questa seconda , ma sarà quasi certamente bisogno nel prossimo futuro da YAGNI, è lì che iniziano i problemi.

Il punto che YAGNI è solo una grande principale tra i tanti è una buona da ricordare; a volte YAGNI suggerisce una decisione, ma ci sono altrettanto buoni (o migliori) motivi per preferire un altro.

Ecco un settore in cui mi sento alcuni sostenitori YAGNI possono andare lontano: se sei a tuo agio con OOD / polimorfismo, di solito ti costa molto poco per "cuocere in" alcuni punti di estensione grandi per un uso futuro, anche in un prototipo .

Ecco un esempio ...

Si sta creando una webapp prototipo che include la possibilità di visualizzare una versione stampabile di una relazione. Hai bisogno di lavorare in modo rapido, ma avere una buona sensazione le steakholders chiederanno la possibilità di inviare il rapporto così lungo la linea.

Nel codice Java lato server, nascondere la conoscenza del fatto che il rapporto si sta preparando per la stampante dietro un'interfaccia. Creare una classe concreta che estende l'interfaccia a ritenere che la responsabilità. Non effettivamente andare fuori e Scrivi di una versione e-mail dell'interfaccia, perché YAGNI. Ma se mai fare, sei pronto per aggiungerlo senza carneficina alle funzioni esistenti.

Direi che se si è agli inizi buttando via ogni buon senso e di fare tutto il progetto nel modo più expediant possibile, allora quello che finirà con un grande mucchio di fallire ... Il che non è per niente mezzi rivoluzionari (tm).

Se veramente si vuole sapere se sta per essere utile, fare un po 'di schermo mock up. Forse anche solo normale html vecchio hard coded. Prendere coloro ai potenziali clienti e vedere se è possibile ottenere il vostro piede nella porta. Se alcuni di loro cominciano a mordere, poi busto il culo e costruirlo.

E 'intenzione di prendere tempo per ottenere un contratto in essere, ottenere il pagamento, e avere qualcuno sul vostro personale ai clienti di iniziare effettivamente usarlo. Mentre quello che sta succedendo, costruirlo.

Molto probabilmente ciò che sta per accadere è che i potenziali clienti vedranno la tua app e, si spera, dirvi perché non funziona per loro. Modificare i mock up e tornare indietro. Iterate, se necessario, fino ad avere un design front-end per il prodotto che qualcuno è disposto a pagare.

Quello che vorrei fare è:

1) progettare tenendo in considerazione le scelte architettoniche giuste. Internazionalizzazione e la sicurezza sono probabilmente must have in questo caso.

2) Durante lo sviluppo, creare i ganci per quei principi da attuare in seguito. Così, quando avete tempo e budget, è possibile implemente senza fare ristrutturazione importante.

3) Quindi è possibile concentrarsi sulle caratteristiche che rendono il vostro volo di applicazione e sono più importanti per i suoi potenziali clienti.

Quindi penso che in questo caso sarei usando più di un approccio di BACIO "estremo YAGNI" come lei ha suggerito.

A mio parere, YAGNI dovrebbe essere seguita per difetto in quanto consente di notevolmente aumentare la produttività .

Ci sono alcune eccezioni, pensiero. Ad esempio, se si sviluppa una libreria di terze parti, si ha bisogno di pensare, almeno un po 'in anticipo e anticipare le esigenze future alcuni degli utenti. Questo non vuol dire che bisogna rinunciare a YAGNI completamente, ma non si dovrebbe seguire il più strettamente come con uno sviluppo in-house.

Sì, ma ...

Sono d'accordo con molte delle vostre considerazioni tranne il "no disaccoppiamento", perché il "si" in YAGNI sta per funzionalità, non per pensare passi. L'introduzione di alcune astrazioni (solo quelli necessari per il disaccoppiamento) sarà pagare subito in termini di errori non resi o gli errori trovati più rapidamente e rimosso.

Una bella (perché consente di risparmiare pensando) modo per introdurre quelle astrazioni sarebbe quello di utilizzare un buon framework web e semplicemente seguire la sua applicazione suggerito stile strutturazione .

Come un fringe benefit, sarebbe poi diventato molto più facile da aggiungere la sicurezza, in seguito l'internazionalizzazione, le prestazioni, e roba ridimensionamento e il tuo YAGNI-comportamento-ora dovrebbe diventare ragionevolmente sicuri.

(Purtroppo, l'argomento si applica solo se si conosce il framework web già. Conoscenza regna sovrana in YAGNI regno.)

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow