Codice leggibile pulito vs codice veloce da leggere. Quando attraversare la linea?

Quando scrivo codice cerco sempre di rendere il mio codice il più pulito e leggibile possibile.

Ogni tanto arriva un momento in cui è necessario attraversare la linea e passare da un bel codice pulito a un codice leggermente più brutto per renderlo più veloce.

Quando è corretto attraversare quella linea?

Quando attraversi la linea

• Hai misurato che il tuo codice è troppo lento per l'uso previsto .
• Hai provato miglioramenti alternativi che non richiedono l'archiviazione del codice.

Ecco un esempio reale: un sistema sperimentale che sto eseguendo stava producendo dati troppo lentamente, impiegando oltre 9 ore per corsa e usando solo il 40% della CPU. Invece di rovinare troppo il codice, ho spostato tutti i file temporanei in un filesystem in memoria. Aggiunte 8 nuove righe di codice non brutto e ora l'utilizzo della CPU è superiore al 98%. Problema risolto; nessuna bruttezza richiesta.

È una falsa dicotomia. Puoi rendere il codice veloce e facile da mantenere.

Il modo in cui lo fai è scriverlo pulito, soprattutto con una struttura di dati il ​​più semplice possibile.

Quindi scopri dove sono gli scarichi di tempo (eseguendolo, dopo averlo scritto, non prima) e risolverli uno per uno. (Ecco un esempio.)

Aggiunto: sentiamo sempre dei compromessi, giusto, come un compromesso tra tempo e memoria o un compromesso tra velocità e manutenibilità? Sebbene tali curve possano benissimo esistere, non si deve presumere che un determinato programma si trovi sulla curva , o anche in nessun posto vicino ad essa.

Qualsiasi programma che si trova sulla curva può facilmente (dandolo a un certo tipo di programmatore) essere reso sia molto più lento, sia molto meno gestibile, e quindi non si troverà da nessuna parte vicino alla curva. Tale programma ha quindi molto spazio per essere reso più veloce e più mantenibile.

Nella mia esperienza, è lì che iniziano molti programmi.

Nella mia esistenza OSS, svolgo molte attività di biblioteca mirate alla performance, che sono profondamente legate alla struttura dei dati del chiamante (cioè esterna alla biblioteca), senza (in base alla progettazione) nessun mandato sui tipi in arrivo. Qui, il modo migliore per rendere questo performer è la meta-programmazione, che (dato che sono in .NET-land) significa IL-emit. Questo è un codice brutto, brutto, ma molto veloce.

In questo modo, accetto felicemente che il codice della libreria possa essere "più brutto" del codice dell'applicazione , semplicemente perché ha un controllo minore (o forse no) sugli input , quindi è necessario eseguire alcune attività attraverso meccanismi diversi. O come l'ho espresso l'altro giorno:

"codifica sulla scogliera della follia, quindi non devi "

Ora il codice dell'applicazione è leggermente diverso, in quanto è qui che gli sviluppatori "normali" (in genere) investono in gran parte del loro tempo collaborativo / professionale; gli obiettivi e le aspettative di ciascuno sono (IMO) leggermente diversi.

IMO, le risposte sopra che suggeriscono che può essere veloce e facile da mantenere si riferiscono al codice dell'applicazione in cui lo sviluppatore ha un maggiore controllo sulle strutture di dati e non utilizza strumenti come la meta-programmazione. Detto questo, ci sono diversi modi di fare meta-programmazione, con diversi livelli di follia e diversi livelli di sovraccarico. Anche in quell'arena devi scegliere il livello appropriato di astrazione. Ma quando si desidera attivamente, positivamente, sinceramente che gestisca i dati imprevisti nel modo più rapido assoluto; potrebbe diventare brutto. Affrontalo; p

Quando hai profilato il codice e verificato che sta effettivamente causando un significativo rallentamento.

Il codice pulito non è necessariamente esclusivo con il codice ad esecuzione rapida. Il codice normalmente difficile da leggere è stato scritto perché era più veloce da scrivere, non perché viene eseguito più velocemente.

Scrivere codice "sporco" nel tentativo di renderlo più veloce è probabilmente poco saggio, dal momento che non si sa con certezza che le modifiche apportate migliorano effettivamente qualsiasi cosa. Knuth l'ha detto meglio:

