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

Quando in precedenza avevo chiesto cosa fosse responsabile del software lento, alcune risposte che ho ricevuto suggerivano che si trattava di un problema sociale e di gestione:

Questo non è un problema tecnico, è un problema di marketing e di gestione .... In definitiva, i responsabili del prodotto sono responsabili di scrivere le specifiche per ciò che l'utente dovrebbe ottenere. Molte cose possono andare storte: il product manager non riesce a inserire la risposta dei pulsanti nelle specifiche ... Gli addetti al controllo qualità eseguono un lavoro mediocre di test rispetto alle specifiche ... se la gestione del prodotto e il personale addetto al controllo qualità sono tutti addormentati al volante, noi programmatori non ce la facciamo. - Bob Murphy

Le persone lavorano su app di buone dimensioni. Mentre funzionano, i problemi di prestazioni si insinuano, proprio come i bug. La differenza è - i bug sono "cattivi" - gridano "trovami e correggimi". I problemi di prestazioni sono semplicemente lì e peggiorano. I programmatori spesso pensano "Bene, il mio codice non avrebbe un problema di prestazioni. Piuttosto, la direzione deve comprarmi una macchina più nuova / più grande / più veloce." Il fatto è che se gli sviluppatori periodicamente cercano solo problemi di prestazioni ( che in realtà è molto semplice ) potrebbero semplicemente eliminarli. - Mike Dunlavey

Quindi, se questo è un problema sociale, quali meccanismi sociali può mettere in atto un'organizzazione per evitare di spedire software lento ai propri clienti?

Con requisiti completi e scritti correttamente, non esiste una distinzione tra bug e prestazioni scadenti . Poiché si specifica la prestazione come requisito non funzionale, le scarse prestazioni diventano un bug proprio come qualsiasi altro bug e verranno rilevate 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, non ho mai visto un requisito non funzionale dire che un compito specifico deve svolgere al massimo N media secondi al . Se il gestore / cliente / stakeholder o qualsiasi altra cosa non si preoccupi della prestazione, perché io, come sviluppatore, mi preoccuperei, dal momento che alle persone che devono interessarsene non importa affatto?

C'è un altro fattore che influenza le scarse prestazioni: il fatto che gli sviluppatori lavorano su PC costosi che funzionano bene . Quando lavori da anni su un PC quad-core con 8 GB di RAM, un SSD di fascia alta, l'ultimo sistema operativo, ecc., È molto difficile immaginare come verrà eseguita l'applicazione su Windows XP su un PC dual-core con 512 Mo di RAM e un vecchio disco fisso riempito 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 sviluppatore e PC consumer, tanto più complicato è lo sviluppatore che si prende cura delle prestazioni della sua app.

Il problema(?):

• Il cliente (o l'utente finale) non si lamenta (abbastanza)
• Quindi il project manager (/ product) non lo considera un requisito
• Quindi lo sviluppatore non ha il tempo di ripararlo.

Devi iniziare all'inizio, educare i clienti. Ma se acquistano l'iPhone invece di un telefono più veloce e meno brillante, gli sviluppatori hanno ragione a dedicare il loro tempo agli sguardi anziché alle prestazioni. L'organizzazione non è il problema.

Certo, alcune cose possono comunque aiutare. Attendere i test automatici è fastidioso, quindi se si dispone di 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 funzionalità).

Ma non puoi fare tutto. Ottimizza o aggiunge funzionalità e decidono coloro che spendono i soldi.

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 in diretta invece di creare prima elenchi artificiali di funzionalità "obbligatorie", sono più rapidamente influenzate dalla reattività e quindi le prestazioni attireranno più attenzione.

Purtroppo, trovo che il problema maggiore sia che non puoi fare tutto. Hai una data di spedizione e sai che è lento, ma DEVI lanciare sul mercato le funzionalità X, Y, Z.

Nella tua mente, lentamente puoi aggiustarlo in seguito, ma l'app funziona almeno.

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

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

E il circolo vizioso continua.

Concordo con gli altri sul fatto che dovremmo trovare il modo di far sì che gli sviluppatori si preoccupino maggiormente del problema, come farli testare su hardware più lento e avere obiettivi di prestazione. Va tutto bene, ma in realtà, quando si tratta di tuning delle prestazioni -

Le persone devono sapere come - e non lo fanno

Potrebbero pensare di sì, ma basta guardare tutte le domande e le risposte relative alle prestazioni su StackOverFlow e su questo forum. È doloroso il fatto che molti mostrino ben poco buon senso per le prestazioni.

Non è qualcosa di cui parlare, le persone devono imparare facendolo . L'unica volta che sono in quella modalità è quando stanno seguendo una lezione o imparando cose nuove da un libro o un blog.

Quindi l'unico modo in cui riesco a pensare di risolvere questo problema è quello di afferrare le persone che insegnano la programmazione e insegnare loro come farlo.

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

