La soluzione dovrebbe essere il più generica possibile o specifica possibile?

La mia regola empirica:

1. la prima volta che incontri il problema, risolvi solo il problema specifico (questo è il principio YAGNI )
2. la seconda volta che ti imbatti nello stesso problema, considera la generalizzazione del primo caso, se non è un gran lavoro
3. una volta che hai tre casi specifici in cui potresti usare la versione generalizzata, dovresti iniziare a pianificare realmente la versione generalizzata - ormai dovresti capire il problema abbastanza bene da essere in grado di generalizzarlo.

Naturalmente, questa è una linea guida e non una regola ferrea: la vera risposta è usare il tuo miglior giudizio, caso per caso.

A specific solution [...] requires more work in the future if similar requirement is needed

Ho sentito questa argomentazione diverse decine di volte, e - per la mia esperienza - si rivela regolarmente un errore. Se si generalizza ora o dopo, quando sorge il secondo requisito simile, il lavoro sarà quasi lo stesso in totale. Quindi non vi è assolutamente alcun motivo per investire ulteriori sforzi nella generalizzazione, quando non si sa che questo sforzo potrà mai ripagare.

(Ovviamente questo non si applica quando una soluzione più generale è meno complicata e richiede meno sforzo di una specifica, ma per mia esperienza, questi sono casi rari.Questo tipo di scenario è stato successivamente modificato nella domanda, e non è quello di cui la mia risposta parla).

Quando compare il "secondo caso simile", è ora di iniziare a pensare alla generalizzazione. Sarà molto più semplice generalizzare correttamente , poiché questo secondo requisito ti offre uno scenario in cui puoi convalidare se hai fatto le cose giuste generiche. Quando cerchi di generalizzare solo per un caso, stai sparando al buio. È molto probabile che tu superi troppo le cose che non hanno bisogno di essere generalizzate e perdi altre parti che dovrebbero. E quando poi sorge un secondo caso e ti rendi conto di aver generalizzato le cose sbagliate, allora hai molto più lavoro da fare per risolvere il problema.

Quindi consiglio di ritardare la tentazione di fare cose "nel caso in cui". Questo approccio porterà solo a maggiori sforzi di lavoro e di manutenzione quando ti sei perso l'occasione di generalizzare tre, quattro o più volte e poi di avere un mucchio di codice simile all'aspetto (quindi duplicato) da mantenere.

TL; DR: dipende da cosa stai cercando di risolvere.

Ho avuto una conversazione simile con i miei nonni su questo argomento, mentre stavamo parlando di come Func e Action in C # siano fantastici. My Gramps è un programmatore di timer molto vecchio, che è stato intorno ai codici sorgente da quando il software è stato eseguito su computer che occupavano un'intera stanza.

Ha cambiato tecnologia diverse volte nella sua vita. Ha scritto codice in C, COBOL, Pascal, BASIC, Fortran, Smalltalk, Java e alla fine ha iniziato C # come hobby. Ho imparato a programmare con lui, seduto sulle sue ginocchia mentre ero solo un diavoletto, intagliando le mie prime linee di codice sull'editor blu di IBM SideKick. All'età di 20 anni, avevo già passato più tempo a programmare che a giocare fuori.

Questi sono un po 'dei miei ricordi, quindi scusami se non sono esattamente pratico mentre li rivivo. Sono un po 'affezionato a quei momenti.

Questo è quello che mi ha detto:

"Se dovessimo andare alla generalizzazione di un problema o risolverlo nello specifico ambito, chiedete? Bene, questa è una ... domanda".

I nonni fecero una pausa per pensarci per un breve momento, mentre fissava la posizione degli occhiali sul suo viso. Stava giocando un gioco match-3 sul suo computer, mentre ascoltava un LP dei Deep Purple sul suo vecchio sistema audio.

"Beh, ciò dipenderà dal problema che stai cercando di risolvere", mi ha detto. "Si è tentati di credere che esista un'unica, santa soluzione per tutte le scelte progettuali, ma non ce n'è una: l'architettura del software è come il formaggio, vedi".

