A che punto dovresti iniziare a pensare alle prestazioni?

Mentre sto costruendo applicazioni mi trovo costantemente a chiedere se questo è il modo migliore per eseguire o implementare una determinata funzionalità. Spesso, posterò domande su StackOverflow o su un altro forum che desiderano feedback solo per ricevere commenti su come non "mettere il carrello davanti al cavallo" per quanto riguarda le prestazioni. La maggior parte dei programmatori non pensa davvero alle prestazioni fino a quando l'applicazione non è terminata o le prestazioni sono assolutamente inaccettabili ?? Voglio dire, capisco che gli ambienti di sviluppo differiscono dagli ambienti di produzione e che non dovresti fare completamente affidamento sui risultati del tuo laptop dev ... ma ci sono pratiche e tecniche che offrono prestazioni migliori di altre.

È una cattiva pratica considerare le prestazioni durante tutto il processo di sviluppo? Devo respingere queste considerazioni fino a quando le prestazioni in realtà non stanno andando in rovina ??

Aggiornare

Per essere chiari, sto parlando della situazione in cui stai considerando o stai per lavorare su alcune funzionalità. Sai che ci sono diversi modi per implementarlo, ma non sei abbastanza sicuro di quanto scalerà ogni implementazione. Inoltre potrebbero esserci diverse tecniche con cui non hai nemmeno familiarità. Su piccola scala, uno qualsiasi degli approcci sarebbe probabilmente adeguato, ma su una scala più ampia alcuni terranno il passo e altri no. Spesso quando chiedo opinioni o indicazioni la risposta è: preoccuparsene più tardi ...

Il differimento delle considerazioni sulle prestazioni a volte si basa su un'errata applicazione della frase:

L'ottimizzazione prematura è la radice di tutti i mali.

Se leggi la citazione completa, Knuth stava cercando di dire che le micro-ottimizzazioni applicate durante lo sviluppo senza profilazione sono generalmente sconsigliate, perché portano a un codice meno gestibile senza necessariamente ottenere sostanziali benefici in termini di prestazioni.

Ma ciò non significa che non dovresti considerare le prestazioni fino a quando l'applicazione non è quasi terminata. Se lo fai, potresti scoprire che le prestazioni sono inadeguate, la tua architettura di progettazione non supporta prestazioni migliori e devi ricominciare da capo.

Ci sono un certo numero di cose che puoi fare durante lo sviluppo per ottenere buone prestazioni, senza ottimizzazioni esoteriche (e premature):

1. Usa un'architettura sensibile e ben ponderata.
2. Utilizzare correttamente le strutture dati.
3. Utilizzare tecnologie (librerie, framework) che funzionano adeguatamente.

Se fai queste cose, scoprirai che qualsiasi ottimizzazione delle prestazioni che deve avvenire sarà limitata a una piccola parte del tuo codice. La profilazione identificherà quel codice e ti consentirà di focalizzare i tuoi miglioramenti delle prestazioni dove faranno il massimo, senza sacrificare la manutenibilità.

Ecco cosa NON pensare:

• È ++ipiù veloce di i++?
• È switchpiù veloce di if?
• Devo le inlinemie funzioni?
• Le funzioni virtuali sono lente?
• C ++ / Java / C # è più veloce / più lento dell'altro?
• blah, blah, ...

Ecco cosa pensare:

• Che cos'è un carico di lavoro previsto realistico?
• Con quale frequenza cambiano le informazioni di input e chi le fornisce? Ha senso considerare la pre-compilazione?
• Ho mantenuto la mia struttura di dati il ​​più semplice e normalizzata possibile? Ciò significa non preoccuparsi dell'hashish e cose del genere.
• Ho mantenuto le notifiche al minimo assoluto? (È qui che le modifiche in una parte dei dati richiedono modifiche contemporaneamente in un'altra parte, poiché la struttura dei dati non è normalizzata.)

Per quanto riguarda quest'ultimo punto, nella mia esperienza è meglio progettare la struttura dei dati in modo tale che, se non deve essere normalizzato, sia in grado di tollerare un'incoerenza temporanea, che può essere successivamente risolta da una sorta di scansione periodica. Un importante killer delle prestazioni è quando le notifiche attivano ulteriori notifiche, che si attivano ulteriormente, in una misura che non avresti mai immaginato prima. E spesso è uno sforzo sprecato a causa di modifiche di annullamento automatico.

Se hai fatto tutto questo, hai un design pulito. Quindi periodicamente mentre lo sviluppi, profilo. ( La pausa casuale è il metodo su cui faccio affidamento.) Quindi, se riesci a vedere che le prestazioni sarebbero migliorate introducendo un algoritmo più sofisticato, lo fai sicuramente.

No, dovresti pensare alle prestazioni (specialmente nella progettazione di database) dall'inizio. C'è stato un sacco di danno nel nostro settore da parte di persone che pensano che qualsiasi ottimizzazione sia ottimizzazione prematura. La citazione era originariamente intesa a impedire alle persone di esaminare le microottimizzazioni prima che si verificasse un problema. Non intendeva non fare alcuna ottimizzazione. In un database, ad esempio, ci sono molte tecniche conosciute che funzionano male. Evitare quelli, nel design, fa parte di ciò che devi fare. È molto difficile riformattare un database con 100.000.000 di record perché è stato progettato utilizzando tecniche scarsamente perforanti e non possiamo più evitare il problema acquistando hardware migliore.

Preoccupati prima della correttezza ¹ , quindi della manutenibilità, quindi della sicurezza e dell'affidabilità, quindi puoi pensare alle prestazioni. Applica questo ordine a ogni parte di codice mentre lo stai sviluppando. È possibile che una soluzione performante possa naturalmente cadere semplicemente nel mantenere le cose chiare e dirette.

L'80% delle prestazioni sta scegliendo l'algoritmo e la struttura dati giusti per il problema attuale; un quicksort mal ottimizzato sta ancora battendo i pantaloni da una sorta di bolla altamente ottimizzata nel caso medio (nel peggiore dei casi è un pareggio).

Quello che tutti gli SO su stanno cercando di abbattere è la mentalità "che è più veloce, ++ p o p ++", in cui le persone sono così coinvolte nel superare in astuzia il compilatore da perdere la traccia del problema più grande, con conseguente codice fragile, bug -ridotto, sbagliato e, soprattutto, non molto più veloce di una soluzione più semplice. Ho affrontato quel tipo di codice in prima persona; Un esempio è stato così fragile che non abbiamo potuto fare qualsiasi modifiche senza romperlo completamente.

¹ Dove "correttezza" significa "soddisfare le specifiche", che non è sinonimo di "privo di bug".

Dovresti iniziare a pensare alle prestazioni una volta che sai cosa sono le prestazioni "buone". In altre parole, sarebbe sbagliato iniziare a pensare alle prestazioni prima di aver identificato le seguenti soglie:

• Prestazioni inaccettabili: correggilo ora prima che sfugga di mano
• Prestazioni accettabili: è il momento di concentrarsi su altre funzionalità prima di provare a fare di più con le prestazioni.
• Prestazioni target: numeri di performance idealizzati. Cioè, se hai tempo e risorse sufficienti, cosa avresti bisogno del tuo sistema?

Dopo aver identificato le soglie, hai anche identificato la metrica che stai utilizzando per misurare le prestazioni. Ciò significa che è possibile impostare alcuni test delle prestazioni automatizzati che è possibile eseguire più volte al giorno. Questo ti dirà se stai migliorando o peggiorando.

Per elaborare queste metriche, devi capire cosa deve fare il tuo sistema. Ad esempio, sono richieste metriche di prestazione assolute (risposta entro il tempo X) o sono richieste misure di rendimento (risposte X per tempo Y)? L'ottimizzazione della produttività e del tempo assoluto richiedono approcci diversi e, se non sai cosa è veramente importante, potresti ottimizzare il modo sbagliato.

Probabilmente hai sentito che l'ottimizzazione prematura è la radice di tutti i mali. La domanda è: cosa lo rende prematuro? Secondo me, non è mai una cattiva idea pensare alle prestazioni, ma non preoccuparti eccessivamente fino a quando il tuo codice non funziona. Una volta che funziona, esegui alcuni test di carico pesante, profila e identifica i colli di bottiglia e ottimizza le prestazioni.

Detto questo, non c'è nulla di sbagliato nel pensare alle prestazioni durante la fase di codifica iniziale se conosci alcune tecniche che faranno davvero la differenza. Ad esempio, scegliere una struttura di archiviazione da una libreria rispetto a un'altra perché l'esperienza passata ti ha insegnato che una di esse è più veloce / utilizza meno RAM dell'altra. O inserendo un sistema di memorizzazione nella cache semplice (puoi renderlo più sofisticato se i test successivi lo richiedono) per i dati che conoscisi accederà molto e sarebbe molto meglio memorizzato nella cache. In questo modo, non ti preoccupi troppo delle prestazioni (almeno non inizialmente) ma stai usando suggerimenti e trucchi che hai imparato lungo la strada da altri progetti. Cerca di mantenerli semplici in modo che siano facili da includere durante lo sviluppo iniziale e possano offrire anche alcuni vantaggi.

Le prestazioni devono essere dettagliate nel sistema e nelle specifiche relative all'utente del Documento sui requisiti. Conosco molte persone ghignare all'idea di intraprendere l' analisi dei requisiti nello sviluppo di un'applicazione, ma sorprendentemente un documento del genere risponderà in modo conciso a cosa e dove dovresti dedicare le tue risorse relative alle prestazioni man mano che l'applicazione si avvicina al completamento. E risponderà a questa domanda in modo tempestivo

Requisiti La documentazione ti farà risparmiare centinaia di ore di tempo che altrimenti verrebbero sprecate in processi non essenziali.

Un approccio equilibrato sarebbe migliore. Le prestazioni sono importanti ma non così importanti come ottenere risultati, quindi:

1. prima costruisci una funzionalità cercando di pensare un po 'a quello che fai e a come lo fai (usa un po' di tempo pensando alle prestazioni ma non molto)
2. Provalo
3. una volta avviato inizia a pensare se è davvero necessario migliorarlo (in genere non lo farai, ma in alcuni casi potresti).

