Quando preferire una soluzione generalizzata rispetto alla risoluzione di casi specifici

Nella programmazione ci troviamo spesso di fronte a una scelta: coprire ogni caso d'uso concepibile individualmente o risolvere il problema generale:

È ovvio che risolvere il problema immediato è più veloce, tuttavia la creazione di una soluzione generalizzata farà risparmiare tempo in futuro.

Come faccio a sapere quando è meglio provare a coprire un elenco finito di casi o creare un sistema generico per coprire tutte le possibilità?

Per prima cosa, passi il sale. Quindi 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 nei progetti software allo stesso modo: usa sistemi di scopo speciali che sviluppi come passi di apprendimento verso quelli generalizzati, quindi quando è il momento di avviare il tuo sistema di scopi generali, hai una maggiore fiducia in ciò che stai costruendo, perché hai diversi sistemi speciali sotto la cintura.

Come faccio a sapere quando è meglio provare a coprire un elenco finito di casi o creare un sistema generico per coprire tutte le possibilità?

Esperienza.

L'unico modo per sapere è aver provato un percorso prima, visto come ti ha morso nel culo (o hai perso un sacco di tempo). Ripeti fino a quando non diventi un po 'meno nel culo.

Anche allora, non lo sai davvero ; hai solo una supposizione migliore.

Per sfruttare le risposte di dasblinkenlight e Paddy3118 , se non hai più casi da implementare, non è necessario generalizzare! Il motivo per cui il cartone animato XKCD è divertente è che si diffonde una generalizzazione prematura . Dopo essere stato invitato a passare il sale, il personaggio invisibile salta immediatamente allo "sviluppo di un sistema per passare condimenti arbitrari" quando tutto il primo personaggio richiesto era il sale. Questa è una buona battuta per gli sviluppatori, dal momento che penso che tutti abbiamo visto casi di generalizzazione prematura.

Il principio opposto alla generalizzazione prematura è YAGNI (Non ne avrai bisogno). Ci sono molti materiali su questo disponibili sul web, ma fondamentalmente YAGNI evidenzia una serie di rischi nel generalizzare senza il beneficio di diversi casi d'uso attuali, inclusa la possibilità che più casi d'uso potrebbero effettivamente non apparire. O, più sottilmente, la mancanza di casi d'uso reali richiede di fare ipotesi su ciò che è necessario in futuro. Queste ipotesi possono essere e spesso sono errate.

Sembra più semplice essere generici nel piccolo, cioè non creare una classe per gestire una tabella di ricerca che associa numeri interi alle stringhe quando è possibile creare una classe di dizionario ragionevole che gestisca qualsiasi coppia di tipi (dove il primo tipo supporta un tipo di confronto).

In una vita precedente ho realizzato molti progetti di automazione industriale per macchinari che gestivano una rete continua di materiali. Acciaio, alluminio, carta, plastica, .... Lo srotoli da un lato e lo arrotoli di nuovo dall'altro dopo aver fatto qualcosa di utile nel mezzo. In un settore si inizia dal "payoff reel", non dal "svolgitore". Se usi una terminologia sbagliata, sei un idiota agli occhi del multimilionario del cliente. Sareste sorpresi di quanto poco possa essere sottratto per essere riutilizzato da un progetto all'altro. OTOH, si potrebbe spesso creare un framework o un modello come punto di partenza. Sarebbe personalizzato per il lavoro da svolgere, ma almeno avrebbe avuto il vantaggio di apprendere da progetti precedenti. E tutti nel team sapevano da dove stavamo partendo.

Fallo una volta, fallo due volte, fallo tre volte, generalizza.

Uno, due, molti!

Nel secondo caso dovresti pensare alla generalizzazione. Quando viene richiesto il terzo, è necessario fornirlo dal codice generalizzato e utilizzare il primo e il secondo caso precedentemente risolti singolarmente come casi di test.