"... Formaggi, nonnine?"

"Non importa cosa pensi del tuo preferito, ci sarà sempre qualcuno che pensa che sia maleodorante".

Ho blinkato per un momento nella confusione, ma prima che potessi dire qualcosa, il nonno è andato avanti.

"Quando costruisci una macchina, come scegli il materiale per una parte?"

"Io ... penso che dipenda dai costi coinvolti e da cosa dovrebbe fare la parte, suppongo."

"Dipende dal problema che la parte sta cercando di risolvere: non costruirai un pneumatico in acciaio o un parabrezza in pelle: scegli il materiale che meglio risolve il problema che hai a portata di mano. che cos'è una soluzione generica o specifica? A quale problema, a quale caso d'uso? Dovresti andare con un approccio completamente funzionale, per dare la massima flessibilità a un codice che sarà usato una sola volta? codice fragile per una parte del tuo sistema che vedrà un sacco di usi e forse un sacco di cambiamenti? Le scelte di progettazione come quelle sono come i materiali che scegli per una parte in una macchina o la forma del mattoncino Lego che scegli per costruire una piccola casa: quale mattoncino Lego è il migliore? "

L'anziano programmatore ha raggiunto un modello di treno Lego che ha sul tavolo prima di continuare.

"Puoi rispondere solo se sai per cosa hai bisogno di quel mattone. Come diavolo saprai se la soluzione specifica è migliore di quella generica, o viceversa, se non sai nemmeno quale problema stai cercando di risolvere? Non puoi vedere oltre una scelta che non capisci. "

".. Hai appena citato The Matrix? "

"Cosa?"

"Niente, continua."

"Supponiamo che tu stia cercando di costruire qualcosa per il sistema nazionale delle fatture: sai come appare quella API infernale e il suo file XML di trentamila righe dall'interno. Come sarebbe una soluzione" generica "per la creazione di quel file Il file è pieno di parametri facoltativi, pieni di casi che devono essere utilizzati solo rami aziendali molto specifici.Per la maggior parte dei casi, puoi tranquillamente ignorarli.Non è necessario creare un sistema di fatture generico se l'unico cosa che venderai mai è solo scarpe, basta creare un sistema per vendere scarpe e renderlo il miglior sistema di vendita di scarpe venduto là. Ora, se dovessi creare un sistema di fatturazione per qualsiasi tipo di cliente, su un altro ampia applicazione - per essere rivenduta come un sistema di vendita generico indipendente, ad esempio - ora è interessante implementare quelle opzioni che sono utilizzate solo per gas, cibo o alcol. Ora sono possibili casi d'uso. Prima erano solo alcuni casi ipotetici Non usare , a d non vuoi implementare i casi Non utilizzare . Non utilizzare è il fratello minore di Non è necessario . "

I Gramp hanno rimesso il treno lego al suo posto e sono tornati al suo gioco match-3.

"Quindi, per essere in grado di scegliere una soluzione generica o specifica per un determinato problema, devi prima capire che diavolo è questo problema. Altrimenti stai solo indovinando, e suppongo sia il lavoro dei manager, non dei programmatori Come quasi tutto in IT, dipende. "

Quindi, ce l'hai. "Dipende". Questa è probabilmente la più potente espressione di due parole quando si pensa alla progettazione del software.

In primo luogo, dovresti cercare di anticipare se è probabile che si verificherà un tale cambiamento - non solo una possibilità remota da qualche parte lungo la linea.

In caso contrario, di solito è meglio andare ora per la soluzione semplice ed estenderla in seguito. È possibile che tu abbia un'immagine molto più chiara di ciò che è necessario allora.

Se lavori in un dominio che è nuovo per te, rispetto a Regola dei tre che Daniel Pryden menzionato sicuramente dovrebbe essere applicato. Dopo tutto, come dovresti costruire astrazioni utili se sei un principiante in quella zona? Spesso le persone sono sicure di sé nella capacità di cogliere le astrazioni, anche se è raro che sia così. Secondo la mia esperienza, l'astrazione prematura non è meno malvagia della duplicazione del codice. Le astrazioni sbagliate sono davvero dolorose da comprendere. A volte anche più doloroso da refactoring.

