Nella programmazione ci troviamo spesso di fronte a una scelta: coprire ogni caso d'uso concepibile individualmente o risolvere il problema generale:
È ovvio che la risoluzione del problema immediato sia più veloce, tuttavia la creazione di una soluzione generalizzata farà risparmiare tempo in futuro.
Come faccio a sapere quando è meglio cercare di coprire un elenco limitato di casi o creare un sistema generico per coprire tutte le possibilità?
Per prima cosa, passi il sale. Poi passi il pepe. Quindi si passa il parmigiano grattugiato. A questo punto, hai abbastanza esperienza per iniziare a sviluppare un sistema generale di passaggio del condimento.
Funziona in progetti software allo stesso modo: usa sistemi di scopo speciale che sviluppi come passi di apprendimento verso quelli generalizzati, quindi quando è il momento di avviare il tuo sistema per scopi generali, hai una maggiore fiducia in ciò che sei edificio, perché hai diversi sistemi speciali sotto la cintura.
How do I know when it's best to try and cover a finite list of cases, or make a generic system to cover all possibilities?
Experience.
L'unico modo per sapere è aver provato prima un percorso, visto come ti ha morso nel culo (o hai perso un sacco di tempo). Ripeti finché non ti viene dato un po 'di meno.
Anche allora, non lo sai sapere ; hai solo una ipotesi migliore.
Per sfruttare le risposte di dasblinkenlight e Paddy3118 , se non hai più casi da implementare, non devi generalizzare! La ragione per cui il cartone animato XKCD è divertente è che emette generalizzazione prematura . Dopo essere stato invitato a passare il sale, il personaggio invisibile balza immediatamente a "sviluppare un sistema per passare condimenti arbitrari" quando tutto il primo personaggio richiesto era il sale. Questo è un buon scherzo per gli sviluppatori, dal momento che penso che tutti abbiamo visto casi di generalizzazione prematura.
Il principio opposto alla generalizzazione prematura è YAGNI (Non ne avrò bisogno). Ci sono molti materiali a riguardo disponibili sul web, ma fondamentalmente YAGNI sottolinea una serie di rischi nella generalizzazione senza il beneficio di diversi casi d'uso reali a portata di mano, compresa la possibilità che potrebbero non comparire effettivamente più casi d'uso. Oppure, in modo più sottile, la mancanza di casi d'uso reali richiede di formulare ipotesi su ciò che è necessario in futuro. Queste ipotesi possono essere, e spesso sono, errate.
Sembra più facile essere generici nel piccolo, cioè non creare una classe per gestire una tabella di ricerca che mappa gli interi in stringhe quando puoi creare una classe di dizionario ragionevole che gestisce qualsiasi coppia di tipi (dove il primo tipo supporta alcuni tipi di confronto).
In una vita precedente ho realizzato molti progetti di automazione industriale per macchinari che gestivano una rete continua di materiale. Acciaio, alluminio, carta, plastica, .... Lo srotoli ad una estremità e lo arrotoli di nuovo all'altro dopo aver fatto qualcosa di utile nel mezzo. In un settore inizi al "payoff reel", non allo "unwinder". Se usi la terminologia sbagliata, sei un idiota negli occhi da molti milioni di dollari del cliente. Sareste stupiti di quanto poco possa essere astratto da riutilizzare da un progetto all'altro. OTOH, si potrebbe spesso creare una struttura o un modello come punto di partenza. Sarebbe stato personalizzato per il lavoro da svolgere, ma almeno aveva il vantaggio di apprendere da progetti precedenti. E tutti nel team sapevano da dove stavamo iniziando.
Fallo una volta, fallo due volte, fallo tre volte, generalizza.
Uno, due, molti!
Nel secondo caso dovresti pensare alla generalizzazione. Quando ti viene chiesto il terzo devi fornirlo dal codice generalizzato e utilizzare il primo e il secondo caso precedentemente risolti individualmente come casi di test.
Leggi altre domande sui tag algorithms problem-solving