Questo è il mio approccio comune a performace vs funzionalità, e in generale dipende tutto da ciò che fa il programma e dalla verifica se è necessario far funzionare meglio le cose e quanto tempo mi costerebbe.

Pensiamo a un sito web di domande e risposte come questo, penso che quelli dietro di esso sicuramente abbiano pensato molto a come fare una domanda e ottenere la risposta il più efficiente possibile in termini di tempo / costi. Ma, quando si pensa alle notifiche, in realtà non importa molto se le notifiche appaiono di tanto in tanto e ti dicono che c'è una nuova risposta o qualcosa del genere.

Esiste un modo per rinviare in modo sicuro il pensiero sulle prestazioni: usare le lingue specifiche del dominio ove possibile.

Se la maggior parte del tuo sviluppo può essere eseguita con i tuoi piccoli DSL e sono progettati abbastanza bene da esprimere il tuo dominio problematico nella forma più generica e di alto livello, è possibile ottenere prima un prototipo funzionante, senza mai pensare a prestazioni e quindi migliorare solo le implementazioni DSL, non il codice di dominio del problema effettivo.

È un approccio molto migliore anche dal punto di vista della manutenibilità.

Dovresti prendere in considerazione le prestazioni. Tuttavia, è necessario tracciare una linea per segnare la fine della messa a punto, poiché (di solito) il tempo è più importante di quello del computer.

Un ottimo articolo di testo sulle prestazioni è: Il Computer Performance Shell Game .

Il gioco shell di prestazioni del computer, noto anche come "trova il collo di bottiglia", viene sempre giocato tra queste quattro risorse:

• processore
• Disco
• Rete
• Memoria

In qualsiasi momento, il tuo computer è in attesa di completare un'operazione su una di queste risorse. Ma quale: CPU, memoria, disco o rete? Se sei interessato alle prestazioni, la prima cosa assoluta da fare è determinare quale di questi colli di bottiglia sta impedendo le prestazioni ed eliminarle.

Il modo "migliore" è un termine molto caricato e la risposta può dipendere fortemente da fattori non noti fino al runtime.

• Hai molta memoria? - otterrai prestazioni migliori con una struttura di dati "all-in-memory", ma se non hai abbastanza scambio di memoria, le tue prestazioni verranno annullate.
• Hai bisogno di persistenza? Un database fornisce integrità ma è più lento della struttura di dati "all-in-memory" di cui sopra. MOLTO più lento.
• Puoi memorizzare i risultati nella cache? La vernice può aiutarti! http://www.varnish-cache.org/

La lista potrebbe continuare all'infinito.

Che cosa si può fare, è quello di scrivere "la cosa più semplice che poteva funzionare" dalla conoscenza che attualmente non hanno, e lo fa in un modulare di moda in modo da poter facilmente riorganizzare quando si sa di più. Nota che la cosa "più semplice" non è necessariamente semplice!

