Come affrontare le idee sbagliate su "l'ottimizzazione prematura è la radice di tutti i mali"?

Ho incontrato molte persone che sono dogmaticamente contrarie a qualsiasi cosa possa essere considerata "ottimizzazione" nel senso generale della parola inglese, e molto spesso citano alla lettera la citazione (parziale) "l'ottimizzazione prematura è la radice di tutti i mali" come giustificazione per la loro posizione, sottintendendo che interpretano qualsiasi cosa di cui sto parlando sia "ottimizzazione prematura". Tuttavia, queste visioni a volte sono così ridicolmente radicate che respingono praticamente qualsiasi tipo di deviazione algoritmica o della struttura dei dati dalla più pura implementazione "ingenua" ... o almeno qualsiasi deviazione dal modo in cui hanno fatto le cose prima.Come si può avvicinare le persone in questo modo in modo da farle "riaprire le orecchie" dopo aver smesso di sentire "prestazioni" o "ottimizzazione"? Come posso discutere di un argomento di progettazione / implementazione che ha un impatto sulle prestazioni senza che le persone pensino all'istante: "Questo ragazzo vuole passare due settimane su dieci righe di codice?"

Ora, la posizione secondo cui "tutta l'ottimizzazione è prematura e quindi malvagia" è stata già discussa qui e in altri angoli del Web , ed è già stato discusso come riconoscere quando l'ottimizzazione è prematura e quindi malvagia , ma purtroppo ci sono ancora persone nel mondo reale che non sono altrettanto aperte alle sfide per la loro fiducia nell'antimottizzazione.

Tentativi precedenti

Alcune volte, ho provato a fornire la citazione completa di Donald Knuth per spiegare che "l'ottimizzazione prematura è cattiva" ↛ "tutta l'ottimizzazione è cattiva":

Dobbiamo dimenticare le piccole efficienze, diciamo circa il 97% delle volte: l'ottimizzazione prematura è la radice di tutti i mali. Tuttavia non dovremmo rinunciare alle nostre opportunità in quel 3% critico.

Tuttavia, quando si fornisce l'intero preventivo, queste persone a volte diventano più convinte che quello che sto facendo è Premature Optimization ™ e scavano e si rifiutano di ascoltare. È quasi come se la parola "ottimizzazione" li spaventasse: in un paio di occasioni, sono stato in grado di proporre cambiamenti di codice effettivi per migliorare le prestazioni senza che venissero posti il ​​veto semplicemente evitando l'uso della parola "optimiz (e | ation)" ( e anche "performance" - anche questa parola fa paura) e usa invece espressioni come "architettura alternativa" o "implementazione migliorata". Per questo motivo, sembra proprio che questo sia davvero dogmatismo e non loro che valutano in realtà ciò che dico in modo critico e poi lo respingono come non necessario e / o troppo costoso.

Sembra che tu stia cercando scorciatoie per non provare prima la "pura implementazione ingenua" e implementare direttamente una "soluzione più sofisticata perché sai in anticipo che l'implementazione ingenua non lo farà". Sfortunatamente, questo raramente funzionerà - quando non hai fatti concreti o argomenti tecnici per dimostrare che l'implementazione ingenua è o sarà troppo lenta, molto probabilmente sbagli e ciò che stai facendo è l'ottimizzazione prematura. E cercare di discutere con Knuth è l'opposto di avere un dato di fatto.

Nella mia esperienza, dovrai mordere il proiettile e provare prima "l'implementazione ingenua" (e probabilmente ti stupirai quanto spesso è abbastanza veloce), o almeno farai una stima approssimativa del tempo di esecuzione, come:

"L'implementazione ingenua sarà O (n³), e n è maggiore di 100.000; che verrà eseguito alcuni giorni, mentre l'implementazione non così ingenua verrà eseguita in O (n), che richiederà solo pochi minuti" .

Solo con tali argomenti a portata di mano puoi essere certo che la tua ottimizzazione non è prematura.

C'è una sola eccezione a IMHO : quando la soluzione più veloce è anche quella più semplice e pulita, allora dovresti usare la soluzione più veloce fin dall'inizio. L'esempio standard è quello di utilizzare un dizionario anziché un elenco per evitare inutili cicli di codice per le ricerche o l'uso di una buona query SQL che fornisce esattamente il record di risultati di cui hai bisogno, invece di un grande set di risultati che deve essere filtrato successivamente nel codice. Se hai un caso del genere, non discutere delle prestazioni- la performance potrebbe essere un vantaggio aggiuntivo, ma molto probabilmente irrilevante, e quando lo dici, le persone potrebbero essere tentate di usare Knuth contro di te. Discutere di leggibilità, codice più breve, codice più pulito, manutenibilità - non è necessario "mascherare" nulla qui, ma perché quelli (e solo quelli) sono gli argomenti corretti qui.

