Scegliere tra prestazioni rispetto a codice leggibile / più pulito? [chiuso]

In parole semplici:

• Rendere il codice brutto non lo rende veloce.
• Rendere il codice pulito non lo rende lento (o veloce).
• Rendere il codice brutto rende più lento il lavoro del maintainer
• Pulisci codice di solito significa che il codice è stato creato da qualcuno a cui interessa.
• Chi si preoccupa di rendere il suo codice pulito, di solito si preoccupa di renderlo efficiente.
• L'hardware diventa più economico con il tempo.
• I programmatori non diventano più economici nel tempo.
• Il tempo di CPU è più economico del tempo del programmatore.
• Alcuni problemi di prestazioni possono essere risolti con il lancio di denaro.
• Pochissimi problemi di manutenzione del codice possono essere risolti con il lancio di denaro.

Devi sempre scegliere il codice pulito in primo luogo in quanto riduce i costi di manutenzione ed è probabile che sia meno complesso. Non dovresti affrontare un problema di prestazioni che non hai identificato; probabilmente è un'ottimizzazione prematura.

Vedi When is Optimization Premature?

L'idea generale è di rendere il codice il più leggibile possibile prima, e quindi di guardare solo all'ottimizzazione dove c'è un problema prestazionale comprovato. Nella maggior parte dei casi, un tempo di risposta di, ad es. 5 ms invece di 1 ms non faranno la differenza. 50 secondi invece di 10 secondi è una questione diversa.

Preferisci soddisfare i requisiti dei tuoi clienti.

Se il cliente ha imposto un requisito di prestazioni e tale requisito impone di modificare il codice per renderlo meno leggibile ma più performante, allora si modifica il codice per renderlo meno leggibile ma più performante.

Ma il brutto codice veloce è una falsa dicotomia. A volte puoi migliorare il rendimento del codice senza renderlo decisamente più brutto.

Se il codice funziona già in modo adeguato, preferisci la leggibilità su più prestazioni.

Misura prima, poi ottimizza i bit lenti solo se devi farlo per soddisfare i requisiti.