• Il metodo super semplice di base
• A 43x SpeedUp - fare che con il profiler
• I motivi per cui, nei dettagli nauseabondi

Chiunque può farlo. Devono solo farlo davvero .

Rendi le prestazioni un requisito.

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

Tuttavia, quei programmatori sono ovviamente ancora utili per l'azienda, ma vengono assegnati a compiti non considerati critici per le prestazioni, quindi finisci con un lettore blu ray in grado di riprodurre flussi Netflix in modo impeccabile senza far cadere alcun fotogramma, ma ci vogliono 30-60 secondi per aprire la voce di menu che mostra la tua coda.

A meno che tu non sia una società di software hotshot che può permettersi di licenziare il 20% del tuo personale e sostituirlo con sviluppatori più esperti (e più costosi), l'unico vero modo per risolverlo è la formazione degli sviluppatori e la segnalazione di bug. Non so come sia in altre società, ma qui se noi sviluppatori riscontriamo un problema di prestazioni che non abbiamo tempo o priorità aziendale da risolvere, abbiamo il diritto di presentare la nostra segnalazione di bug. Potrebbero essere necessarie un paio di versioni per arrivare all'inizio del backlog, ma di solito vengono indirizzate alla fine.

Se la prestazione è un requisito, provalo.

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

Il test di accettazione del software deve disporre di un test di accettazione dettagliato per varie caratteristiche delle prestazioni operative.

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

Le prestazioni (come il consumo di risorse) dovrebbero essere iscritte in budget ai sottosistemi. Quindi i test di accettazione del sottosistema possono verificarli.

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

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

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

Ricordo una volta a metà degli anni '90 e stavo trascorrendo un po 'di tempo a cercare di ottimizzare qualcosa e un collega mi disse: "Funziona con i pentium, a chi importa?" .... quello mi ha aperto gli occhi. Purtroppo, era solo la punta dell'iceberg, ho sentito quell'atteggiamento nel corso della mia carriera, anche se la parte "pentium" è cambiata nel tempo.

L'unico modo per attirare lo sviluppatore medio è ottenere la mancanza di prestazioni da visualizzare 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 (velocemente, bene, velocemente - scegline due).

Ma non dovrebbe essere necessaria una lettera dal QA per un programmatore per rendersi conto che un ritardo di 3 secondi tra la pressione dei tasti e la risposta è inaccettabile

D'accordo non dovrebbe. Dovrebbe richiedere di più: una prova del 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 / controllo qualità sia causato dai loro problemi locali di accesso lento al disco / memoria / rete. In tal caso, il tuo QA e il tuo sviluppatore semplicemente sprecheranno i loro sforzi per sistemare cose che non contano per gli utenti finali.

Affidarsi agli sviluppatori nei test delle prestazioni è altrettanto produttivo quanto lanciare un dado per scegliere un pezzo di funzionalità per accelerare. Oh, ed è altrettanto affidabile - "gli sviluppatori hanno generalmente un'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 zoppicante ha deciso che i loro brillanti ragazzi di marketing e programmatori intelligenti sono abbastanza bravi da gestire i problemi di prestazioni dei clienti. Che grande lezione è stata. Rilascio respinto, un anno e mezzo di sforzi sono andati nel cestino e la società ha quasi perso un partner strategico. Alla fine, hanno invitato professionisti (esperti di benchmarking, statistiche, UX, ottimizzazione a basso livello, cose del genere) e professionisti che hanno risolto quel casino.

tutti i programmatori dovrebbero fare il proprio QA in modo da vedere immediatamente tali problemi?

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

• Come ex tester ho pensato una volta che non dovrebbe essere un problema combinare le attività di sviluppo e di controllo qualità. Sembrava che la differenza tra test di sviluppo di routine e QA sistematico non avesse molta importanza. Ho pensato che la separazione dev / QA sia 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 punto di riferimento e imposta le prestazioni target e farò del mio meglio per colpirlo. Non sono così bravo nei test delle prestazioni, ma ne so un paio di volte sull'ottimizzazione.

Penso che scoprirai che il 99% delle volte il problema è l'oscillazione dell'ambito. Con il dvr per esempio. Penseresti che sia facile ma poi TIVO o un concorrente introducono una nuova funzionalità che è ben accolta. La prossima cosa che sai che una nuova funzionalità è sulla piastra. Potrebbe essere o meno compatibile con il prodotto esistente e non stiamo rifacendo il prodotto esistente che richiederà troppo tempo. Quindi la funzione viene bloccata e fa schifo le prestazioni. Sicuramente i dati sono lì per ottenere l'informazione, ma se non si pensava di ottenere tali informazioni, ci sono buone probabilità che non sia facile da ottenere. Quindi ora ha un processo complesso per creare tali informazioni ogni volta che ti avvicini all'elenco dei programmi.

