In che modo i team di sviluppo possono impedire prestazioni lente nelle app consumer?

Con requisiti correttamente scritti e completi, non esiste una distinzione tra bug e prestazioni scadenti . Poiché specifichi le prestazioni come un requisito non funzionale, le scarse prestazioni diventano un bug come qualsiasi altro bug e verranno catturate dal QA e risolte dagli sviluppatori prima del rilascio.

C'è un problema sociale? Io non la penso così Il problema principale è che i requisiti sono incompleti. Lavorando per anni come libero professionista, I never ha mai visto un requisito non funzionale che indica che un'attività specifica deve eseguire in media N in media. Se il manager / cliente / stakeholder o qualunque cosa non si preoccupa del rendimento, perché io, in qualità di sviluppatore, mi preoccuperei di questo, dal momento che le persone a cui deve importare non ne importano affatto?

C'è un altro fattore che influenza le scarse prestazioni: il fatto che gli sviluppatori lavorano su PC costosi che funzionano bene . Quando lavori per anni su un PC quad-core con 8 GB di RAM, un SSD di fascia alta, il sistema operativo più recente, ecc., È molto difficile immaginare come verrà eseguita la tua applicazione su Windows XP su un PC dual-core con 512 Mo di RAM e un vecchio disco rigido pieno al 90% e non deframmentato per anni. Sfortunatamente, in alcuni paesi, l'ultimo caso è quello che vediamo per la maggior parte dei consumatori di un'app. Maggiore è il divario tra PC per sviluppatori e PC consumer, più è complicato per uno sviluppatore occuparsi delle prestazioni della sua app.

Il problema (?):

• Il cliente (o l'utente finale) non si lamenta (basta)
• Quindi il gestore del progetto (/ prodotto) non lo considera un requisito
• Pertanto lo sviluppatore non ha il tempo di risolverlo.

Devi iniziare dall'inizio, educare i clienti. Ma se comprano l'iPhone invece di un telefono più veloce e meno brillante, gli sviluppatori hanno il diritto di passare il loro tempo a guardare anziché a prestazioni. L'organizzazione non è un problema.

Certo, alcune cose possono aiutare comunque. In attesa di test automatici è fastidioso, quindi se hai test automatici gli sviluppatori hanno un feedback costante sui problemi di prestazioni, e saranno più propensi a risolverli (come un problema tecnico, non come una caratteristica).

Ma non puoi fare tutto. Ottimizza o aggiungi funzionalità e chi spende i soldi decide.

Ma alcune buone notizie: ho notato che le applicazioni SaaS / Cloud / Buzzword aiutano molto qui. Quando le persone scelgono tra alcune applicazioni web simili e riescono a testare live invece di creare prima liste artificiali di funzionalità "richieste", sono più rapidamente influenzate dalla reattività e quindi le prestazioni avranno maggiore attenzione.

Purtroppo, trovo che il problema principale sia che non puoi fare tutto. Hai una data di spedizione, e sai che è lenta, ma hai bisogno di ottenere le funzionalità X, Y, Z sul mercato.

Nella tua mente, lento puoi risolvere in seguito, ma l'app funziona almeno.

Quindi, ti preoccupi della funzionalità e dell'estetica (perché gli utenti si concentrano spesso sull'estetica). La prossima versione correggi le prestazioni.

Ma il PM ti fornisce solo un elenco di funzionalità e non c'è tempo per correggere le prestazioni.

E il circolo vizioso continua.

Sono d'accordo con gli altri, che dovremmo trovare dei modi per fare in modo che gli sviluppatori si preoccupino di più del problema, come farli testare su hardware più lenti e avere obiettivi di rendimento. Va bene, ma davvero, quando si tratta di ottimizzazione delle prestazioni -

Le persone devono sapere come - e non lo fanno

Potrebbero pensare che fanno, ma guardano tutte le domande e le risposte relative alle prestazioni su StackOverFlow e su questo forum. È doloroso il fatto che molti mostrino molto poco buonsenso sulle prestazioni.