C'è un libro che parla del punto in cui uno sviluppatore di un'area sconosciuta sta lavorando. È costituito da domini specifici con astrazioni utili estratte.

Data la natura del corpo della tua domanda, supponendo che l'abbia capita correttamente, in realtà la vedo come una questione di progettazione delle funzionalità del sistema centrale più che una domanda su soluzioni generiche o specifiche.

E quando si tratta di funzionalità e funzionalità del sistema centrale, quelle più affidabili sono quelle che non ci sono. Vale la pena di sbagliare dal lato del minimalismo, soprattutto considerando che è generalmente più semplice aggiungere funzionalità centralmente, a lungo desiderato, piuttosto che rimuovere funzionalità problematiche, a lungo indesiderate, con numerose dipendenze perché ha reso il lavoro con il sistema molto più difficile di quanto deve essere mentre solleva infinite domande di design con ogni nuova funzionalità.

In effetti, in mancanza di una strong previsione di ciò che sarà necessario frequentemente in futuro, cercherò di evitare di considerare questo come un tipo di sostituzione da A a B, se possibile, e invece lo cerco come un modo per trasformare A stato. Ad esempio, imposta alcuni campi in A per trasformarlo in metamorfosi e apparire come B all'utente senza effettivamente cambiarlo in un "tipo" di cosa diverso - potresti potenzialmente rendere A un negozio B privatamente utilizzando le funzioni di composizione e chiamata in B quando lo stato di A è impostato per indicare che dovrebbe simulare B per semplificare l'implementazione, se possibile. Questa dovrebbe essere una soluzione molto semplice e minimamente invasiva.

Ad ogni modo, facendo eco a molti altri, suggerirei di sbagliare dal lato di evitare soluzioni generiche in questo caso, ma soprattutto perché presumo che questo sia in considerazione dell'aggiunta di una capacità molto audace al sistema centrale, e lì Ti suggerirei di sbagliare sul lato di lasciarlo fuori, soprattutto per ora.

È difficile dare una risposta generica a questo specifico problema ;-)

Più è generico, più tempo otterrai per le modifiche future. Ad esempio per questo motivo molti programmi di gioco utilizzano invece il modello di componente entità di costruire un sistema di tipo molto elaborato ma rigido dei personaggi e degli oggetti nel gioco.

D'altra parte, fare qualcosa di generico richiede un investimento iniziale in termini di tempo e impegno nel design, che è molto più alto rispetto a qualcosa di molto specifico. Ciò comporta il rischio di sovraingegnerizzazione e persino di perdersi in potenziali esigenze future.

Vale sempre la pena di vedere se c'è una generalizzazione naturale che ti porterà una svolta. Tuttavia, alla fine, è una questione di equilibrio, tra lo sforzo che è possibile trascorrere ora e lo sforzo che potrebbe essere necessario in futuro.

1. ibrida. Questo non deve essere una o / o domanda. Puoi progettare l'API per le conversioni di tipo generale mentre implementa solo la conversione specifica di cui hai bisogno in questo momento. (Assicurati che se qualcuno chiama la tua API generale con una conversione non supportata, fallisce con uno stato di errore "non supportato".)

2. Test. Per la conversione A- > B, dovrò scrivere uno (o un piccolo numero) di test. Per una generica conversione x- > y, potrei dover scrivere un'intera matrice di test. Questo è sostanzialmente più lavoro, anche se tutte le conversioni condividono un'unica implementazione generica.

   Se, d'altra parte, risulta essere un modo generico per testare tutte le conversioni possibili, allora non c'è molto più lavoro e potrei essere propenso ad andare a una soluzione generica prima.