Secondo la mia esperienza, quest'ultimo caso è raro: il caso più tipico è quello di poter prima implementare una soluzione semplice, ingenua che sia meglio comprensibile e meno soggetta a errori rispetto a una più complicata, ma probabilmente più veloce.

E, naturalmente, dovresti conoscere i requisiti e il caso d'uso abbastanza bene da sapere quali prestazioni sono accettabili e quando le cose diventano "troppo lente" agli occhi dei tuoi utenti. In un mondo ideale, otterresti una specifica formale sulle prestazioni da parte del tuo cliente, ma nei progetti del mondo reale, le prestazioni richieste sono spesso un'area grigia, cosa che gli utenti ti diranno solo quando noteranno che il programma si comporta "troppo lentamente" in produzione. E spesso, questo è l'unico modo di scoprire quando qualcosa è troppo lento: il feedback degli utenti, e quindi non è necessario citare Knuth per convincere i tuoi compagni di squadra che la loro "ingenua implementazione" non era sufficiente.

Chiediti questo:

• Il software NON soddisfa le specifiche di prestazione?
• Il software ha un problema di prestazioni?

Questi sono motivi per ottimizzare. Quindi, se le persone si oppongono, mostra loro le specifiche e torna da loro e spiega che dobbiamo ottimizzare perché non stiamo soddisfando le specifiche. Oltre a ciò, ci sarebbe difficile convincere gli altri che l'ottimizzazione è necessaria.

Penso che il punto principale della citazione sia, se non si ha un problema, non eseguire inutili ottimizzazioni poiché il tempo e l'energia potrebbero essere spesi altrove. Dal punto di vista commerciale, questo ha perfettamente senso.

Secondario, per coloro che temono l'ottimizzazione, eseguire sempre il backup dei risultati delle prestazioni con metriche. Quanto è più veloce il codice? Quanto sono migliorate le prestazioni rispetto alle precedenti? Se uno passasse due settimane solo per migliorare il codice del 2% rispetto alla versione precedente, se fossi il tuo capo non sarei felice. Queste due settimane avrebbero potuto essere impiegate nell'implementazione di una nuova funzionalità in grado di attrarre più clienti e guadagnare di più.

Infine, la maggior parte dei software non deve essere altamente ottimizzata. Solo in alcuni settori specializzati la velocità è davvero importante. Quindi, il più delle volte si possono usare librerie e framework preesistenti con buoni risultati.

Come lavorare con persone che affrontano una discussione nel momento in cui ha a che fare con la performance?

Inizia con principi condivisi che si basano sulla direzione strategica del tuo gruppo.

I miei principi:

I miei principi personali sulla scrittura del codice mirano innanzitutto alla correttezza del mio programma, quindi a profilarlo e determinare se necessita di ottimizzazione. Profilo io stesso il mio codice perché altri programmatori sono potenziali consumatori del mio codice - e non lo useranno se è lento - quindi per il mio codice, la velocità è una caratteristica.

Se i tuoi consumatori sono clienti, i tuoi clienti ti diranno se hai bisogno di un codice più veloce.

Tuttavia, ci sono scelte conosciute, dimostrabilmente migliori nel codice che si possono fare. Preferirei inserirlo nella mia prima bozza per diversi motivi:

1. Se riesco a farlo bene la prima volta, allora posso dimenticare l'implementazione (sfruttando il nascondere le informazioni) e non ingombrare il mio codice con TODO.
2. Altri (in particolare quelli che imparano solo sul lavoro) lo vedono fatto nel modo giusto e imparano e usano lo stesso stile di codice per andare avanti. Al contrario, se mi vedono fare nel modo sbagliato, lo faranno anche nel modo sbagliato.

Supponendo che la necessità di ottimizzazione sia corretta

Supponendo che questa sia una parte veramente importante del tuo codice che necessita di ottimizzazione, potresti raccontare la parabola di Schlemiel the Painter o enfatizzare il resto della citazione:

"I programmatori sprecano enormi quantità di tempo pensando o preoccupandosi della velocità delle parti non critiche dei loro programmi e questi tentativi di efficienza hanno effettivamente un forte impatto negativo quando si considerano il debug e la manutenzione. Dovremmo dimenticare piccole efficienze, diciamo Il 97% delle volte: l'ottimizzazione prematura è la radice di tutti i mali. Eppure non dovremmo rinunciare alle nostre opportunità in quel 3% critico. " - Donald Knuth

Pesare i costi di ulteriore complessità

