Dovrei essere preoccupato se risolvo molti dei miei problemi allo stesso modo?

No, va bene.

Il punto della programmazione pratica è trovare soluzioni che possano essere utili in molti sviluppi simili. Hai appena trovato uno.

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

Se funziona bene, chiamalo schema di progettazione. Se non lo fa, ma non lo sai meglio, è l'antipattern del martello d'oro.

Realisticamente nei nostri giorni di lavoro tendiamo a ottenere un buon numero di problemi piuttosto 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 hanno capito che qualcuno stia usando una tecnica non ideale.

Se sai qualcosa di buono, è probabile che puoi fletterlo secondo necessità e che la tua implementazione sarà solida ed efficace. Quelle cose probabilmente non saranno vere dai tuoi primi tentativi di nuove tecniche.

Ma il rovescio della medaglia è che se tutto quello che hai è un martello, tutto sembra un chiodo. Dovresti fare qualcosa per rendersi conto delle alternative e quando stai spingendo troppo i tuoi preferiti.

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

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

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 in quanto tale il problema è mappabile a strutture di dati conosciute, generalmente stai bene.

Quando non va bene? La complessità del tuo tempo o spazio è O (n ^ 2) o peggio, oppure il problema per definizione è NP completo. In queste situazioni è necessario applicare un buon numero di euristiche, applicare le conoscenze di altri domini ecc.

Esempio rapido: nella progettazione dei chip, scegliere come organizzare le porte nel circuito per potenza minima è NP-completo. Solo i grafici da soli non ti faranno molto bene, anche se è un bisogno imprescindibile. È necessario leggere materiale aggiuntivo, in molti casi interdisciplinare e applicare le conoscenze nel proprio dominio. Ad es. algoritmi genetici (algoritmi che imitano crossover e mutazione genetici, come definiti in biologia 101) hanno un sacco di applicazioni nella progettazione di chip hardware.

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

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

• semplicità ,
• riusabilità ,
• e solo l'ultimo rendimento .

Non che le prestazioni non siano importanti: progetto pensando alle prestazioni, ma senza spingerlo troppo lontano (quindi se devo fare delle chiamate a un metodo di utilità come StringUtils.isEmpty o qualcosa del genere nello stesso flusso, Non mi dispiacerebbe). Se le prestazioni sono allora necessarie (caso aziendale o problema di esperienza utente), allora ho un approccio diverso da quello semplice e riutilizzabile. Essere pragmatici.

Stranamente però, quando si scrive in C, mi interessa molto di più sulle prestazioni rispetto a quando si scrive in Java ... Forza dell'abitudine:))

Finché il problema viene risolto in modo efficiente, non c'è motivo di preoccuparsi.

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

Se funziona, va bene.

Se ti preoccupi di sovrascrivere su una singola tecnica, prova come esercizio per trovare varianti di alcuni problemi risolti che renderebbero impraticabile la tua soluzione. Punti extra se puoi generalizzare le modifiche per definire lo spazio di applicabilità del tuo solito processo.

Se risolvi il problema, va bene. E non importa in che modo finché non crei più problemi.

"Arte dello sviluppatore" ha in realtà la risposta corretta se il tuo obiettivo è quello di produrre un prodotto. E se la tua "fabbrica" produce i prodotti che soddisfano quindi cool.

Ma ...

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

Questo è in realtà sostenuto da ricerche neurologiche. Quindi eccoci.