3. accoppiamento. Un convertitore da A a B potrebbe dover necessariamente conoscere i dettagli di implementazione di A e B (accoppiamento stretto). Se A e B si stanno ancora evolvendo, questo significa che potrei dover continuare a rivisitare il convertitore (ei suoi test), il che fa schifo, ma almeno è limitato ad A e B.

   Se fossi andato con una soluzione generica che ha bisogno di accedere ai dettagli di tutti i tipi, anche se C e D si evolvono, potrei aver bisogno di continuare a modificare il convertitore generico (e una serie di test), che può rallentare giù anche se nessuno ha ancora bisogno di convertirsi in C o D .

   Se entrambe le conversioni generiche e specifiche possono essere implementate in un modo che è solo approssimativamente associato ai dettagli dei tipi, non mi preoccuperei di ciò. Se uno di questi può essere fatto in un modo sciolto, ma l'altro richiede un accoppiamento stretto, allora questo è un argomento strong per l'approccio unilaterale appena uscito dal cancello.

Should the solution be as generic as possible or as specific as possible?

Questa non è una domanda a cui rispondere.

Il meglio che si può ragionevolmente ottenere è un paio di euristiche per decidere in che modo generale o specifico fare una determinata soluzione. Lavorando attraverso qualcosa come il processo sottostante, di solito l'approssimazione del primo ordine è corretta (o abbastanza buona). Quando non lo è, è probabile che la ragione sia troppo specifica per il dominio per essere adeguatamente descritta in dettaglio qui.

1. Approssimazione del primo ordine: la consueta regola YAGNI di tre come descritto da Daniel Pryden, Doc Brown, et al .

   Questa è un'euristica generalmente utile perché probabilmente è il meglio che puoi fare che non dipende dal dominio e da altre variabili.

   Quindi, la presunzione iniziale è: facciamo la cosa più specifica.

2. Approssimazione del secondo ordine: in base alla tua conoscenza approfondita del dominio della soluzione , dici

   The "generic" solution in this case requires less work than the "specific" solution

   quindi potremmo reinterpretare YAGNI raccomandandoci di evitare inutili lavori , piuttosto che evitare generalità inutili. Quindi, potremmo modificare la nostra presunzione iniziale e invece fare la cosa più semplice .

   Tuttavia, se la conoscenza del dominio della soluzione indica che la soluzione più semplice è probabile che apra molti bug, o sia difficile da testare adeguatamente, o causi altri problemi, essere più facile da codificare non è necessariamente una ragione sufficiente per cambiare la nostra scelta originale.

3. Approssimazione del terzo ordine: la tua conoscenza del dominio problematico suggerisce che la soluzione più semplice sia effettivamente corretta, oppure stai permettendo che molte transizioni che conosci non abbiano alcun significato o torto?

   Se la soluzione facile ma generica sembra problematica, o non sei sicuro della tua capacità di giudicare questi rischi, fare il lavoro extra e stare con la tua ipotesi iniziale è probabilmente meglio.

4. Approssimazione del quarto ordine: la tua conoscenza del comportamento del cliente, o in che modo questa caratteristica si relaziona con gli altri, o le priorità di gestione del progetto, o ... altre considerazioni non strettamente tecniche modificano la tua attuale decisione di lavoro?

Questa non è una domanda facile a cui rispondere con una semplice risposta. Molte risposte hanno dato un'euristica costruita attorno a una regola del 3 o qualcosa di simile. Superare tali regole empiriche è difficile.

Per rispondere veramente alla tua domanda, devi considerare che probabilmente il tuo lavoro non implementerà qualcosa che modifica A- > B. Se sei un appaltatore, forse è questo il requisito, ma se sei un dipendente, sei stato assunto per svolgere molti compiti più piccoli per l'azienda. Cambiare A- > B è solo una di quelle attività. La tua azienda si preoccuperà anche di come possano essere apportate le modifiche future, anche se ciò non è indicato nella richiesta. Per trovare "TheBestImplementation (tm)", devi guardare l'immagine più ampia di ciò che ti viene chiesto di fare, e poi usarlo per interpretare la piccola richiesta che ti è stata data per cambiare A- > B.