"Dovremmo dimenticare le piccole efficienze, diciamo circa il 97% delle volte: l'ottimizzazione prematura è la radice di tutti i mali . Tuttavia non dovremmo cedere le nostre opportunità in quel 3% critico. Un buon programmatore non sarà cullato dall'accompagnamento da ragionando, sarà saggio esaminare attentamente il codice critico, ma solo dopo che questo codice sarà stato identificato ".

In altre parole, scrivi prima il codice. Quindi, profilare il programma risultante e vedere se quel segmento è, in effetti, un collo di bottiglia delle prestazioni. In tal caso, ottimizza la sezione se necessario e assicurati di includere molti commenti sulla documentazione (possibilmente includendo il codice originale) per spiegare le ottimizzazioni. Quindi profilare il risultato per verificare che sia stato effettivamente apportato un miglioramento.

Poiché la domanda dice " codice veloce da leggere ", la risposta semplice non è mai. Non c'è mai una scusa per scrivere codice difficile da leggere. Perché? Due ragioni.

1. Cosa succede se sei investito da un autobus sulla strada di casa stasera? O (più ottimisticamente e più tipicamente) decollato da questo progetto e riassegnato a qualcos'altro? Il piccolo vantaggio che immagini di aver fatto con il tuo groviglio di codice è totalmente compensato dal fatto che nessun altro può capirlo . Il rischio che ciò comporta per i progetti software è difficile da sopravvalutare. Ho lavorato una volta con un importante PBXproduttore (se lavori in un ufficio probabilmente hai uno dei suoi telefoni sulla scrivania). Il loro project manager mi ha detto un giorno che il loro prodotto principale - il software proprietario che ha trasformato una normale scatola Linux in un centralino telefonico completo - era noto all'interno dell'azienda come "il blob". Nessuno lo capiva più. Ogni volta che hanno implementato una nuova funzionalità. colpivano la compilazione, poi stavano indietro, chiudevano gli occhi, contavano fino a venti, poi sbirciavano tra le dita per vedere se funzionava. Nessuna azienda ha bisogno di un prodotto principale che non controlla più, ma è uno scenario spaventosamente comune.
2. Ma devo ottimizzare! OK, quindi hai seguito tutti i consigli eccellenti in altre risposte a questa domanda: il tuo codice non sta superando i suoi casi di test delle prestazioni, lo hai profilato con attenzione, identificato i colli di bottiglia, trovato una soluzione ... e sta per coinvolgere qualche bit-twiddling . Bene: ora vai avanti e ottimizza. Ma ecco il segreto (e potresti voler sederti per questo): l' ottimizzazione e la riduzione delle dimensioni del codice sorgente non sono la stessa cosa. Commenti, spazi bianchi, parentesi e nomi di variabili significativi sono tutti enormi aiuti per la leggibilità che non ti costano assolutamente nulla perché il compilatore li getterà via. (O se stai scrivendo un linguaggio non compilato come JavaScript - e sì, ci sono ragioni molto valide per ottimizzare JavaScript - possono essere gestiti da un compressore .) Lunghe righe di codice ristretto e minimalista (come quello che ha muntoo pubblicato qui ) non hanno nulla a che fare con l'ottimizzazione: è un programmatore che cerca di mostrare quanto sono intelligenti impacchettando il maggior numero di codice nel minor numero possibile di caratteri. Non è intelligente, è stupido. Un programmatore veramente intelligente è colui che può comunicare chiaramente le proprie idee agli altri.

Quando è un codice usa e getta. Voglio dire letteralmente: quando scrivi uno script per eseguire un calcolo o un'attività una tantum, e sai con tale certezza che non dovrai mai più fare quell'azione che puoi 'rm source-file' senza esitazione, quindi puoi scegliere la brutta via.