È sempre qualcosa che dovresti tenere a mente. Penso che ciò che la maggior parte delle persone stia cercando di dire è che non ha molto senso passare due giorni a cercare di ottimizzare qualcosa che non si sa nemmeno sia rotto. Una volta che un prodotto è in esecuzione e puoi fare alcuni test di usabilità, questo dovrebbe mostrarti dove stai riscontrando problemi di prestazioni. Quindi, una volta identificati i veri problemi di prestazioni, puoi scegliere come target le ottimizzazioni che devi eseguire.

Almeno in teoria, dovresti iniziare a pensare alle prestazioni una volta che sei in beta test e non prima.

Questa non è, tuttavia, la licenza per prendere decisioni di progettazione sbagliate. Ad esempio, l'uso di una stringa NVARCHAR come chiave primaria è un percorso sicuro per scarse prestazioni; detto questo, è un'abitudine sporca a prescindere dai problemi di prestazioni e non si dovrebbe usare in primo luogo.

Se il tuo progetto segue le migliori pratiche convenzionali (tutto in terza forma normale, nascondimento corretto delle informazioni nelle tue classi, uso minimo di singoli, ecc.) E in seguito c'è un problema di rendimento, sarà facile da gestire (crea un indice qui, implementare una cache lì).

HTH

Dipende. È utile tenere presente la regola 80/20: la maggior parte (diciamo l'80%) del codice nell'applicazione non verrà mai eseguita abbastanza spesso da fare una notevole differenza nelle prestazioni. Devi concentrarti sul restante 20% dove l'app è destinata a spendere circa l'80% del suo tempo di esecuzione.

Potresti essere in grado di identificare in anticipo alcuni degli hot spot prestazionali ovvi, come se sapessi che un determinato calcolo verrà ripetuto milioni di volte. In questi casi, vale sicuramente la pena pensare di ottimizzarlo in anticipo scegliendo le strutture dati e gli algoritmi giusti per il lavoro.

Tuttavia, tale ottimizzazione è più un'attività di progettazione. Ciò che di solito è inutile sono le micro-ottimizzazioni, in cui qualcuno trascorre una quantità eccessiva di tempo con trucchi ingegnosi come "ottenere prestazioni". Soprattutto se fatto senza misurazioni appropriate prima e dopo, tali modifiche potrebbero non fare alcuna differenza o effettivamente rallentare l'app in circostanze reali.

Dipende da quale fase di sviluppo ci si trova

1) Se stai sviluppando le funzionalità del tuo software, prosegui e assicurati che funzioni correttamente (cioè, desiderato ed efficiente).

2) Una volta integrati i blocchi predefiniti, otterrai un accenno di hogger delle risorse, lì avrai spazio per l'ottimizzazione.

Se devi iniziare a pensare alle prestazioni, sei nei guai. Dovresti pensare sempre alle prestazioni. In effetti, sospetto che i bravi programmatori penseranno alla performance anche quando non avevano intenzione di farlo, in un modo "gli uomini pensano al sesso ogni sette secondi".

Ciò che è importante è quali azioni intraprenderai sulla base di tutto quel pensiero. I pensieri sono economici, ma le azioni possono infrangere il codice e far scadere le scadenze.

La maggior parte delle volte, l'unica azione sensata sarà quella di non fare nulla: hai identificato che il tuo pezzo di codice non verrà chiamato abbastanza spesso perché i problemi di prestazioni siano osservabili, forse è un pezzo di codice di avvio che viene eseguito una volta per computer per 1% della tua potenziale base di utenti, forse è un po 'di codice server ridondante annegato in un mare di lenti accessi al database, forse è solo un'assegnazione intera in una sezione non critica del codice.

Molto spesso, si sospetta che una determinata operazione possa causare un problema di prestazioni che potrebbe essere risolto con una semplice modifica. Ad esempio, la fastidiosa sensazione che eseguire una complessa query SQL su ogni richiesta o richiedere due volte lo stesso pezzo di dati da un dizionario, sarà dannosa per te. È qui che risulta utile la conoscenza delle tecniche di ottimizzazione e forse si arriva alla conclusione più sorprendente:

Se conosci una tecnica rapida che quasi sicuramente migliorerà le prestazioni di un pezzo di codice, non farlo.