Se sei un programmatore entry level di basso livello appena uscito dal college, è spesso consigliabile fare esattamente ciò che ti è stato detto di fare. Se sei stato assunto come architetto di software con 15 anni di esperienza, in genere è consigliabile pensare a grandi cose. Ogni lavoro effettivo cadrà da qualche parte tra "fai esattamente quello che è il compito ristretto" e "pensa al quadro generale". Sentirai dove il tuo lavoro si adatta a quello spettro se parli abbastanza con le persone e fai abbastanza lavoro per loro.

Posso dare alcuni esempi concreti in cui la tua domanda ha una risposta definitiva basata sul contesto. Considerare il caso in cui si sta scrivendo un software critico per la sicurezza. Ciò significa che hai un team di test alzato per garantire che il prodotto funzioni come promesso. Alcuni di questi gruppi di test sono tenuti a testare ogni singolo percorso possibile attraverso il codice. Se parli con loro, potresti scoprire che se generalizzi il comportamento, aggiungerai $ 30.000 ai costi dei test perché dovranno testare tutti questi percorsi aggiuntivi. In tal caso, non aggiungi funzionalità generalizzate, anche se devi duplicare il lavoro 7 o 8 volte a causa di esso. Salva i soldi dell'azienda e fai esattamente ciò che la richiesta ha indicato.

Dall'altro lato, considera che stai creando un'API per consentire ai clienti di accedere ai dati in un programma di database realizzato dalla tua azienda. Un cliente richiede di consentire le modifiche A- > B. Le API hanno in genere un aspetto delle manette d'oro: una volta aggiunta la funzionalità a un'API, in genere non è necessario rimuovere tale funzionalità (fino al prossimo numero di versione principale). Molti dei tuoi clienti potrebbero non essere disposti a pagare il costo dell'aggiornamento al prossimo numero di versione principale, quindi potresti rimanere bloccato con qualsiasi soluzione tu scelga da molto tempo. In questo caso, I altamente consiglia di creare la soluzione generica dall'inizio. Davvero non vuoi sviluppare una API scadente piena di comportamenti unici.

Hmm ... non molto contesto per dare una risposta ... echeggiare risposte precedenti, "Dipende".

In un certo senso, devi ricorrere alla tua esperienza. Se non il tuo, allora qualcuno più anziano nel dominio. Si può cavillare su quale sia il criterio di accettazione. Se è qualcosa sulla falsariga di "l'utente dovrebbe essere in grado di cambiare il tipo da" A "a" B "" contro "l'utente dovrebbe essere in grado di cambiare il tipo dal suo valore corrente a qualsiasi valore alternativo consentito".

I criteri di accettazione frequenti sono soggetti a interpretazione, ma un buon personale addetto al controllo qualità può scrivere criteri appropriati per l'attività da svolgere, riducendo al minimo l'interpretazione necessaria.

Esistono restrizioni di dominio che non consentono di passare da "A" a "C" o qualsiasi altra opzione, ma solo da "A" a "B"? O è solo un requisito strettamente specificato che non è "lungimirante"?

Se il caso generale fosse più difficile, andrei a chiedere prima di iniziare il lavoro, ma nel tuo caso se potessi 'prevedere' che altre richieste di modifica di tipo 'verrebbero in futuro, sarei tentato di : a) scrivere qualcosa riutilizzabile per il caso generale, e b) avvolgere in un condizionale che consente solo A - > B per ora.

Semplice da verificare per il caso corrente nei test automatici e abbastanza facile da aprirsi ad altre opzioni in seguito se / quando emergono casi d'uso diversi.

Per me, una linea guida che ho stabilito qualche tempo fa è: "Per i requisiti ipotetici scrivi solo codice ipotetico". Cioè - se prevedi requisiti aggiuntivi, dovresti pensare un po 'a come implementarli e strutturare il tuo codice attuale in modo che non blocchi in quel modo.