Non è qualcosa di cui parlare, le persone hanno bisogno di imparare da facendolo . L'unica volta in cui si trovano in quella modalità è quando stanno frequentando un corso, o imparano cose nuove da un libro o da un blog.

Quindi l'unico modo in cui riesco a pensare a risolvere questo problema è quello di entrare in contatto con le persone che insegnano nella programmazione, e insegnare loro loro come farlo.

Il cielo sa, ho provato su questi forum, come in -

• La base super-semplice metodo
• A 43x speedup - fai quello con il tuo profiler
• I motivi per cui, in termini nauseanti

Chiunque può farlo Devono solo fare .

Rendi il rendimento un requisito.

Scrivere codice performante è difficile. Richiede una solida conoscenza di concetti come il threading, la gestione di eventi asincroni, il caching e la complessità asintotica. A giudicare dai gruppi di programmatori con cui ho lavorato, circa il 20-40% di un dato gruppo non comprende questi concetti abbastanza bene da incorporare considerazioni sulle prestazioni come una questione naturale nel loro lavoro quotidiano.

Tuttavia, quei programmatori sono ovviamente ancora utili alla compagnia, ma vengono assegnati a compiti non considerati critici dal punto di vista delle prestazioni, quindi si finisce con un lettore blu ray in grado di riprodurre i flussi Netflix in modo impeccabile senza perdere alcun frame, ma ci vogliono 30 -60 secondi per aprire la voce di menu che mostra la coda.

A meno che tu non sia una società di software hotshot che può permettersi di licenziare il 20% del personale e sostituirli con sviluppatori più esperti (e più costosi), l'unico vero modo per risolverlo è la formazione degli sviluppatori e l'archiviazione delle segnalazioni di bug. Non so come sia in altre aziende, ma qui se gli sviluppatori vedono un problema di prestazioni che non abbiamo il tempo o la priorità aziendale da risolvere, abbiamo il pieno diritto di presentare il nostro bug report su di esso. Potrebbero volerci un paio di versioni per arrivare in cima al backlog, ma alla fine vengono risolte.

Se le prestazioni sono un requisito, prova per questo.

Altrimenti Wally può scrivere un ciclo infinito e partire presto "Ci vuole un po '." Lui può chiedere.

Il test di accettazione del software dovrebbe avere un test di accettazione dettagliato per le varie caratteristiche delle prestazioni dell'operazione.

Se non lo fai, non stai progettando nessuna prestazione nel prodotto.

Le prestazioni (come il consumo di risorse) dovrebbero essere preventivate in budget per i sottosistemi. Quindi i test di accettazione del sottosistema possono controllarli.

Quindi puoi testare presto e spesso per le prestazioni. Anche i test di unità possono quindi controllarlo.

Quindi ora gli sviluppatori hanno come criterio di accettazione e possono organizzare il loro approccio per adattarlo.

Dove sto lavorando ora, lo stress test delle prestazioni è 2x più grande di qualsiasi set di dati dei clienti che conosciamo. Rompe regolarmente una nuova versione del prodotto. Buona prova.

Ricordo una volta a metà degli anni '90 e stavo passando un po 'di tempo a cercare di ottimizzare qualcosa e un collega mi ha detto: "Questo è in corso sui pentium, a chi importa?" .... questo è stato un apripista. Purtroppo, era solo la punta dell'iceberg, ho sentito questo atteggiamento nel corso della mia carriera, anche se la parte "pentium" è cambiata nel tempo.

L'unico modo per far sì che lo sviluppatore medio si preoccupi è quello di ottenere la mancanza di prestazioni per essere visto come un bug da parte del cliente. A seconda dell'applicazione e del pubblico, questo può essere un compito facile o difficile (ho visto entrambi). Se il pubblico non si preoccupa delle scarse prestazioni, gli sviluppatori non lo faranno mai (rapidamente, bene, velocemente - scegli due).