A volte c'è un costo reale in termini di manutenibilità della complessità aggiunta. In questo caso, è possibile mantenere l'implementazione secondaria in una funzione o sottoclasse diversa e applicare gli stessi unittest ad essa in modo che non vi siano dubbi sul fatto che sia corretta. Successivamente, se esegui il profilo del tuo codice e scopri che l'implementazione ingenua è un collo di bottiglia, puoi cambiare il tuo codice ottimizzato e migliorare in modo dimostrabile il tuo programma.

Comando

A volte il problema è l'ego: alcune persone preferiscono usare un codice subottimale o errato piuttosto che qualcun altro ha più ragione di loro. Probabilmente vuoi evitare di lavorare con queste persone.

La leadership, specialmente quando non si ha l'autorità posizionale sulle persone, consiste nel dare suggerimenti ragionevoli e guidare gli altri verso un consenso. Se non riesci a guidare la tua squadra verso una riunione delle menti, forse non vale la pena insistere sulla questione. Probabilmente c'è un pesce più grande da friggere.

La via da seguire è dimenticare la citazione reale e le varie interpretazioni - è dogmatismo in entrambi i casi concentrarsi così tanto su una citazione specifica di un guru. Chi dice che Knuth abbia sempre ragione comunque?

Concentrati invece sul progetto in corso, il software che stai sviluppando insieme ai colleghi con cui non sei d'accordo. Quali sono i requisiti per prestazioni accettabili per questo software? È più lento di questo? Quindi ottimizzare.

Non è necessario chiamarlo "ottimizzazione", è possibile chiamarlo "correzione di un bug", poiché è per definizione un bug se l'implementazione non è conforme ai requisiti.

Più in generale, ci sono due possibilità per quanto riguarda le ottimizzazioni:

1. Il codice ottimizzato è anche più breve, più semplice da capire e più facile da mantenere.

2. Il codice ottimizzato è più complesso da comprendere, richiede più tempo per la scrittura e il test o sarebbe più complesso da modificare in futuro se i requisiti cambiassero in modi imprevisti.

Se il caso è (1) non devi nemmeno discutere dell'ottimizzazione. Ma se (2) è il caso, allora ti stai impegnando in una decisione di compromesso . Questa è in realtà una decisione a livello aziendale, non puramente una decisione tecnica. Devi valutare il costo dell'ottimizzazione rispetto al vantaggio. Affinché ci sia anche un vantaggio, l'inefficienza deve essere un problema in primo luogo, sia come esperienza utente negativa che come costo significativamente aumentato dell'hardware o di altre risorse.

Penso che la citazione completa nel contesto sia istruttiva. Copierò da un post che ho scritto su Reddit sull'argomento:

Non c'è dubbio che il graal dell'efficienza porti ad abusi. I programmatori sprecano enormi quantità di tempo pensando o preoccupandosi della velocità delle parti non critiche dei loro programmi e questi tentativi di efficienza hanno effettivamente un forte impatto negativo quando si considerano il debug e la manutenzione. Dobbiamo dimenticare le piccole efficienze, diciamo circa il 97% delle volte: l'ottimizzazione prematura è la radice di tutti i mali.

Tuttavia non dovremmo rinunciare alle nostre opportunità in quel 3% critico. Un buon programmatore non si crogiolerà in tale compiacimento, sarà saggio guardare attentamente il codice critico; ma solo dopo che quel codice è stato identificato.

- Donald Knuth, Programmazione strutturata con go to Statements , ACM Computing Surveys, Vol 6, No. 4, Dec. 1974, p.268

Il punto, e l'implicazione, è che ci sono cose più importanti di cui preoccuparsi che porre la tua attenzione all'ottimizzazione troppo presto. Certamente, dovresti considerare attentamente le tue strutture dati e i tuoi algoritmi (questo è nel 3%) ma non dovresti preoccuparti se la sottrazione è più veloce del modulo (questo è nel 97%) fino a quando non diventa chiaro che l'ottimizzazione di basso livello è necessario.

Il primo non è necessariamente un'ottimizzazione nel senso che pensano i tuoi colleghi, ma è un'ottimizzazione nel senso che algoritmi e strutture di dati scelti male sono non ottimali.

Nella mia esperienza, se si ottiene regolarmente questo tipo di opposizione all'ottimizzazione , le persone non si lamentano davvero dell'ottimizzazione. Si lamentano di ciò che stai sacrificando in nome dell'ottimizzazione. Di solito si tratta di leggibilità, manutenibilità o tempestività. Se il tuo codice viene consegnato nello stesso lasso di tempo e altrettanto facile da capire, alla gente non potrebbe interessare di meno se stai utilizzando strutture di dati e algoritmi più efficienti. Il mio suggerimento in questo caso è di lavorare per rendere il tuo codice più elegante e gestibile.

