Seguire SOLID porta a scrivere un framework in cima allo stack tecnologico?

Mi piace SOLID e faccio del mio meglio per usarlo e applicarlo durante lo sviluppo. Ma non posso fare a meno di pensare che l'approccio SOLID trasformi il tuo codice in codice "framework", ovvero il codice che progetteresti se stessi creando un framework o una libreria che altri sviluppatori possano usare.

In genere ho praticato 2 modalità di programmazione: creare più o meno esattamente ciò che viene richiesto tramite requisiti e KISS (programmazione tipica), oppure creare logiche, servizi, ecc. Molto generici e riutilizzabili che forniscano la flessibilità di cui altri sviluppatori potrebbero aver bisogno (programmazione quadro) .

Se l'utente vuole davvero che un'applicazione faccia cose xey, ha senso seguire SOLID e aggiungere un sacco di punti di ingresso di astrazione, quando non sai nemmeno se questo è anche un problema valido per iniziare con? Se aggiungi questi punti di ingresso di astrazione, stai davvero soddisfacendo i requisiti degli utenti o stai creando un framework in aggiunta al tuo framework esistente e stack tecnologico per rendere più facili le aggiunte future? In quale caso stai servendo gli interessi del cliente o dello sviluppatore?

Questo è qualcosa che sembra comune nel mondo Java Enterprise, in cui sembra che tu stia progettando il tuo framework sopra J2EE o Spring in modo che sia una UX migliore per lo sviluppatore, invece di concentrarsi su UX per l'utente?

La tua osservazione è corretta, i principi SOLID sono IMHO realizzati tenendo in considerazione librerie riutilizzabili o codice framework. Quando li segui tutti alla cieca, senza chiedere se ha senso o no, stai rischiando di sovra-generalizzare e investire molto più sforzo nel tuo sistema di quanto probabilmente necessario.

Questo è un compromesso e ha bisogno di esperienza per prendere le giuste decisioni su quando generalizzare e quando no. Un possibile approccio a questo è attenersi al principio YAGNI - non rendere il codice SOLIDO "per ogni evenienza" - o, per usare le tue parole: non

fornire la flessibilità di cui altri sviluppatori potrebbero aver bisogno

invece, fornisce la flessibilità di cui gli altri sviluppatori hanno effettivamente bisogno non appena ne hanno bisogno , ma non prima.