But it shouldn't take a letter from QA for a programmer to realize that a 3 second lag between keypress and response is unacceptable

Accetto che non dovrebbe. Dovrebbe richiedere più di questo: una prova che il ritardo ottenuto è rilevante per gli utenti finali .

Dato che non hai fornito alcun contesto, sembra del tutto possibile che il ritardo nell'ambiente di sviluppo / QA sia causato dai problemi locali di accesso lento al disco / alla memoria / alla rete. In questo caso, il tuo QA e lo sviluppatore semplicemente sprecheranno i loro sforzi per sistemare cose che non interessano solo gli utenti finali.

Affidarsi agli sviluppatori nei test delle prestazioni è tanto produttivo quanto tirare un dado per scegliere un pezzo di funzionalità da accelerare. Oh ed è affidabile come questo - "gli sviluppatori hanno in genere orribile intuizione su dove saranno effettivamente i problemi di prestazioni in un'applicazione" ( Brian Goetz ).

• Sono stato in un progetto in cui una volta la gestione lame ha deciso che i loro brillanti tipi di marketing e i programmatori intelligenti sono sufficienti per gestire i problemi di prestazioni dei clienti. Che grande lezione è stata. Rilascio rifiutato, mezzo anno di sforzi andati a finire nel cestino, e la compagnia ha quasi perso un partner strategico. Alla fine, hanno invitato professionisti (esperti in benchmark, statistiche, UX, ottimizzazione a basso livello, cose del genere) e i professionisti hanno risolto il problema.

should all programmers do their own QA so they see such issues immediately?

Il fatto che sia fattibile non significa che sia la strada da percorrere. Al contrario, nella mia esperienza questo è stato uno dei modi più affidabili per perdere la produttività dei programmatori . Quasi come interminabili riunioni e persino meglio di intervistare i candidati.

• Come ex tester, una volta ho pensato che non dovrebbe essere un problema combinare attività di sviluppo e controllo qualità. Sembrava che la differenza tra test di routine di routine e QA sistematica non fosse molto importante. Pensavo che la separazione tra dev / QA fosse semplicemente una tradizione nell'industria del software. Ho imparato piuttosto difficile che non è così. La separazione si è rivelata una questione di concentrazione e produttività, e piuttosto seria.

Se c'è un problema di prestazioni, dammi solo un benchmark e imposta le prestazioni di destinazione e io fare del mio meglio per colpirlo Non sono bravo nei test delle prestazioni, ma conosco un po 'o due sull'ottimizzazione.

Penso che il 99% delle volte il problema è il creep dell'oscilloscopio. Ad esempio con il dvr. Penseresti che sia facile, ma poi TIVO o un concorrente presentano una nuova funzionalità che è ben accolta. La prossima cosa che sai una nuova funzionalità è sul piatto. Potrebbe o meno essere compatibile con il prodotto esistente e non stiamo rifacendo il prodotto esistente che impiegherà troppo tempo. Quindi la funzione si inceppa e fa schifo le prestazioni. Certo, i dati sono lì per ottenere l'infromation ma se non si pensava di ottenere quell'informazione allora ci sono buone probabilità che non sia facile da ottenere. Quindi ora ha un processo complesso per costruire quell'informazione ogni volta che vai vicino all'elenco dei programmi.

Ignorare gli sviluppatori a cui non sembra importare ...

Penso che spesso gli sviluppatori che lavorano sul codice non abbiano gli strumenti per misurare le prestazioni su base continua.

