Principi SOLIDI vs YAGNI

Quando i principi SOLIDI diventano YAGNI?

Come programmatori facciamo continuamente dei compromessi, tra complessità, manutenibilità, tempo di costruzione e così via. Tra gli altri, due delle linee guida più intelligenti per fare le scelte sono nella mia mente i principi SOLID e YAGNI. Se non ne hai bisogno; non costruirlo e tenerlo pulito.

Ora, ad esempio, quando guardo la serie dimecast su SOLID , vedo che inizia come un programma abbastanza semplice e finisce per essere piuttosto complesso (fine sì, la complessità è anche negli occhi di chi guarda), ma fa ancora mi chiedo: quando i principi SOLIDI si trasformano in qualcosa che non ti serve? Tutti i solidi principi sono modi di lavorare che consentono l'uso per apportare modifiche in una fase successiva. Ma cosa succede se il problema da risolvere è piuttosto semplice ed è un'applicazione usa e getta, e allora? O i principi SOLIDI sono sempre applicabili?

Come richiesto nei commenti:

• Principi solidi
• YAGNI

È sempre difficile giudicare un approccio basato su uno screencast, poiché i problemi raccolti per le demo sono in genere così piccoli che l'applicazione rapida di principi come SOLID fa sembrare che la soluzione sia completamente ingegnerizzata.

Direi che i principi SOLID sono quasi sempre utili. Una volta che sei diventato esperto con loro, usarli non sembra qualcosa a cui devi deliberatamente pensare. Diventa semplicemente naturale. Ho visto molte app usa e getta diventare più di così, quindi ora ho paura di dire che ho intenzione di buttare via qualcosa, perché non lo sai mai.

L'approccio che di solito seguo è che se scrivo una semplice app per un determinato compito, a volte rinuncio a principi di grandi nomi a favore di alcune righe di codice che funzionano. Se trovo che sto tornando a quell'app per apportare ulteriori modifiche, mi prenderò il tempo per renderlo SOLIDO (almeno un po ', dal momento che un'applicazione al 100% dei principi è raramente fattibile).

Nelle app più grandi, inizio in piccolo e man mano che il programma si evolve, applico i principi SOLID ove possibile. In questo modo non provo a progettare tutto in anticipo fino all'ultimo enum. Questo, per me, è il punto dolce in cui convivono YAGNI e SOLID.

Pensa innanzitutto al problema in questione. Se applichi ciecamente i principi di YAGNI o SOLID, puoi ferirti in seguito. Qualcosa che spero che tutti possiamo capire è che non esiste un "unico" approccio progettuale adatto a tutti i problemi. Puoi vederne le prove quando un negozio vende un cappello pubblicizzato come "taglia unica", ma non si adatta alla tua testa. È troppo grande o troppo piccolo.

Invece, è meglio capire i principi e i problemi che SOLID sta tentando di affrontare; nonché i principi e i problemi che YAGNI sta cercando di affrontare. Scoprirai che uno si occupa dell'architettura della tua applicazione e l'altro riguarda il processo di sviluppo nel suo insieme. Sebbene in alcuni casi possano esserci sovrapposizioni, si tratta di problemi nettamente diversi.

YAGNI (You Ain't Gonna Need It [acronimo americano caratteristico]) si preoccupa di risparmiare tempo per gli sviluppatori aggiungendo basi in cemento armato rinforzato in acciaio a un ponte che ha lo scopo di attraversare solo un'insenatura larga 3 piedi quando un ponte in legno più semplice farà solo bene. Se stiamo attraversando un fiume largo un miglio e dobbiamo supportare diversi rimorchi per trattori, ovviamente avremmo bisogno di ulteriori lavori di fondazione. In sostanza, YAGNI ti sta dicendo di guardare al quadro generale e al design per le esigenze attuali . Sta affrontando il problema di rendere qualcosa di troppo complicato perché stiamo anticipando una serie di potenziali bisogni che il cliente non ha ancora identificato.

SOLID si preoccupa di come assicuriamo che i pezzi del ponte si incastrino correttamente e possano essere mantenuti nel tempo. È possibile applicare i principi SOLIDI al ponte in legno e al ponte in cemento armato armato.

In breve, questi due concetti non sono necessariamente in conflitto tra loro. Quando ti imbatti in una situazione in cui credi che siano, è il momento di dare un'occhiata al quadro generale. A seconda delle tue conclusioni, potresti decidere di eliminare una parte dei principi SOLIDI o potresti decidere di averne davvero bisogno.

I principi SOLID non sono necessari quando si tratta di un'applicazione usa e getta; altrimenti sono sempre necessari.

SOLID e YAGNI non sono in contrasto: un design di buona classe semplifica la manutenzione dell'applicazione. YAGNI afferma semplicemente che non dovresti aggiungere la possibilità per la tua applicazione di essere questa mostruosità configurabile che può fare tutto sotto il sole - a meno che non ne abbia effettivamente bisogno.

È la differenza tra una classe di auto che ha confini ben definiti (SOLID) e una classe di auto che ha la capacità di auto-guarire (YAGNI) prima che il cliente lo richieda.

Nulla si applica sempre! Non lasciare che gli astronauti dell'architettura ti spaventino! L'importante è cercare di capire quali problemi questi principi stanno cercando di affrontare in modo da poter prendere una decisione informata sull'applicazione.

Recentemente stavo cercando di capire quando avrei dovuto usare il principio di responsabilità singola ( ecco cosa mi è venuto in mente).

Spero che sia di aiuto!

C'è una citazione attribuita a Einstein (probabilmente una variazione su una vera ):

"Tutto dovrebbe essere reso il più semplice possibile, ma non più semplice."

E questo è più o meno l'approccio che ho di fronte al compromesso SOLID vs YAGNI: applicali in alternativa, perché non sai mai se un programma è un codice "usa e getta" o no. Quindi, aggiungi solo uno strato di sporco che funzioni, quindi lucidalo su un'interfaccia più pulita ... e ripeti fino a quando convergi al giusto livello di entropia. Fiduciosamente.

Esistono molti modi per progettare un programma per un determinato problema; SOLID è un tentativo di identificare le proprietà di un buon design. L'uso corretto di SOLID dovrebbe comportare un programma più facile da ragionare e modificare.

YAGNI e KISS si occupano dell'ambito delle funzionalità. Un programma che risolve più tipi di problemi è più complesso e astratto. Se non hai bisogno di quella generalità, hai speso tempo e fatica a creare codice che è più difficile da capire e mantenere ma non offre alcun valore aggiunto.

Un programma progettato bene non è necessariamente focalizzato solo sulle funzionalità di cui ha bisogno. Un programma focalizzato solo sulle funzionalità di cui ha bisogno non è necessariamente ben progettato. Non vi è alcun compromesso, solo due assi ortogonali nello spazio decisionale. Un programma ideale è sia modulare che ha solo funzionalità essenziali.

Penso che dovresti avviare YAGNI e ogni volta che ce n'è bisogno, SOLIDificalo.

Quello che voglio dire è che SOLID è lì, quindi quando aggiungi una nuova classe non dovrai fare il refactoring, basta cambiare un'implementazione (per esempio), bene secondo me, scrivi semplicemente il tuo codice e quando vedi che stai cambiando roba - cambiarla con SOLID (cioè il temuto refactoring del SOLID dovrebbe salvarti da - non è così male quando stai solo iniziando).

Non stai perdendo tempo perché dovresti comunque fare il lavoro (all'inizio) e ovunque sia necessario il tuo codice è bello e ordinato.

Immagino che potresti chiamarlo valutazione pigra di SOLID.