Se riesci a pensarci ora, puoi sicuramente farlo tra cinque minuti più tardi. Tenendolo fuori dal codice (ma, forse, in un // TODOcommento) lascia il codice più pulito e ti salva la volta precedente per lavorare su un'altra funzione, senza perdere tempo se finisci per buttare via quel codice in seguito. Se il codice originale risulta causare problemi di prestazioni quando testato, torna indietro e applica la tua tecnica rapida.

Non sto dicendo qui che dovresti evitare di scrivere codice idiomatico solo perché sembra essere più veloce. Scrivi codice idiomatico secondo le migliori pratiche che migliorano la produttività e la leggibilità e riducono i bug. È solo che se hai una scelta tra il codice idiomatico del libro e un'alternativa più veloce ma facile da scrivere, scegli sempre la leggibilità invece della velocità.

L'unica situazione difficile è quando non sembra esserci un modo semplice per migliorare le prestazioni del codice, eppure è dolorosamente ovvio che un pezzo di codice si romperà non appena viene consegnato: un attraversamento completo del database ad ogni clic, un centinaio di richieste SQL per pagina sul sito o qualcosa di altrettanto spaventoso. Qui è dove è necessario fermarsi e pensare ancora. Di solito si tratta di problemi di architettura che non possono essere risolti comunque su scala locale. Conferma i tuoi sospetti con un picco rapido o un prototipo, cerca esperienze simili e soluzioni comuni e considera un cambiamento di architettura o un calo di funzionalità.

IMHO è importante pensare alle prestazioni prima di implementare il sistema, ma solo pensare. È necessario analizzare l'applicazione e scoprire quali potrebbero essere i potenziali colli di bottiglia delle prestazioni.

Quindi implementare il sistema il più semplice possibile. Se sorgono problemi di prestazioni, ottimizzali.

Ad esempio, supponiamo di avere un client GUI che ottiene i dati attraverso un qualche tipo di servizio (SOAP, REST HTTP, ecc.). Quindi la cosa più importante per le alte prestazioni / scalabilità è avere il minor numero di chiamate possibile, avendo ogni chiamata restituisce molti dati, piuttosto che molte chiamate restituiscono un po 'di informazioni ciascuna, cioè preferiscono la comunicazione pesante a quella chiacchierona.

Quando si implementa questo tipo di sistema, non mi interessa molto il numero di chiamate tra il sistema. Ma vorrei assicurarmi che la base di codice mi avrebbe facilitato il refactoring / ottimizzazione in caso di necessità.

Dovresti pensare alle prestazioni in modo molto generale sin dall'inizio. È necessario selezionare strutture di dati e algoritmi che funzioneranno bene per l'applicazione e che siano ragionevolmente efficienti. Gli algoritmi sono fondamentali per il software e le strutture di dati ancora di più. Probabilmente dovrai eseguire importanti riscritture se devi apportare modifiche importanti a entrambi, mentre i dettagli più piccoli possono essere riscritti più facilmente.

Potresti anche voler avere abitudini efficienti, ma queste dipenderanno dalla lingua. In C ++, ad esempio "++ i;" poiché un'istruzione o un'espressione autonoma è sempre valida almeno quanto "i ++;" e potrebbe essere potenzialmente molto più efficiente. Nella maggior parte dei casi, tuttavia, è necessario scrivere un codice chiaro e fidarsi del compilatore. Prendere l'abitudine di preoccuparsi delle microefficienza quasi sicuramente ti causerà più problemi di quanti ne risolva. Per le app desktop, il compilatore è intelligente almeno quanto lo sei su i >> 1vs. i / 2, oppure il modo migliore per migliorare le prestazioni è ottenere un compilatore migliore, quindi non preoccuparti.

Oltre a ciò, non preoccuparti molto finché non avrai qualcosa che puoi testare. In quel momento, puoi profilare il programma per vedere dove sono i punti caldi e probabilmente avere un'idea sul fatto che tu abbia un programma di performance o meno. Se devi migliorare le prestazioni, scopri dove il programma trascorre la maggior parte del suo tempo e migliora le cose lì. Se hai progettato un'efficienza globale adeguata e hai scritto bene il programma, stai cambiando solo una parte relativamente piccola del programma.

Penso che il meglio che puoi fare sia seguire le buone pratiche di progettazione (ad esempio, non fare cose che sai ostacoleranno le prestazioni) finché non riuscirai a far funzionare qualcosa. Se non puoi misurare il miglioramento, non puoi apportare miglioramenti. Una volta che hai qualcosa con cui puoi provare, allora è spesso una buona idea fare una corsa di profilazione e avere un'idea di dove siano gli hot spot (se presenti). Se qualcosa ti salta fuori, dovresti considerare il refactoring o la riscrittura dell'area problematica, ma se non è così male (solo perché il codice trascorre il 90% del suo tempo in due o tre metodi non significa nulla se si comporta in modo adeguato nel complesso) poi continua a sviluppare. Qualcosa che ho visto più di una volta sono gli sviluppatori che passano giorni a ottimizzare la parte più complessa del sistema,

Quando dovrei iniziare a pensarci? Quanto sforzo dovrei fare? Dipende dalla scala Cockburn del progetto. (In altre parole, qual è il rischio di non avere buone prestazioni?)

Impara i fondamenti con largo anticipo (vedi la risposta di Robert Harvey ). Per applicare il pensiero orientato alle prestazioni durante le varie fasi dello sviluppo del software, lo sviluppatore deve conoscerlo a fondo, in modo che il processo di pensiero non venga ostacolato da tali considerazioni aggiuntive. (In altre parole, inizia a pensare alle prestazioni prima che il progetto venga concepito.)

Durante le prime fasi dello sviluppo, fai un uso liberale degli strumenti di profilazione delle prestazioni e tieni traccia della cronologia delle statistiche. Prestare particolare attenzione all'organizzazione di tali informazioni per renderle utili per il successivo processo decisionale.

Quindi, a seconda della natura del tuo progetto e della sua scala Cockburn:

• Prototipazione rapida, o "sbattere il codice come se non ci fosse un domani", o sviluppo interno a basso impatto aziendale: basta mantenere le statistiche. Non pensare ancora alle prestazioni. Implementa la funzione nel modo più semplice. Attenersi al primo algoritmo che ti viene in mente.

  • Nella seconda parte del progetto, ci saranno test delle prestazioni ad hoc per identificare gli "hotspot" in base ai casi d'uso reali. Se si verificano problemi di prestazioni che rendono il software inutilizzabile, dovrebbe essere facilmente identificabile.
  • Per lo sviluppo interno a basso impatto aziendale, è sufficiente distribuire il codice e risolvere i problemi di prestazioni in un secondo momento.

• Applicazioni desktop, che richiedono un approccio coerente e completo alle prestazioni. Non deve essere altamente ottimizzato; tuttavia, dovrebbero esserci il minor numero possibile di "blocchi" (non reattività).

  • Le applicazioni desktop di solito hanno percorsi di esecuzione altamente contorti che complicano il pensiero orientato alle prestazioni. Una progettazione a più livelli consentirà la separazione dei problemi di prestazioni di database / rete da problemi di prestazioni della GUI, che sarà gestita da diversi esperti del team.
  • Una cronologia delle tracce di registro consentirà di identificare gli hotspot.

• Elaborazione ad alte prestazioni, che richiede di ottenere le massime prestazioni dall'hardware.

  • Nomina qualcuno nel tuo team incaricato di analizzare e riportare le statistiche sulle prestazioni.
  • Fai teorie sulle caratteristiche prestazionali, verifica con gli esperimenti e confronta con le tue previsioni dai modelli Comp Sci semplificati.
  *

All'inizio. Identificare le caratteristiche prestazionali richieste. Se non è possibile identificare l'obiettivo, è necessario fare un passo indietro per comprendere meglio le proprie esigenze o differire fino a quando non si conoscono i requisiti dei componenti con il rischio che si potrebbe riscrivere. Quindi, prova. Non ottimizzare, prova. Se il codice non supera il test delle prestazioni, ottimizzare. Con un framework di test in atto, l'utilizzo degli strumenti di monitoraggio delle prestazioni esistenti dovrebbe rendere l'attività relativamente semplice.

Mantenere i test delle prestazioni in atto per tutta la durata del progetto come test di regressione. Il codice di manutenzione è noto per innescare problemi di prestazioni perché le "correzioni" hanno spesso un focus molto ristretto.

Mi affido sempre a una formula semplice:

1. Fallo funzionare
2. Fallo giusto
3. Fallo veloce

... in questo ordine.

Secondo c2 , questa formulazione è attribuita a Kent Beck .