Quindi ogni volta che hai una funzione o una classe nel tuo codice non sei sicuro che possa essere riutilizzato, non metterlo nel tuo framework in questo momento. Attendi fino a quando non avrai un caso reale di riutilizzo e refactoring su "SOLIDI abbastanza per quel caso". Non implementare più configurabilità (seguendo l'OCP) o punti di ingresso dell'astrazione (usando il DIP) in una classe di cui hai veramente bisogno per il caso reale di riutilizzo. Aggiungi la flessibilità successiva quando il prossimo requisito per il riutilizzo è effettivamente presente.

Naturalmente, questo modo di lavorare richiederà sempre una certa quantità di refactoring nella base di codice esistente e funzionante. Ecco perché i test automatici sono importanti qui. Quindi rendere il tuo codice SOLID abbastanza dall'inizio sin dall'inizio per renderlo unitamente testabile non è una perdita di tempo, e farlo non contraddice YAGNI. I test automatici sono un caso valido per il "riutilizzo del codice", poiché il codice in questione viene utilizzato sia dal codice di produzione che dai test. Ma tieni a mente, aggiungi solo la flessibilità di cui hai effettivamente bisogno per far funzionare i test, niente di meno, niente di più.

Questa è in realtà una vecchia saggezza. Molto tempo fa prima che il termine SOLID ottenuto popolare, qualcuno mi ha detto, prima di provare a scrivere nuovamente il codice utilizzabile, dovremmo scrivere utilizzabile codice. E penso ancora che questa sia una buona raccomandazione.

Dalla mia esperienza, quando scrivo un'app, hai tre opzioni:

1. Scrivi il codice esclusivamente per soddisfare i requisiti,
2. Scrivi un codice generico che anticipi i requisiti futuri, oltre a soddisfare i requisiti attuali,
3. Scrivi un codice che soddisfi solo i requisiti attuali, ma che sia facile da modificare in seguito per soddisfare altre esigenze.

Nel primo caso, è comune finire con un codice strettamente accoppiato privo di test unitari. Certo è veloce da scrivere, ma è difficile da testare. Ed è un vero dolore reale cambiare in seguito quando cambiano i requisiti.

Nel secondo caso, si impiegano enormi quantità di tempo nel tentativo di anticipare le esigenze future. E troppo spesso quei futuri requisiti previsti non si materializzano mai. Questo sembra lo scenario che stai descrivendo. È una perdita di sforzo per la maggior parte del tempo e si traduce in un codice inutilmente complesso che è ancora difficile da modificare quando si presenta un requisito che non era previsto per la presentazione.

L'ultimo caso è quello a cui mirare a mio avviso. Usa TDD o tecniche simili per testare il codice mentre procedi e finirai con un codice liberamente accoppiato, che è facile da modificare ma ancora veloce da scrivere. E il fatto è che, facendo questo, segui naturalmente molti dei principi SOLIDI: piccole classi e funzioni; interfacce e dipendenze iniettate. E la signora Liskov è generalmente anche felice perché le lezioni semplici con responsabilità individuali raramente si rompono del suo principio di sostituzione.

L'unico aspetto di SOLID che in realtà non si applica qui è il principio aperto / chiuso. Per biblioteche e framework, questo è importante. Per un'app indipendente, non tanto. In realtà si tratta di scrivere codice che segue " SLID ": facile da scrivere (e leggere), facile da testare e facile da mantenere.

La prospettiva che hai può essere distorta dall'esperienza personale. Questa è una pendenza scivolosa di fatti che sono individualmente corretti, ma l'inferenza che ne risulta non lo è, anche se a prima vista sembra corretta.

• I frame hanno una portata maggiore rispetto ai piccoli progetti.
• Le cattive pratiche sono significativamente più difficili da affrontare in basi di codice più grandi.
• La costruzione di un framework (in media) richiede uno sviluppatore più abile rispetto alla costruzione di un piccolo progetto.
• Gli sviluppatori migliori seguono di più le buone pratiche (SOLID).
• Di conseguenza, i framework hanno un bisogno maggiore di buone pratiche e tendono a essere creati da sviluppatori che hanno una maggiore esperienza con le buone pratiche.

Ciò significa che quando interagisci con framework e librerie più piccole, il codice di buone pratiche con cui interagirai sarà più comunemente trovato nei framework più grandi.

Questo errore è molto comune, ad es ogni medico con cui sono stato curato era arrogante. Pertanto, concludo che tutti i medici sono arroganti. Questi errori soffrono sempre facendo un'inferenza generale basata su esperienze personali.

Nel tuo caso, è possibile che tu abbia sperimentato prevalentemente buone pratiche in framework più grandi e non in librerie più piccole. La tua osservazione personale non è sbagliata, ma lo è una prova aneddotica e non universalmente applicabile.

2 modalità di programmazione: creare più o meno esattamente ciò che viene richiesto tramite requisiti e KISS (programmazione tipica) o creare logiche, servizi, ecc. Molto generici e riutilizzabili che offrano la flessibilità di cui altri sviluppatori potrebbero aver bisogno (programmazione quadro)

Lo stai confermando in qualche modo qui. Pensa a cos'è un framework. Non è un'applicazione. È un "modello" generalizzato che gli altri possono utilizzare per realizzare ogni tipo di applicazione. Logicamente, ciò significa che un framework è costruito in una logica molto più astratta per essere utilizzabile da tutti.

I costruttori di framework non sono in grado di prendere scorciatoie, perché non sanno nemmeno quali sono i requisiti delle applicazioni successive. Costruire un framework li incentiva intrinsecamente a rendere il loro codice utilizzabile per gli altri.

I costruttori di applicazioni, tuttavia, hanno la capacità di scendere a compromessi in termini di efficienza logica perché sono focalizzati sulla consegna di un prodotto. Il loro obiettivo principale non è il funzionamento del codice ma piuttosto l'esperienza dell'utente.

Per un framework, l'utente finale è un altro sviluppatore, che interagirà con il tuo codice. La qualità del codice è importante per l'utente finale.
Per un'applicazione, l'utente finale è un non sviluppatore, che non interagirà con il codice. La qualità del tuo codice non ha importanza per loro.

Questo è esattamente il motivo per cui gli architetti di un team di sviluppo spesso agiscono come esecutori di buone pratiche. Sono a un passo dalla consegna del prodotto, il che significa che tendono a guardare il codice in modo obiettivo, piuttosto che concentrarsi sulla consegna dell'applicazione stessa.

Se aggiungi questi punti di ingresso di astrazione, stai davvero soddisfacendo i requisiti degli utenti o stai creando un framework in aggiunta al tuo framework esistente e stack tecnologico per rendere più facili le aggiunte future? In quale caso stai servendo gli interessi del cliente o dello sviluppatore?

Questo è un punto interessante ed è (secondo la mia esperienza) il motivo principale per cui le persone cercano ancora di giustificare l'evitamento delle buone pratiche.

Riassumendo i seguenti punti: Saltare le buone pratiche può essere giustificato solo se i tuoi requisiti (come attualmente conosciuti) sono immutabili e non ci saranno mai cambiamenti / aggiunte alla base di codice. Avviso spoiler: raramente è così.
Ad esempio, quando scrivo un'applicazione console di 5 minuti per elaborare un determinato file, non utilizzo le buone pratiche. Perché oggi userò l'applicazione e non sarà necessario aggiornarla in futuro (sarebbe più semplice scrivere un'applicazione diversa se ne avessi bisogno di nuovo).

Supponiamo che tu possa compilare debolmente un'applicazione in 4 settimane e puoi costruirla correttamente in 6 settimane. A prima vista, costruire debolmente sembra meglio. Il cliente ottiene la sua applicazione più rapidamente e l'azienda deve dedicare meno tempo ai salari degli sviluppatori. Vinci / vinci, vero?

Tuttavia, questa è una decisione presa senza pensare al futuro. A causa della qualità della base di codice, per apportare una modifica sostanziale a quella costruita in modo scadente ci vorranno 2 settimane, mentre per apportare le stesse modifiche a quella costruita correttamente richiede 1 settimana. Potrebbero esserci molti di questi cambiamenti in arrivo in futuro.

Inoltre, vi è la tendenza per le modifiche a richiedere inaspettatamente più lavoro di quanto si pensasse inizialmente in codebase costruite in modo scadente, quindi probabilmente spingendo il tempo di sviluppo a tre settimane anziché due.

E poi c'è anche la tendenza a perdere tempo a caccia di bug. Questo è spesso il caso di progetti in cui la registrazione è stata ignorata a causa di vincoli di tempo o di totale riluttanza a implementarla perché si lavora distrattamente supponendo che il prodotto finale funzionerà come previsto.

Non è nemmeno necessario che sia un aggiornamento importante. Nel mio attuale datore di lavoro, ho visto diversi progetti realizzati in modo rapido e sporco e quando il più piccolo bug / modifica doveva essere fatto a causa di una comunicazione errata nei requisiti, che portava a una reazione a catena della necessità di refactoring modulo dopo modulo . Alcuni di questi progetti finirono per crollare (e lasciare dietro di sé un caos non mantenibile) prima ancora di rilasciare la loro prima versione.

Le decisioni di scelta rapida (programmazione rapida e sporca) sono utili solo se si può garantire in modo definitivo che i requisiti sono esattamente corretti e non dovranno mai cambiare. Nella mia esperienza, non ho mai incontrato un progetto in cui questo è vero.

Investire il tempo extra in buone pratiche è investire nel futuro. I futuri bug e modifiche saranno molto più facili quando la base di codice esistente sarà basata su buone pratiche. Pagherà già i dividendi dopo che sono state apportate solo due o tre modifiche.

In che modo SOLID trasforma il codice semplice in codice framework? Non sono assolutamente uno stan per SOLID ma non è proprio ovvio che cosa intendi qui.

• BACIO è l'essenza della S Responsabilità ingle Principio.
• Non c'è nulla nel principio O / Principio chiuso (almeno per quello che ho capito - vedi Jon Skeet ) che va contro la scrittura del codice per fare bene una cosa. (In effetti, più il codice è strettamente focalizzato, più diventa importante la parte "chiusa").
• Il principio di sostituzione L iskov non dice che devi permettere alle persone di sottoclassare le tue classi. Si dice che se si sottoclasse vostre classi, sottoclassi dovrebbero rispettare il contratto delle loro superclassi. Questo è solo un buon design OO. (E se non hai sottoclassi, non si applica.)
• BACIO è anche l'essenza del I nterface segregazione Principio.
• Il D ependency inversione principio è l'unico che posso vedere da remoto l'applicazione, ma penso che sia ampiamente incompreso e esagerata. Ciò non significa che devi iniettare tutto con Guice o Spring. Significa solo che dovresti astrarre dove appropriato e non dipendere dai dettagli di implementazione.

Ammetto di non pensare io stesso in termini SOLIDI, perché mi sono imbattuto nelle scuole di programmazione Gang of Four e Josh Bloch , non nella scuola di Bob Martin. Ma penso davvero che se pensi che "SOLID" = "aggiungendo più livelli allo stack tecnologico", stai leggendo male.

PS Non vendere i vantaggi di "UX migliore per lo sviluppatore" in breve. Il codice trascorre gran parte della sua vita in manutenzione. Uno sviluppatore sei tu .