SOLID principi vs YAGNI

È sempre difficile giudicare un approccio basato su uno screencast, dal momento che i problemi scelti per le demo sono in genere così limitati che l'applicazione di principi come SOLID fa sembrare rapidamente che la soluzione sia completamente sovradimensionata.

Direi che i principi SOLID sono quasi sempre utili. Una volta acquisito padronanza con loro, utilizzarli non sembra qualcosa a cui devi pensare deliberatamente. Diventa semplicemente naturale. Ho visto molte app one-off scaricabili diventare più di così, quindi ho paura di dire che ho intenzione di buttare via qualcosa, perché non si sa mai.

L'approccio che prendo di solito è che se sto scrivendo una semplice app per un particolare compito, a volte rinuncio a principi di grande nome 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 di renderlo SOLIDO (almeno in qualche modo, dal momento che un'applicazione del 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 cerco di progettare tutto in anticipo fino all'ultimo enum. Questo, per me, è il punto ideale in cui coesistono YAGNI e SOLID.

Pensa innanzitutto al problema in questione. Se applichi ciecamente i principi di YAGNI o SOLID, puoi farti male in seguito. Qualcosa che spero che tutti noi possiamo capire è che non esiste un approccio progettuale "unico" che si adatti a tutti i problemi. Puoi vedere la prova di ciò quando un negozio vende un cappello pubblicizzato come "taglia unica", ma non si adatta alla tua testa. È troppo grande o troppo piccolo.

Invece, è meglio comprendere i principi e i problemi che SOLID sta tentando di risolvere; così come i principi e i problemi che YAGNI sta tentando di affrontare. Scoprirai che uno riguarda l'architettura della tua applicazione e l'altro riguarda il processo di sviluppo nel suo complesso. Anche se in alcuni casi possono esserci sovrapposizioni, sono problemi distintamente diversi.

YAGNI (che non ne avrò bisogno [abbreviato acronimo americano]) si preoccupa di risparmiare tempo per gli sviluppatori aggiungendo fondamenta di cemento armato rinforzate in acciaio a un ponte destinato esclusivamente a un torrente largo 3 piedi quando un ponte di legno più semplice andrà bene. Se stiamo attraversando un fiume largo un miglio e abbiamo bisogno di supportare diversi rimorchi per trattori, ovviamente avremmo bisogno di un lavoro di fondazione extra. In sostanza, YAGNI ti sta dicendo di guardare l'immagine e il design più grandi per le esigenze attuali . Sta affrontando il problema di creare qualcosa di troppo complicato perché stiamo anticipando una serie di potenziali esigenze che il cliente non ha ancora identificato.

SOLID si occupa del modo in cui ci assicuriamo che i pezzi del ponte si adattino correttamente e possano essere mantenuti nel tempo. È possibile applicare i principi SOLID al ponte in legno e al ponte in calcestruzzo rinforzato in acciaio.

In breve questi due concetti non sono necessariamente in conflitto l'uno con l'altro. Quando ti imbatti in una situazione in cui credi di esserlo, è il momento di dare un'occhiata al quadro generale. A seconda della tua conclusione, potresti decidere di eliminare una parte dei principi SOLID o potresti decidere che ne hai davvero bisogno.

I principi SOLIDI non sono necessari quando si tratta di un'applicazione a eliminazione diretta; altrimenti sono sempre necessari.

SOLID e YAGNI non sono in disaccordo: un design di buona qualità rende l'applicazione più facile da mantenere. 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 Car che ha confini ben definiti (SOLID) e una classe di auto che ha la capacità di auto-guarire (YAGNI) prima che il cliente la richieda.

Nulla vale sempre! Non lasciare che Astronauti di architettura ti spaventi! L'importante è cercare di capire quali problemi questi principi stanno cercando di affrontare in modo da poter prendere una decisione informata sull'applicazione di questi principi.

Recentemente stavo cercando di capire quando dovrei usare il Principio di Responsabilità Unica ( ecco cosa mi è venuto in mente.)

Spero che questo aiuti!

Esiste una citazione attribuita a Einstein (probabilmente una variazione su una versione reale ):

“Everything should be made as simple as possible, but no simpler.”

E questo è più o meno l'approccio che prendo di fronte al compromesso SOLID vs YAGNI: applicali in alternativa, perché non sai mai se un programma è un codice 'throw-away' o meno. Quindi, aggiungete uno strato di sporco che funziona, quindi lucidatelo su un'interfaccia più pulita ... e ripetete fino a quando non converrete al giusto livello di entropia. Speriamo.

Ci sono molti modi per progettare un programma per un dato problema; SOLID è un tentativo di identificare le proprietà di un buon design. Si suppone che l'uso corretto di SOLID determini 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 ben progettato 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 caratteristiche essenziali.

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

Ciò che intendo è SOLIDO c'è, quindi quando aggiungi una nuova classe non dovrai refactoring, cambia semplicemente implementazione (ad esempio), a mio avviso, scrivi semplicemente il tuo codice, e quando vedi che tu Cambiando roba - cambia con SOLID (cioè il temuto refactoring di cui il SOLID dovrebbe salvarti - non è così male quando stai iniziando).

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

Suppongo che potresti chiamarlo valutazione pigra di SOLID.