Altrimenti è una falsa dicotomia - se pensi di aver bisogno di renderlo brutto per farlo più velocemente, stai sbagliando. (O i tuoi principi su ciò che è un buon codice devono essere rivisti. L'uso di goto è in effetti piuttosto elegante quando è la soluzione corretta al problema. Raramente lo è comunque.)

Ogni volta che il costo stimato di prestazioni inferiori sul mercato è superiore al costo stimato della manutenzione del codice per il modulo di codice in questione.

Le persone continuano a intrecciare SSE / NEON / etc codificato a mano. assemblaggio per provare a battere alcuni software della concorrenza sul popolare chip della CPU di quest'anno.

Non dimenticare che puoi rendere il codice difficile da leggere con la documentazione e i commenti appropriati.

In generale, profilo dopo aver scritto il codice di facile lettura che svolge la funzione desiderata. I colli di bottiglia potrebbero richiedere di fare qualcosa che lo rende più complicato, ma lo risolvi spiegando te stesso.

Per me è una proporzione di stabilità (come nel cemento cementato, nell'argilla cotta nel forno, incastonata nella pietra, scritta con inchiostro permanente). Più instabile è il tuo codice, poiché maggiore è la probabilità che tu debba modificarlo in futuro, più facilmente deve essere flessibile, come l'argilla bagnata, per rimanere produttivo. Sottolineo anche la flessibilità e non la leggibilità. Per me la facilità di modificare il codice è più importante della facilità di leggerlo. Il codice può essere facile da leggere e un incubo da cambiare, e a che serve leggere e comprendere facilmente i dettagli dell'implementazione se sono un incubo da cambiare? A meno che non sia solo un esercizio accademico, in genere il punto di essere in grado di comprendere facilmente il codice in una base di codice di produzione è con l'intento di essere in grado di cambiarlo più facilmente secondo necessità. Se è difficile cambiare, quindi molti dei vantaggi della leggibilità escono dalla finestra. La leggibilità è generalmente utile solo nel contesto della flessibilità e la flessibilità è utile solo nel contesto dell'instabilità.

Naturalmente anche il codice più difficile da mantenere immaginabile, indipendentemente da quanto sia facile o difficile da leggere, non rappresenta un problema se non c'è mai un motivo per cambiarlo, solo usarlo. Ed è possibile ottenere tale qualità, soprattutto per il codice di sistema di basso livello in cui le prestazioni tendono spesso a contare di più. Ho un codice C che uso ancora regolarmente, che non è cambiato dalla fine degli anni '80. Da allora non ha dovuto cambiare. Il codice è fugace, scritto nei giorni difficili, e lo capisco a malapena. Eppure è ancora applicabile oggi, e non ho bisogno di comprenderne l'implementazione per trarne grande utilità.

Scrivere a fondo i test è un modo per migliorare la stabilità. Un altro è il disaccoppiamento. Se il tuo codice non dipende da nient'altro, l'unica ragione per cui cambia è se, di per sé, deve cambiare. A volte una piccola quantità di duplicazione del codice può fungere da meccanismo di disaccoppiamento per migliorare notevolmente la stabilità in un modo che lo rende un degno compromesso se, in cambio, si ottiene un codice che ora è completamente indipendente da qualsiasi altra cosa. Ora quel codice è invulnerabile alle modifiche al mondo esterno. Nel frattempo il codice che dipende da 10 diverse librerie esterne ha 10 volte la ragione per cui cambierà in futuro.

Un'altra cosa utile in pratica è quella di separare la tua libreria dalle parti instabili della tua base di codice, possibilmente anche costruendola separatamente, come potresti fare per le librerie di terze parti (che allo stesso modo dovrebbero essere usate, non modificate, almeno non dal tuo squadra). Proprio quel tipo di organizzazione può impedire alle persone di manometterlo.

Un altro è il minimalismo. Meno il codice tenta di fare, più è probabile che possa fare ciò che fa bene. I progetti monolitici sono quasi permanentemente instabili, poiché più funzionalità vengono aggiunte a loro, tanto più sembrano incomplete.

La stabilità dovrebbe essere il tuo obiettivo principale ogni volta che miri a scrivere un codice che sarà inevitabilmente difficile da modificare, come il codice SIMD parallelizzato che è stato messo a punto con il micro-tuning. Contrastare la difficoltà di mantenere il codice massimizzando la probabilità che non si debba cambiare il codice e quindi non sarà necessario mantenerlo in futuro. Ciò porta a zero i costi di manutenzione, non importa quanto sia difficile mantenere il codice.