Ma non scrivere il codice attuale per questi ora - pensa solo un po 'a cosa faresti. Altrimenti, di solito, le cose diventano inutilmente complesse e, in futuro, saranno probabilmente infastidite quando i requisiti effettivi diverranno diversi da quanto previsto.

Quattro esempi: se hai tutti gli usi del metodo di conversione sotto il tuo controllo, per ora puoi chiamarlo convertAToB e pianifica di utilizzare un refactoring "metodo di rinomina" nell'IDE per rinominarlo se ti serve più generale funzionalità più tardi. Tuttavia, se il metodo di conversione fa parte di un'API pubblica, questo potrebbe essere molto diverso: essere specifico potrebbe bloccare la generalizzazione in un secondo momento, poiché in questo caso è difficile rinominare le cose.

I keep hearing that a good developer should try to anticipate the change and design the system so that it's easy to extend in the future,

In linea di principio, sì. Ma questo non porta necessariamente a soluzioni generiche.

Ci sono due tipi di argomenti nello sviluppo del software, per quanto mi riguarda, in cui dovresti anticipare le modifiche future:

• Librerie destinate a essere utilizzate da terze parti e
• architettura generale del software.

Il primo caso viene risolto osservando la tua coesione / accoppiamento, iniezione di dipendenza o qualsiasi altra cosa. Il secondo caso è a un livello più astratto, ad esempio scegliendo un'architettura orientata al servizio invece di un grosso blob monolingue di codice per una grande applicazione.

Nel tuo caso, stai chiedendo una soluzione specifica per un problema specifico, che non ha alcun impatto prevedibile sul futuro. In questo caso, YAGNI e DRY sono buoni motti per sparare per:

• YAGNI (non ne avrai bisogno) ti dice di implementare il minimo indispensabile di base di cui hai bisogno e di usare adesso . Significa implementare il minimo che rende la tua attuale suite di test da rossa a verde, se dovessi usare lo sviluppo di stile TDD / BDD / FDD. Non una sola riga in più.
• ASCIUTA (non ripeterti) significa che se ti imbatti nuovamente in un problema simile, allora fai una buona occhiata se hai bisogno di una soluzione generica.

In combinazione con altre pratiche moderne (come una buona copertura di test per essere in grado di refactoring in modo sicuro) questo significa che si finisce con un codice scritto, snello, medio, che cresce quando necessario.

which sounds like a generic solution is the way to go?

No, sembra che dovresti avere ambienti di programmazione, linguaggi e strumenti che rendono facile e divertente il refactoring quando ne hai bisogno. Le soluzioni generiche non forniscono questo; dissociano l'applicazione dal dominio effettivo.

Dai un'occhiata ai moderni ORM o quadri MVC, ad esempio Ruby on Rails; a livello di applicazione, tutto si concentra sul lavoro non generico. Le librerie di rails sono ovviamente quasi del 100% generiche, ma il codice di dominio (di cui tratta la tua domanda) dovrebbe fare un minimo di shenanigans in questo aspetto.

Un modo diverso di pensare al problema è considerare ciò che ha senso.

Ad esempio, c'era un'applicazione che stavo sviluppando che conteneva sezioni che facevano quasi la stessa cosa ma che avevano regole di autorizzazione incoerenti. Poiché non c'era motivo di tenerli diversi, quando ho refactorato quella sezione, ho fatto in modo che tutti facessero le autorizzazioni allo stesso modo. Il codice complessivo è stato ridotto, più semplice e l'interfaccia era più coerente.

Quando la direzione ha deciso di consentire ad altre persone l'accesso a una funzione, siamo riusciti a farlo cambiando semplicemente una bandiera.

Ovviamente ha senso effettuare la conversione del tipo specifico. Ha senso anche fare conversioni di tipo addinzionali?

Ricorda che se la soluzione generale è più veloce da implementare, allora anche il caso specifico è facile, basta controllare che sia l'unica conversione di tipo che stai permettendo.

Se l'applicazione si trova in un'area altamente regolamentata (un'applicazione medica o finanziaria), cerca di coinvolgere più persone nella tua progettazione.