Dovrei preoccuparmi se risolvo molti dei miei problemi allo stesso modo?

Mi piace molto programmare giochi e creatori / giochi puzzle. Mi trovo a progettare molti di questi problemi allo stesso modo e alla fine utilizzo una tecnica simile per programmarli con cui mi sento davvero a mio agio.

Per darti una breve panoramica, mi piace creare grafici in cui i nodi sono rappresentati con oggetti. Questi oggetti contengono dati come coordinate, posizioni e ovviamente riferimenti ad altri oggetti vicini. Li inserirò tutti in una struttura di dati e prenderò decisioni su queste informazioni in un "loop di gioco".

Mentre questo è un breve esempio, non è esatto in tutte le situazioni. È solo un modo in cui mi sento davvero a mio agio. È male?

No, va bene.

Il punto della programmazione pratica è trovare soluzioni che potrebbero essere utili in molti sviluppi simili. Ne hai appena trovato uno.

Non puoi e non dovresti creare soluzioni diverse solo per il fatto che sono diverse. Ma dovresti assolutamente dare un'occhiata critica alle tue soluzioni ogni volta e chiederti se sono ancora buone o forse il settore è progredito da allora e devi allinearti di conseguenza.

Se funziona bene, chiamalo un modello di progettazione. In caso contrario, ma non sai meglio, è l'antipasto martello d'oro.

Realisticamente nei nostri lavori di oggi tendiamo a porre un discreto numero di problemi abbastanza simili.

In queste situazioni attenersi a ciò che sai può essere buono. Ho visto più esempi di soluzioni sbagliate da parte di persone che implementano qualcosa che non capiscono che qualcuno usa bene una tecnica non ideale.

Se conosci bene qualcosa, è probabile che tu possa fletterlo secondo necessità e che la tua implementazione sarà solida ed efficace. Queste cose probabilmente non saranno vere dai tuoi primi tentativi di nuove tecniche.

Ma il rovescio della medaglia è che se tutto ciò che hai è un martello, tutto sembra un chiodo. Dovresti fare delle cose per renderti consapevole delle alternative e quando forse stai spingendo troppo i tuoi preferiti.

Forse scegli alcune modifiche non urgenti / non critiche e utilizzarle per aggiornarti con soluzioni alternative?

Bella domanda, e devo ammettere che anche questo mi perseguita.

Quando va bene? Esegui un'analisi delle prestazioni del tuo codice - se vedi che sei in O (log n) o O (n) o O (n log n) e come tale il problema è riconducibile a strutture di dati conosciute, di solito stai bene.

Quando non va bene? La complessità del tempo o dello spazio è O (n ^ 2) o peggiore, oppure il problema per definizione è NP completo. In queste situazioni è necessario applicare una buona dose di euristica, applicare le conoscenze di altri domini, ecc.

Esempio rapido: nella progettazione di chip, la scelta di come disporre le porte nel circuito per una potenza minima è NP-completa. Solo i grafici da soli non ti faranno molto bene, anche se è un must. Devi leggere materiale aggiuntivo, molto interdisciplinare a volte e applicare le conoscenze nel tuo dominio. Ad esempio, gli algoritmi genetici (algoritmi che imitano i crossover genetici e le mutazioni, come definiti nella biologia 101) hanno molte applicazioni nella progettazione di chip hardware.

Non necessariamente, se è un buon modo di risolverli :)

Di solito quando lavoro su una "soluzione", vado per queste cose in ordine:

• semplicità ,
• riusabilità ,
• e solo l'ultima esibizione .

Non importa che le prestazioni non contino: progetto con le prestazioni in mente, ma senza spingerle troppo lontano (quindi se devo fare chiamate a un metodo di utilità come StringUtils.isEmpty o qualcosa del genere nello stesso flusso, ho vinto ' non importa). Se sono necessarie prestazioni (caso aziendale o problema dell'esperienza utente), scelgo un approccio diverso da quello semplice e riutilizzabile. Essere pragmatici.

Stranamente, quando scrivo in C, mi preoccupo molto di più delle prestazioni rispetto a quando scrivo in Java ... Force of habit :))

Finché il problema viene risolto in modo efficiente, non è necessario preoccuparsi.

Penso che il grafico sia un design adatto per la progettazione di giochi per rappresentare decisioni / scelte. Tieni presente che probabilmente questo può essere perfezionato e reso più efficiente e questa potrebbe non essere la soluzione migliore per altri domini.

Se funziona, va bene.

Se ti preoccupi di scavalcare una sola tecnica, prova come esercizio per trovare variazioni di alcuni problemi risolti che renderebbero la tua soluzione inattuabile. Punti extra se è possibile generalizzare le modifiche per definire lo spazio di applicabilità del normale processo.

Se risolvi il problema, va bene. E non importa in che modo fino a quando non crea più problemi.

"Developer Art" in realtà ha la risposta corretta se il tuo obiettivo è quello di produrre un prodotto. E se la tua "fabbrica" ​​produce i prodotti che soddisfano, allora cool.

Ma...

Se mai vuoi imparare nuovi (e potenzialmente migliori) modi di fare le cose, devi cambiare le cose. Questo produrrà fallimenti, ma solo attraverso il fallimento si può effettivamente imparare. E attraverso questo nuovo apprendimento potresti essere in grado di produrre software ancora migliore e più avvincente.

Questo è in realtà supportato dalla ricerca neurologica. Quindi eccoti.