Le soluzioni iniziali inefficienti riescono a ISPIRARE quelle migliori e quindi a velocizzare la risoluzione dei problemi?

Sì ... a volte è necessario avere il tempo di farlo "sbagliato" (o vicino) per poterlo finalmente correggere. In generale, si arriva a una soluzione per la prima volta - POI fare ottimizzazione e miglioramenti del design. A volte capirai meglio il problema dopo aver passato un primo passaggio.

In generale, è necessario misurare "efficienza" e "prestazioni". Tuttavia, se stai creando un algoritmo, ci sono delle tecniche per determinare (o avere una buona idea) se sarà O (1), O (n), O (log n), O (n2) ecc.

A volte però creare un pezzo di codice funzionante aiuta a rompere qualsiasi "blocco" che potresti incontrare e potrebbe effettivamente portare ad altre e, si spera, soluzioni migliori.

Sicuramente.

Hai bisogno di disegnare esattamente quello che vuoi per capire cosa hai bisogno di costruire, e quello che vuoi non è sempre efficiente.

L'opposto è molto peggio - A partire da metodi efficienti e cercando di capire come convincerli a fare ciò che devi fare. Finisci con qualcosa che potrebbe essere veloce, ma non fa esattamente quello che vuoi. Oppure schiaffi su alcuni cerotti per fargli fare quello che vuoi e il codice si trasforma in un casino.

Costruisco costantemente qualcosa per cui funziona, refactoring per renderlo più programmabile (nessun codice copia / incolla, commenti, metodi di suddivisione, ecc.), quindi controllo le prestazioni per vedere se il codice deve essere raffinato a tutti.

Assolutamente e in due modi:

Il primo è che tu, applicando una soluzione approssimativa e non ideale, inizi a vedere esattamente dove e perché fallisce, che ti consente di indirizzare i tuoi sforzi su problemi reali piuttosto che su problemi che ritieni possano verificarsi.

Il secondo è che a volte vedrai queste soluzioni approssimative e non ideali implementate e funzionano bene e questa è una lezione preziosa. Non tutte le soluzioni devono essere perfettamente progettate, a volte ruvide e pronte fanno il lavoro e ti permettono di impiegare lo sforzo che avresti speso per la lucidatura inutile su qualcosa che farà davvero la differenza.

Personalmente ho sofferto per lo meno con il codice sopra ingegnerizzato che mirava a risolvere problemi o affrontare situazioni che non si presentavano mai di quelle che avevo a che fare con soluzioni veloci e sporche che non erano flessibili ed eleganti.

TL; DR: funziona e funziona bene, e chi sono gli standard che incontri?

Devi considerarlo come se il tuo codice sia inefficiente fino al punto di non essere pratico. Stai nidificando per loop e passa le istruzioni 5 in profondità, o è qualcosa di semplice come "whoops, usa una matrice invece di una tabella hash?"

Inoltre, ulteriori domande, perché so che lo faccio, sono i tuoi standard a cui tieni il tuo codice, oppure è uno standard pubblicato o standard aziendale che stai cercando di incontrare. Sì, è bello se il tuo codice viene eseguito in tempo O (nlogn), ma occupa più linee di quelle che la tua azienda vuole che il codice prenda, o magari funzioni in quel momento, ma è totalmente non-mantenibile. Ci sono un gran numero di "standard" che possono essere soddisfatti oltre all'efficienza, e quelli a cui è necessario tener conto.

Determore sempre la migliore complessità teorica asintotica prima di scrivere qualsiasi codice. Poi prendo una decisione consapevole se voglio mirare o no. Se i tuoi dati sono finiti, come per esempio, un elenco di paesi, puoi usare O (n) o anche O (n ² ) invece di un algoritmo O (1) e non notare mai. In tal caso, la mia considerazione principale può essere la manutenibilità invece dell'efficienza.

Non riscrivo quasi mai per l'efficienza a meno che uno sviluppatore precedente non abbia fatto una scelta decisamente sbagliata. Riscrivo sempre la mia prima bozza per la manutenibilità.

Il codice che funziona ora è molto meglio di un codice inedito che potrebbe funzionare più velocemente in futuro. Ovviamente i bravi programmatori pianificano in anticipo ed evitano le brutte situazioni di O (N ^ 2), ma ecco il mio punto principale: ottimizzare prima di misurare è male.

Nulla ispira la scrittura del codice in un modo "migliore" rispetto all'esecuzione di codice da misurare e nel frattempo il codice è in esecuzione.