Ignorando 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.

ad es. Se è possibile misurare il tempo di risposta per la tua app (ad es. è un'applicazione basata sul Web o richiede un database, ecc.) - Stai attualmente ricevendo notifiche (e-mail, SMS o altro) che indicano il peggior "top 10" eseguire (o superare una determinata soglia) risposte?

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

Se tuttavia, ogni giorno / poche ore ricevi un'e-mail che indica che la schermata "x" richiede 13 secondi per il caricamento ed è in esecuzione la seguente query SQL, SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...ti conviene credere che uno sviluppatore potrebbe (e si spera lo farebbe) risolvere tutto esso.

Quindi, anche se mi piacerebbe credere che tutti i programmatori fanno prendere sul serio le prestazioni penso che la mancanza di visibilità alla questione (s) è spesso il colpevole.

Nota: penso che sia qualcosa a cui entrambi gli sviluppatori dovrebbero richiedere l'accesso (o addirittura sviluppare una tale funzionalità) e che la direzione dovrebbe fornire / finanziare tali strumenti.

Puoi fornire esempi migliori in cui possiamo effettivamente attribuire la colpa ai 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 relativo al codice ma legato all'ambiente.

I giorni di esecuzione di un programma su un computer in isolamento e la determinazione se è "veloce" o "lento" sono passati. 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 server gigabit ma alla fine abbiamo stabilito che tutto passava attraverso un antico dispositivo firewall con porte da 10 Mb. Questi problemi si spostano e sono difficili da trovare.

D'accordo, ci sono molte cose che i programmatori possono fare (minimizzare la larghezza di banda, 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 tutti i tipi di circostanze che impari solo per esperienza (e guardi le tue assunzioni crollare di fronte a te).

Quanto sei disposto a pagare per un software migliore? Quanto aspetterà il mercato 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 fallirà (o dovrebbe) il prodotto. Forse ci sono abbastanza clienti che possono convivere 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 faccia. Mi rendo conto anche che è un po 'fuori di testa.

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

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

L'esperienza di prima mano è importante. Offri agli sviluppatori un computer veloce per la compilazione e la compilazione, ma un computer sovraccarico molto lento (come una percentuale di utenti potrebbe effettivamente avere) su cui eseguire le loro app. (Questo può essere fatto in ambienti di sviluppo basati su cloud / server partizionando VM o server in base alla funzione.) Fornisci loro un telefono cellulare con una batteria scarica e richiede loro di usarlo solo per i test iniziali dell'app mobile per giorni.

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

Smetti di comprare le cose e commenta le scarse prestazioni di tutte le recensioni online che incontri.

Se i dispositivi continuano a vendere, il software è "abbastanza buono" per non investire più tempo e denaro. Se le recensioni negative sulle prestazioni riducono significativamente le vendite, il software "non è abbastanza buono" e deve essere riparato.

Le uniche metriche che interessano un produttore di beni di consumo sono le vendite e i profitti per unità.

Sono d'accordo che i programmatori dovrebbero essere istruiti meglio sulla massimizzazione delle prestazioni, ecc.

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

Poiché la mano successiva che gestirà il codice è il team di controllo qualità (testing), non sarebbe meglio insegnare loro sull'importanza delle prestazioni, avere uno standard di standard di prestazioni accettabili, ecc. Come standard aziendale (beh, nel mondo perfetto , lo standard di prestazione dovrebbe essere nelle specifiche ma ciò non accade molto spesso)? (vale a dire che la normale pagina / scheda che cambia ee aziendale dovrebbe avvenire immediatamente, "salva l'aggiornamento dovrebbe avvenire in x secondi", se si tratta di un'app critica quindi ...). Il computer in cui si trovano i team QA dovrebbe essere il tipico computer dell'utente. (non vogliamo farli incazzare dando loro un 386, ma non dare loro un quad core con 8 GB di RAM, ad esempio). Non si sfogerebbero con i programmatori se si arrabbiassero abbastanza con le prestazioni?

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

L'ho già detto prima, ma lo dirò di nuovo: penso che uno dei modi migliori per gestirlo sia semplicemente far lavorare gli sviluppatori su hardware (relativamente) marginale.

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

Se arriva al punto che il QA deve far rispettare le regole in cui gli sviluppatori non credono davvero perché ritengono che le prestazioni siano adeguate, è molto probabile che la maggior parte delle "correzioni" ottenute ottengano modi creativi per aggirare le regole, non correzioni reali che migliorano la vita per l'utente finale.

Allo stesso tempo, dovrei aggiungere che raramente ho visto questo come un problema. Semmai, ho visto gli sviluppatori passare troppo tempo a cercare di migliorare le prestazioni dove non avevo davvero abbastanza fastidio (un peccato di cui spesso sono anche colpevole).