es. Se è possibile misurare il tempo di risposta per la tua app (ad esempio un'applicazione basata sul Web o una query su un database, ecc.) - Stai ricevendo notifiche (email, SMS, qualsiasi altra cosa) che indicano la "peggiore 10" peggiore performance (o oltre una determinata soglia) risposte?

In molti, molti casi - gli sviluppatori non ottengono queste informazioni dalle distribuzioni "reali" e di conseguenza è molto facile ignorare le informazioni che non si vedono.

Se tuttavia ogni giorno / poche ore ricevi un'email che indica che la schermata "x" richiede 13 secondi per caricarsi e che sta eseguendo la seguente query SQL SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN... è meglio che tu creda che uno sviluppatore avrebbe potuto (e si sperava) risolvere il problema.

Quindi, anche se mi piacerebbe credere che tutti i programmatori fanno prendano sul serio le prestazioni, penso che la mancanza di visibilità del / i problema / i sia spesso il colpevole.

Nota: penso che sia una cosa che entrambi gli sviluppatori dovrebbero richiedere l'accesso (o persino lo sviluppo di tale funzione) e che la gestione dovrebbe fornire / finanziare tali strumenti.

Puoi trovare esempi migliori in cui possiamo effettivamente incolpare i programmatori? A parte Eclipse, e un commentatore ha già sottolineato che sono i plugin a farlo (la mia prima installazione di ogni nuova versione di Eclipse funziona come un fulmine, ma quando aggiungo gli altri strumenti inizia a rallentare), i tuoi esempi potrebbero non essere programmatori e codice correlato ma correlato all'ambiente.

I giorni di esecuzione di un programma su un computer in isolamento e la determinazione se è "veloce" o "lento" sono andati. Gli altri esempi forniti dipendono dal loro ambiente: l'attuale congestione della rete, se i server back-end sono sovraccarichi, schede di rete mal configurate, un cavo difettoso, il numero di altre persone che lo utilizzano nelle vicinanze o centinaia di altre variabili. per esempio. il nostro provider di hosting ha addebitato un supplemento per le connessioni gigabit server, ma alla fine abbiamo determinato che tutto passava attraverso un dispositivo firewall antico con porte da 10 Mb. Questi problemi cambiano e sono difficili da trovare.

D'accordo, ci sono molte cose che i programmatori possono fare (riducendo al minimo la larghezza di banda, i trucchi dell'interfaccia utente che migliorano la reattività e mostrano i progressi per dare l'impressione che sia veloce). Ma quando esci nel mondo reale ci sono circostanze di ogni genere che apprendi solo per esperienza (e osservi le tue supposizioni crollare di fronte a te).

Quanto sei disposto a pagare per un software migliore? Quanto il mercato attenderà un software migliore? Quanto poco cruft vorrà aggiungere alla prossima versione?

È un mercato spietato là fuori dove vengono fatti molti compromessi. Se è veramente una schifezza, il mercato (o dovrebbe) fallirebbe il prodotto. Forse ci sono abbastanza clienti che possono vivere con lo status quo?

Penso che la risposta più generale a questo problema sia anche la più difficile da gestire, ovvero che ogni programmatore dovrebbe essere consapevole delle prestazioni con qualsiasi cosa facciano. Capisco anche che è un po 'fuori di testa.

A seconda delle dimensioni del progetto e del team corrispondente, credo che ci possa essere molto valore nell'avere programmatori di prestazioni dedicati.

Ad esempio, ho lavorato a un team in cui il team di progetto (inclusi circa 30 sviluppatori) aveva almeno 2 persone dedicate all'ottimizzazione delle prestazioni. Questa app in particolare era anche soggetta a problemi di prestazioni in quanto vi erano moltitudini di componenti di interoperabilità, non solo sui servizi Web, ma anche in termini di livelli legacy con vari componenti di mappatura dati e adattatore.

L'esperienza della prima mano è importante. Dare agli sviluppatori un computer veloce da compilare e costruire, ma un computer veramente sovraccarico lento (come una certa percentuale di utenti potrebbe effettivamente avere) per eseguire la propria app (s) su. (Questo può essere fatto in ambienti di sviluppo basati su cloud / server mediante il partizionamento di VM o server in base alla funzione). Dare loro un telefono cellulare con una batteria semivuota e richiedere loro di usarlo solo per i test iniziali dell'app mobile.

Se gli sviluppatori si immedesimano con il cliente per quanto riguarda le prestazioni e la durata della batteria, allora non considereranno le prestazioni come delle specifiche di gestione semi-fittizie da mettere in fondo all'elenco delle priorità. (Come in: "hey, ho pensato che fosse l'ottimizzazione prematura" fino a tardi.)

Interrompi l'acquisto di materiale e commenta le scarse prestazioni di qualsiasi recensione online che incontri.

Se i dispositivi sono ancora in vendita, il software è "abbastanza buono" da non investire più tempo e denaro. Se le recensioni negative sulle prestazioni riducono significativamente le vendite, il software non è "abbastanza buono" e deve essere corretto.

Le sole metriche che interessano un produttore di beni di consumo sono le vendite e il profitto per unità.

Sono d'accordo che i programmatori dovrebbero essere meglio istruiti su come massimizzare le prestazioni, ecc.

Ma penso che la soluzione non stia fornendo ai programmatori un hardware quasi fatale per l'uso quotidiano. Quanto sarà stressante se il tuo studio visivo si blocca due volte al giorno, ci sono voluti x secondi per costruire la roba, y secondi per aprire la soluzione, z secondi per cambiare windows. Non penso che sia stato molto conveniente per l'azienda, dal momento che l'hardware è economico e il tempo dei programmatori è costoso.

Dato che la prossima mano che gestirà il codice è il team QA (testing), non sarebbe meglio insegnare loro l'importanza delle prestazioni, avere uno standard di performance standard accettabile, ecc. come standard aziendale (beh, nel mondo perfetto, lo standard delle prestazioni dovrebbe essere specifico ma ciò non accade molto spesso)? (La normale pagina di ee-change / scheda dovrebbe accadere immediatamente, "salva l'aggiornamento dovrebbe avvenire in x secondi", se è un'app critica allora ...). Il computer in cui vengono eseguiti i team di controllo qualità dovrebbe essere il tipico computer dell'utente. (non vogliamo farli incazzare dando loro un 386, ma non dare loro un quad core con 8GB di ram per esempio). Non si sfogerebbero ai programmatori se si arrabbieranno abbastanza con le prestazioni?

Penso che il cliente / project manager dovrebbe costringere il programmatore / qa team / sviluppatore / rappresentante del team aziendale a fare la propria presentazione sull'hardware tipico più basso che hanno. (il computer più debole dell'azienda, ad esempio). Se è riscritto, dovranno raccogliere dati sulla velocità con cui eseguire x process nel vecchio software e confrontarlo con la velocità con il nuovo software (potrebbe essere più lento, dal momento che il nuovo software potrebbe comportare un ulteriore processo di business ma dovrebbe esserci una finestra accettabile).

L'ho già detto in precedenza, ma lo ripeto: penso che uno dei modi migliori per gestire questo è semplicemente quello di far lavorare i tuoi sviluppatori su hardware (relativamente) di ultima generazione.

Per il tuo tipico programmatore, la maggior parte delle considerazioni ufficiali sulle prestazioni sono secondarie semplicemente: "è fastidioso quando provo a eseguirlo?" Se lo trovano fastidioso, lo risolveranno (almeno provano a farlo). Se sono contenti del modo in cui funziona, il meglio che otterrai è un tentativo poco convincente di sistemare. Questo aiuta anche a trovare i problemi in anticipo, prima che diventino molto più costosi da risolvere.

Se arriva al punto che QA deve far rispettare le regole in cui gli sviluppatori non credono perché pensano che le prestazioni siano adeguate, è molto probabile che la maggior parte delle "correzioni" che ottieni avranno modi creativi di spostarsi le regole, non correzioni reali che migliorano la vita per l'utente finale.

Allo stesso tempo, devo aggiungere che raramente ho visto questo come un problema. Se non altro, ho visto gli sviluppatori spendere troppo tempo cercando di migliorare le prestazioni in cui non mi importava abbastanza da disturbare (un peccato di cui sono spesso colpevole).