La performance engineering è una specializzazione diversa dallo sviluppo generale del software?

No, no, no, non puoi separare qualcosa che è intrinsecamente parte del lavoro.

I programmatori possono codificare qualsiasi cacca che faccia ticchettare tutti i test in verde e poi dire all'altro team di riscrivere tutto per farlo funzionare anche velocemente? Non funziona in questo modo.

È un lavoro dello stesso programmatore che scrive il codice per pensare anche alle prestazioni. Se li liberi da quell'obbligo, cosa li motiverebbe a imparare e a migliorare le cose ogni volta?

Detto questo, c'è un percorso di carriera se si sceglie di specializzarsi nell'ottimizzazione delle prestazioni. Ma non è come un lavoro quotidiano, è piuttosto che offri i tuoi servizi di consulenza a vari clienti per aiutare con i loro problemi di prestazioni. Ovviamente, per essere in grado di farlo, devi essere già passato oltre la possibilità di scrivere solo codice funzionante e avere acquisito conoscenza di come rendere il codice funzionante un codice veloce.

Sì, è assolutamente utile disporre di ingegneri esperti delle prestazioni, se il tuo sistema è al di sopra della media complessità.

Il motivo è che localizzare il collo di bottiglia di un sistema in uso effettivo è molto diverso dalla programmazione generale non sprecata. Deve assolutamente essere fatto su un sistema realistico, non su una sandbox di sviluppo. Richiede competenze (analitiche piuttosto che sintetiche) e strumenti (traccianti, profiler online) che sono molto diversi dalla programmazione delle applicazioni. Persino i più grandi esperti linguistici di solito non possono prevedere quale sarà il collo di bottiglia solo dall'ispezione del codice sorgente, e in effetti questa non è una cosa utile da fare. Mai supporre; misura sempre .

Inoltre, una volta misurato, la parte di un sistema che deve essere modificata per migliorare le prestazioni è in genere molto piccola rispetto all'intero sistema. E risolvere il problema potrebbe richiedere un linguaggio di programmazione diverso da quello originale (C invece di Python, Assembler invece di C ...) Non è semplicemente utile spendere questo tipo di sforzo su ogni parte di un sistema per cominciare e non ha alcun senso dal punto di vista economico richiedere a tutti i tuoi sviluppatori di conoscere l'assemblatore solo perché potrebbe rivelarsi necessario in alcuni punti.

Non credo che tu possa dividere completamente questo ruolo, perché l'ottimizzazione delle prestazioni spesso porta a soluzioni progettuali diverse (struttura del codice più piatta, più ripetizione, meno indiretta, meno astrazione) che concentrarsi totalmente sulla velocità di sviluppo, sulla manutenibilità e sull'estetica del codice. Il codice veloce è spesso un codice brutto. Se hai 2 team separati, uno che lavora su miglioramenti delle prestazioni, un altro che lavora sulla funzionalità, inevitabilmente si scontreranno e discutono sui cambiamenti di progettazione, che possono essere irreversibili. In poche parole, se un software deve essere veloce e mantenibile, deve essere scritto da un singolo team che conosca ENTRAMBI le prestazioni e i principi del "bel design". E sì, una squadra del genere è più difficile da costruire. Spiacente; -)

Ecco un esempio di una delle mie esperienze in ottimizzazione delle prestazioni.

Ecco un altro.

Se fossi tornato nel mondo accademico, e potrei dire ai programmatori di oggi come affrontare questo problema, farei in modo che siano competenti nel tecnica di pausa casuale .

Così com'è, escono dalla scuola pensando che a) la performance sia tutta una questione di big-O, e b) i profiler siano come trovi i problemi di performance. Questo perché è tutto ciò che i loro insegnanti sanno, e i loro insegnanti non hanno mai fatto molto per ottimizzare le prestazioni su software reale (grande), come nei link sopra. Pensano ancora alla misurazione = trovare, e pensano ancora che stiano cercando "metodi in cui il tempo è trascorso", come se il significato di ciò fosse persino compreso. Ecco un elenco dei miti.

Quindi, per rispondere alla tua domanda, a) il test di qualità dovrebbe assicurarsi che siano inclusi test di stress, per rilevare problemi di prestazioni, e b) i programmatori dovrebbero essere quelli per trovare e risolvere i problemi di prestazioni, proprio come qualsiasi altro bug .

Quando i programmatori acquisiscono un'esperienza sufficiente, imparano a evitare approcci progettuali che portano a problemi di prestazioni, come la progettazione di strutture dati eccessivamente complicate, dati non normalizzati e cose che sono state insegnate come parte di OOP, come l'eccessiva dipendenza in caso di notifica, troppe "novità" e nascondigli di informazioni che portano a buchi neri che ingannano il programma.

Con l'esperienza, imparano come usare le loro abilità OOP con giudizio e con parsimonia, in modo da non causare molti problemi di prestazioni. Imparano anche come trovare e rimuovere quelli rimanenti che fanno causa.

I problemi di prestazioni sono come bug. I programmatori esperti ne fanno meno, ma se non lo fanno non funzionano. In ogni caso è compito loro trovarli e risolverli, ma nella mia esperienza, purtroppo, pochi di loro sanno davvero come, e tutti noi sperimentiamo il risultato.