Se stai ricevendo questo tipo di opposizione rispetto al codice di altre persone, di solito è perché stai suggerendo una quantità significativa di rilavorazioni. In quei casi hai davvero bisogno di alcune misurazioni effettive per dimostrare che vale la pena, o forse provare a essere coinvolto prima nella fase di progettazione, prima che il codice venga scritto. In altre parole, devi dimostrare che è nel 3%. Se riscrivessimo tutto il codice che non era esattamente come ci piaceva, non avremmo mai ottenuto nulla.

Ci sono davvero molti fraintendimenti su questa citazione, quindi è meglio fare un passo indietro e guardare qual è il vero problema. Il problema non è tanto che non dovresti mai "ottimizzare". È che "ottimizzare" non è mai un compito che dovresti iniziare a fare. Non dovresti mai svegliarti la mattina e dirti "ehi, dovrei ottimizzare il codice oggi!".

Questo porta a uno sforzo sprecato. Basta guardare il codice e dire "Posso renderlo più veloce!" porta a molti sforzi per fare qualcosa di più veloce che è stato abbastanza veloce in primo luogo. Potresti trovare orgoglio nel dirti che hai fatto un po 'di codice quattro volte più veloce, ma se quel codice era un calcolo che avveniva alla pressione di un pulsante, e impiegava 10 msec in primo luogo prima di essere mostrato a un utente umano, nessuno me ne frega niente.

Questo è il "prematuro" in "ottimizzazione prematura". Quando non è "prematuro"? Quando i clienti ti dicono "è troppo lento, aggiustalo!" Questo è quando digiti il ​​codice e provi a renderlo più veloce.

Questo non significa che dovresti spegnere il cervello. Ciò non significa che dovresti tenere 10.000 record dei clienti in un elenco collegato singolarmente. Dovresti sempre capire l'impatto delle prestazioni di ciò che fai in mente e agire di conseguenza. Ma l'idea è che non stai spendendo tempo extra deliberatamente cercando di renderlo più veloce. Stai semplicemente scegliendo la scelta più performante tra scelte altrimenti uguali.

Puoi fare le cose nel modo sbagliato o fare le cose nel modo giusto.

Spesso le cose vengono fatte nel modo sbagliato e il codice viene refactored in modo da farlo nel modo giusto. Se hai intenzione di scrivere un nuovo codice e sai che puoi fare le cose nel modo giusto senza una grossa penalità, sbaglierei dalla parte del farlo nel modo giusto. (Si noti che, dopo il test delle prestazioni, ecc., Alcune cose potrebbero dover cambiare - ma va bene. In alternativa, un'implementazione completamente ingenua è raramente, se non mai, giusta.)

Non è necessariamente un'ottimizzazione prematura se a) sai che aiuterà in futuro o b) sai che il percorso non ottimale porterà a problemi lungo la strada. È come una partita a scacchi, davvero.

Penso che le persone tenderanno a voler fare le cose bene, piuttosto che sbagliare. Usalo quando discuti strategie alternative con i tuoi colleghi.

Sembra un problema di comunicazione e non un problema di programmazione. Cerca di capire perché le persone sentono il modo in cui lo fanno e prova a cristallizzare perché pensi che il tuo modo sia migliore. Quando lo hai fatto, non iniziare una discussione conflittuale in cui il tuo obiettivo è quello di dire agli altri perché hanno torto e hai ragione. Spiega i tuoi pensieri e sentimenti e lascia che le persone reagiscano a questo. Se non riesci a raggiungere alcun tipo di consenso e ritieni che questo sia un problema davvero critico, allora probabilmente hai alcuni seri problemi nel team.

Più focalizzato sulla programmazione effettiva, non perdere tempo con lunghe discussioni su qualcosa che hai solo la sensazione che sia "più veloce". Se vedi qualcuno scrivere un metodo che viene chiamato una volta per richiesta in un'app Web e presenta una complessità temporale O (n ^ 2) quando SAPI che è davvero un problema temporale O (log (n)), allora, certo, se è tale un gioco da ragazzi, vai avanti.

Siate consapevoli, tuttavia, in quanto esseri umani, noi programmatori siamo davvero pessimi (e intendo FANTASTICI) nell'indovinare quali parti delle nostre applicazioni saranno strozzate. Eric Lippert scrive di questo interessante argomento in questo post del blog. Favorire sempre la manutenibilità. Eventuali problemi di prestazioni che possono essere rilevati possono quindi essere facilmente risolti (o meglio, relativamente) quando si hanno più informazioni.