Soluzione tecnica Specialized VS Specialized; cosa prendere in considerazione?

Come al solito, la risposta è: dipende. Ci sono molti problemi da considerare, tra cui:

• prima di tutto, ciò che il cliente vuole ed è disposto a pagare per
• la differenza nell'implementazione e nei costi e rischi di manutenzione tra le soluzioni alternative
• la durata prevista del prodotto
• l'ambito previsto delle modifiche future (ovvero è ragionevolmente previsto che la soluzione più generale sarà effettivamente utilizzata nel prossimo futuro?)

Se la soluzione più generale è facile da implementare, con costi aggiuntivi minimi e zero rischi, potrebbe essere una buona idea farlo, anche se non ce n'è bisogno. OTOH se la soluzione generale è significativamente più costosa, hai bisogno di una giustificazione sufficientemente strong (= valore aggiunto per il cliente), altrimenti ti ritrovi con generalità speculativa .

Dovresti sempre tenere a mente che una soluzione più generale di solito (anche se non sempre!) significa codice più complesso, che è quindi più difficile da capire e modificare a lungo termine. Quindi il costo di implementazione non è l'unico fattore da prendere in considerazione. I costi di manutenzione per un prodotto con un lungo ciclo di vita superano i costi di sviluppo. OTOH per un prodotto destinato a essere utilizzato solo una volta o per un breve periodo, ovviamente renderlo più generico potrebbe essere inutile. (Anche se dovremmo essere consapevoli che la durata effettiva del software è spesso significativamente più lunga di quanto inizialmente previsto.)

E il caso "non sempre" menzionato sopra include anche casi in cui un'attenta analisi del problema rivela che si tratta di una sottocategoria o di una visione diversa di qualche problema più generale e noto per il quale esistono soluzioni note, oppure la soluzione è significativamente più facile da implementare. In questi casi, l'ulteriore sforzo di analisi e progettazione è più che redditizio in un codice più semplice e più pulito, che può anche essere più veloce e / o meno affamato di risorse. Questi casi sono l'eccezione, piuttosto che la regola, ma vale comunque la pena menzionarli.

Aggiornamento

Un altro aspetto che ho dimenticato di menzionare è il costo potenziale di rendere la soluzione più generale in futuro. Spesso non è significativamente più costoso rifattorizzare il codice più tardi che renderlo generale ora - il che suggerisce di rinviare la decisione il più tardi possibile. L'economia di tali decisioni sta risparmiando 100 dollari ora, con il rischio che nel peggiore dei casi, dovrai pagare 110 dollari qualche anno più tardi (ma hai investito 100 dollari e probabilmente ti ha guadagnato di più), ma nel migliore dei casi non si paga nulla.

Tuttavia, vi è (almeno) un'area in cui il refactoring successivamente è significativamente più costoso, più rischioso e più difficile rispetto alla progettazione di una soluzione generale fin dall'inizio: i database. Cambiare la struttura della tabella e migrare enormi quantità di dati business-critical in una nuova struttura è tutt'altro che banale, anche in casi più semplici, e talvolta può essere addirittura impossibile. Pertanto, quando si progetta uno schema DB, è logico optare per la soluzione più generale, che può includere una gamma più ampia di potenziali estensioni future.

Per iniziare bene la lettura, consulta questo elenco di Wikipedia . Idealmente, stai esaminando separazione dei dubbi . Mentre una soluzione più generale presenta vantaggi per il riutilizzo tra i progetti, c'è un problema.

Il database riguarda la memorizzazione dei dati e quindi è compito del database sapere quali sono i dati. Non vuoi una tabella in grado di memorizzare qualcosa con un campo che contiene i dati e uno che contiene la descrizione.

Seguirò la regola di rappresentanza . I dati devono dire di cosa si tratta, oppure è inutile. Solo se i dati sono effettivamente generali dovrebbero essere trattati come generali.

Infine, peggio è meglio . Non hai intenzione di sapere tutto su come generalizzare la soluzione quando la crei per la prima volta. Non sai cosa è effettivamente richiesto, quindi costruire una soluzione che cerchi di farlo è molto più utile solo per un guadagno marginale.

In definitiva, la mia risposta è simile a quella di Péter Török, in quanto ritengo che dipenda dallo sforzo e dalla complessità aggiuntivi di implementazione della soluzione generalizzata.

Inquadrare questo come un argomento implementaiton è un errore, e etichettare i due opposti programmando il linguaggio e definendolo nel modo in cui pensano sia pericolosamente vicino alla creazione dello stereotipo dello sviluppatore logico e prospettico di Ruby contro il trollish, sviluppatore Java testardo e folle.

Questa non dovrebbe essere una discussione tecnica su come soddisfare i bisogni del cliente con l'ulteriore aspettativa che i clienti non sanno quasi mai cosa vogliono e cambiano opinione frequentemente, e si aspettano anche che quando cambiano idea hanno vinto Il risultato è un grande sforzo di refactoring. Questo problema non riguarda tanto la separazione delle preoccupazioni (che è importante per i suoi meriti) nella mia mente, ma quella dell'interpretazione realistica della realtà.

Se sto modellando un'interpretazione rigorosa del Calendario Maya e lo sto progettando e implementandolo rigorosamente, probabilmente ho ragione ad essere specifico nel mio progetto. Sono praticamente garantito che il calendario Maya non cambierà, specialmente visto come il popolo Maya non esiste più su questa Terra. D'altra parte, se sto progettando un sistema di gestione dei documenti e mi viene detto che i soli documenti che vogliono archiviare sono file JPEG, allora sono probabilmente intelligente a non progettare i miei tavoli intorno alle specificità delle immagini, perché quando lo demo, probabilmente realizzeranno che vogliono archiviare anche i PDF. Ho appena creato un sacco di lavoro in più per me stesso.

Questo non ha nulla a che fare con il linguaggio e tutto ciò che ha a che fare con la realtà nello sviluppo di software di requisiti aziendali in rapida evoluzione e di clienti deprimenti inaffidabili.