Como as equipes de desenvolvimento podem impedir o desempenho lento nos aplicativos de consumo?

Quando perguntei anteriormente qual é o responsável pelo software lento, algumas respostas que recebi sugeriram que era um problema social e de gerenciamento:

Este não é um problema técnico, é um problema de marketing e gerenciamento ... Por fim, os gerentes de produto são responsáveis ​​por escrever as especificações para o que o usuário deve obter. Muitas coisas podem dar errado: o gerente de produto falha ao colocar a resposta do botão nas especificações ... O pessoal do controle de qualidade faz um trabalho medíocre de teste com as especificações ... se o gerenciamento de produtos e a equipe de controle de qualidade estiverem dormindo ao volante, nós programadores não podemos compensar isso. - Bob Murphy

As pessoas trabalham em aplicativos de bom tamanho. Enquanto trabalham, os problemas de desempenho aparecem, assim como os bugs. A diferença é - os erros são "ruins" - eles gritam "me encontre e me conserte". Os problemas de desempenho ficam lá e pioram. Os programadores costumam pensar "Bem, meu código não teria um problema de desempenho. Em vez disso, a gerência precisa me comprar uma máquina mais nova / maior / mais rápida". O fato é que, se os desenvolvedores periodicamente apenas buscarem problemas de desempenho (o que é realmente muito fácil ), eles podem simplesmente limpá-los. - Mike Dunlavey

Portanto, se esse é um problema social, quais mecanismos sociais uma organização pode implementar para evitar o envio de software lento para seus clientes?

Com requisitos completos e escritos corretamente, não existe distinção entre bugs e desempenho ruim . Como você especifica o desempenho como um requisito não funcional, o desempenho ruim se torna um bug como qualquer outro bug e será detectado pelo controle de qualidade e resolvido pelos desenvolvedores antes do lançamento.

Existe algum problema social? Acho que não. A principal questão é que os requisitos estão incompletos. Trabalhando por anos como freelancer, nunca vi um requisito não funcional informando que uma tarefa específica deve ser executada em no máximo N segundos, em média. Se o gerente / cliente / parte interessada ou o que quer que seja que não se importe com ativos de desempenho, por que eu, como desenvolvedor, me incomodaria com isso, pois as pessoas que precisam se preocupar com isso não se importam?

Há outro fator que influencia o desempenho ruim: o fato de os desenvolvedores trabalharem em PCs caros com bom desempenho . Quando você trabalha há anos em um PC quad-core com 8 GB de RAM, um SSD de ponta, o sistema operacional mais recente etc., é muito difícil imaginar como o aplicativo será executado no Windows XP em um PC dual core com 512 Mo de RAM e um disco rígido antigo preenchido a 90% e não desfragmentado por anos. Infelizmente, em alguns países, o último caso é o que vemos para a maioria dos consumidores de um aplicativo. Quanto maior a diferença entre PCs de desenvolvedor e PCs de consumidor, mais complicado é para um desenvolvedor cuidar do desempenho de seu aplicativo.

O problema(?):

• O cliente (ou usuário final) não reclama (o suficiente)
• Portanto, o gerente de projeto (/ produto) não considera um requisito
• Portanto, o desenvolvedor não tem tempo para corrigi-lo.

Você tem que começar do início, educar os clientes. Mas se eles compram o iPhone em vez de um telefone mais rápido e menos brilhante, os desenvolvedores têm razão em gastar seu tempo com aparência e não com desempenho. A organização não é o problema.

Claro, algumas coisas podem ajudar de qualquer maneira. Aguardar testes automatizados é irritante; portanto, se você tiver testes automatizados, os desenvolvedores terão um feedback constante sobre problemas de desempenho e será mais provável que eles sejam resolvidos (como um problema técnico, não como um recurso).

Mas você não pode fazer tudo. É otimizar ou adicionar recursos, e quem gasta o dinheiro decide.

Mas algumas boas notícias: notei que os aplicativos SaaS / Cloud / Buzzword ajudam muito aqui. Quando as pessoas escolhem entre alguns aplicativos da Web semelhantes e testam ao vivo, em vez de criarem listas artificiais de recursos "necessários", elas são mais rapidamente influenciadas pela capacidade de resposta e, portanto, o desempenho recebe mais atenção.

Infelizmente, acho que o maior problema é que você não pode fazer tudo. Você tem uma data de envio e sabe que é lento, mas PRECISA colocar os recursos X, Y, Z no mercado.

Em sua mente, devagar, você pode corrigir mais tarde, mas pelo menos o aplicativo funciona.

Portanto, você se preocupa com a funcionalidade e a estética (porque os usuários se concentram na estética com frequência). Na próxima versão, você corrigirá o desempenho.

Mas o PM apenas fornece uma lista de recursos, e não há tempo para corrigir o desempenho.

E o círculo vicioso continua.

Concordo com outras pessoas que devemos encontrar maneiras de fazer com que os desenvolvedores se preocupem mais com o problema, como testá-los em hardware mais lento e ter objetivos de desempenho. Tudo bem, mas realmente, quando se trata de ajuste de desempenho -

As pessoas precisam saber - e não sabem

Eles podem pensar que sim, mas basta examinar todas as perguntas e respostas relacionadas ao desempenho no StackOverFlow e neste fórum. É doloroso quantos demonstrem muito pouco senso comum sobre desempenho.

Não é algo para se falar, as pessoas precisam aprender fazendo isso. A única vez que eles estão nesse modo é quando estão participando de uma aula ou aprendendo coisas novas de um livro ou blog.

Portanto, a única maneira de pensar para resolver esse problema é contatar as pessoas que ensinam programação e ensiná- las a fazê-lo.

Deus sabe, eu tentei nesses fóruns, como em -

• O método básico super simples
• Uma aceleração de 43x - faça isso com seu profiler
• As razões pelas quais, em detalhes nauseantes

Qualquer um pode fazer isso. Eles só precisam fazer isso.

Faça do desempenho um requisito.

Escrever código de desempenho é difícil. Requer uma sólida compreensão de conceitos como encadeamento, manipulação de eventos assíncronos, armazenamento em cache e complexidade assintótica. A julgar pelos grupos de programadores com quem trabalhei, cerca de 20 a 40% de qualquer grupo não entende esses conceitos o suficiente para incorporar considerações de desempenho como uma questão de curso em seu trabalho diário.

No entanto, obviamente, esses programadores ainda são úteis para a empresa, mas são atribuídos a tarefas que não são consideradas críticas para o desempenho; portanto, você acaba com um reprodutor de blu ray capaz de reproduzir fluxos da Netflix na perfeição, sem perder nenhum quadro, mas leva de 30 a 60 segundos. para abrir o item de menu que exibe sua fila.

A menos que você seja uma empresa de software de primeira linha que pode dar ao luxo de demitir 20% de sua equipe e substituí-los por desenvolvedores mais experientes (e mais caros), a única maneira real de corrigi-lo é o treinamento do desenvolvedor e a apresentação de relatórios de erros. Não sei como é em outras empresas, mas aqui, se os desenvolvedores virem um problema de desempenho que não temos tempo ou prioridade de negócios para corrigir, temos o direito de arquivar nosso próprio relatório de erro. Pode levar algumas versões para chegar ao topo da lista de pendências, mas elas geralmente são abordadas eventualmente.

Se o desempenho é um requisito, teste-o.

Caso contrário, Wally pode escrever um loop infinito e sair mais cedo "Demora um pouco". Ele pode reivindicar.

Seu teste de aceitação de software deve ter um teste de aceitação detalhado para várias características de desempenho da operação.

Se você não fizer isso, não estará projetando nenhum desempenho no produto.

O desempenho (como o consumo de recursos) deve ser orçado em subsistemas. Em seguida, os testes de aceitação do subsistema podem verificá-los.

Em seguida, você pode testar cedo e frequentemente o desempenho. Mesmo os testes de unidade podem verificar.

Portanto, agora os desenvolvedores o têm como critério de aceitação e podem organizar sua abordagem de acordo com ele.

Onde estou trabalhando agora, o teste de estresse de desempenho é duas vezes maior do que qualquer conjunto de dados de clientes que conhecemos. Ele interrompe regularmente uma nova versão do produto. Bom teste.

Lembro-me de uma vez em meados dos anos 90 e estava passando algum tempo tentando otimizar alguma coisa, e um colega de trabalho me disse: "Isso está funcionando com pentiums, quem se importa?" .... isso foi um revelador. Infelizmente, foi apenas a ponta do iceberg, ouvi essa atitude ao longo da minha carreira - embora a parte "pentium" tenha mudado ao longo do tempo.

A única maneira de fazer com que o desenvolvedor médio se preocupe é fazer com que a falta de desempenho seja vista como um bug por parte do cliente. Dependendo do aplicativo e do público-alvo, isso pode ser uma tarefa fácil ou difícil (eu já vi os dois). Se o público não se importa com o fraco desempenho, os desenvolvedores nunca o farão (rápido, bom, rápido - escolha dois).

Mas não deve ser necessária uma carta do controle de qualidade para um programador perceber que um atraso de 3 segundos entre pressionamento de tecla e resposta é inaceitável

Concordo que não deveria. Deve demorar mais do que isso: uma prova de que o atraso obtido é relevante para os usuários finais .

Como você não forneceu contexto, parece inteiramente possível que o atraso no ambiente de desenvolvimento / controle de qualidade seja causado por problemas locais de acesso lento ao disco / memória / rede. Se for esse o caso, seu controle de qualidade e desenvolvedor simplesmente desperdiçarão esforços para consertar coisas que simplesmente não importam para os usuários finais.

Contar com desenvolvedores em testes de desempenho é tão produtivo quanto lançar um dado para escolher uma parte da funcionalidade para acelerar. Ah, e é tão confiável quanto isso - "os desenvolvedores geralmente têm uma intuição horrível sobre onde realmente estarão os problemas de desempenho em um aplicativo" ( Brian Goetz ).

• Eu estive em um projeto em que o gerenciamento manco decidiu uma vez que seus brilhantes profissionais de marketing e programadores inteligentes são bons o suficiente para lidar com as preocupações de desempenho dos clientes. Que grande lição foi essa. Liberação rejeitada, meio ano de esforços para a lixeira, e a empresa quase perdeu um parceiro estratégico. No final, eles convidaram profissionais (especialistas em benchmarking, estatística, UX, otimização de baixo nível, coisas assim) e profissionais consertaram essa bagunça.

todos os programadores devem fazer seu próprio controle de qualidade para ver esses problemas imediatamente?

O fato de ser factível não significa que é o caminho a percorrer. Pelo contrário, na minha experiência, essa foi uma das maneiras mais confiáveis ​​de perder a produtividade dos programadores . Quase tão bom quanto reuniões intermináveis ​​e ainda melhor do que entrevistar candidatos.

• Como ex-testador, uma vez pensei que não deveria ser um problema combinar atividades de desenvolvimento e controle de qualidade. Parecia que a diferença entre o teste de rotina do desenvolvedor e o controle de qualidade sistemático não importaria muito. Eu pensei que a separação dev / QA é apenas uma tradição na indústria de software. Aprendeu da maneira mais difícil que isso não é assim. A separação acabou sendo uma questão de foco e produtividade, e bastante séria.

Se houver um problema de desempenho, forneça uma referência e defina o desempenho desejado, e farei o possível para alcançá-lo. Eu não sou tão bom em testes de desempenho, mas sei um pouco ou dois sobre otimização.

Eu acho que você descobriria que 99% das vezes o problema é o escopo. Com o dvr por exemplo. Você acha que isso é fácil, mas a TIVO ou um concorrente apresenta um novo recurso que é bem recebido. A próxima coisa que você sabe é que um novo recurso está no prato. Pode ou não ser compatível com o produto existente e não estamos refazendo o produto existente que levará muito tempo. Portanto, o recurso fica preso e prejudica o desempenho. Certifique-se de que existem dados para obter as informações, mas se não foi possível obter essas informações, há uma boa chance de que não será fácil obter essas informações. Portanto, agora ele tem um processo complexo para criar essas informações sempre que você se aproxima da lista de programas.

Ignorando os desenvolvedores que parecem não se importar ...

Eu acho que muitas vezes os desenvolvedores que trabalham no código não têm as ferramentas para medir o desempenho continuamente.

Por exemplo, se é possível medir o tempo de resposta do seu aplicativo (por exemplo, é um aplicativo baseado na Web ou consulta um banco de dados, etc.) - Você está recebendo notificações no momento (e-mail, SMS, o que for) que indicam os "10 principais" piores executando (ou acima de um determinado limite) respostas?

Em muitos casos, os desenvolvedores não estão recebendo essas informações das implantações do "mundo real" e, como resultado, é muito fácil ignorar as informações que você não vê.

Se, no entanto, todos os dias / poucas horas você receber um e-mail indicando que a tela "x" leva 13 segundos para carregar e estiver executando a seguinte consulta SQL, SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...é melhor acreditar que um desenvolvedor pode (e esperamos) ser corrigido isto.

Assim, embora eu gostaria de acreditar que todos os programadores fazer desempenho levar a sério eu acho que a falta de visibilidade ao tema (s) é muitas vezes o culpado.

Nota: Eu acho que isso é algo que os desenvolvedores devem solicitar acesso (ou mesmo desenvolver esse recurso) e a gerência deve fornecer / financiar essas ferramentas.

Você pode apresentar melhores exemplos em que podemos culpar os programadores? Além do Eclipse, e um comentarista já apontou que são os plug-ins que fazem isso (minha primeira instalação de cada nova versão do Eclipse funciona como um raio, mas quando eu adiciono as outras ferramentas, ela começa a ficar lenta), seus exemplos podem não ser programadores e relacionado ao código, mas relacionado ao ambiente.

Os dias de execução de um programa em um computador isoladamente e a determinação de se é 'rápido' ou 'lento' se foram. Os outros exemplos que você dá dependem do ambiente deles - o congestionamento atual da rede, se os servidores de back-end estão sobrecarregados, placas de rede mal configuradas, um cabo com defeito, o número de outras pessoas que o utilizam nas proximidades ou centenas de outras variáveis. por exemplo. nosso provedor de hospedagem cobrava extra pelas conexões de gigabit do servidor, mas eventualmente determinamos que tudo passava por um antigo dispositivo de firewall com portas de 10 Mb. Esses problemas mudam e são difíceis de encontrar.

De acordo, há muitas coisas que os programadores podem fazer (minimizando a largura de banda, os truques da interface do usuário que melhoram a capacidade de resposta e mostram o progresso para dar a impressão de que é rápido). Mas quando você se lança para o mundo real, existem todos os tipos de circunstâncias que você apenas aprende por experiência (e observa suas suposições desmoronarem à sua frente).

Quanto você está disposto a pagar por um software melhor? Quanto o mercado espera por um software melhor? Quão pequena quantidade de lixo deseja adicionar à próxima versão?

É um mercado difícil, onde muitos compromissos são feitos. Se for realmente uma porcaria, o mercado (ou deveria) falhar no produto. Talvez existam clientes suficientes que possam viver com o status quo?

Eu acho que a resposta mais geral para esse problema também é a mais difícil de gerenciar, que é que todo programador deve estar atento ao desempenho com qualquer coisa que faça. Sei também que isso é um pouco fora de controle.

Dependendo do tamanho do projeto e da equipe correspondente, acredito que pode haver muito valor em ter programadores de desempenho dedicados.

Como exemplo, trabalhei em uma equipe em que a equipe do projeto (incluindo cerca de 30 desenvolvedores) tinha pelo menos 2 pessoas dedicadas à otimização de desempenho. Esse aplicativo em particular também era propenso a problemas de desempenho, pois havia vários componentes de interoperabilidade, não apenas nos serviços da Web, mas também em termos de camadas herdadas com vários componentes de adaptador e mapeamento de dados.

Experiência em primeira mão é importante. Ofereça aos desenvolvedores um computador rápido para compilar e construir, mas um computador sobrecarregado muito lento (como pode ser uma porcentagem dos usuários) para executar os aplicativos. (Isso pode ser feito em ambientes de desenvolvimento baseados em nuvem / servidor particionando VMs ou servidores por função.) Dê a eles um telefone celular com meia bateria descarregada e exija que eles o usem apenas nos dias em que os testes de aplicativos móveis começarem.

Se os desenvolvedores simpatizarem com o cliente em relação ao desempenho e à duração da bateria, eles não considerarão o desempenho como uma especificação de gerenciamento semi-falsa para colocar no final da lista de prioridades. (Como em: "ei, eu pensei que era otimização prematura" até tarde demais.)

Pare de comprar as coisas e comente o fraco desempenho de todas as avaliações on-line que você encontrar.

Se os dispositivos ainda estiverem vendendo, o software é "bom o suficiente" para não investir mais tempo e dinheiro. Se críticas negativas sobre o desempenho reduzem significativamente as vendas, o software "não é bom o suficiente" e precisa ser corrigido.

As únicas métricas que interessam a um produtor de bens de consumo são vendas e lucro por unidade.

Concordo que os programadores devem aprender melhor a maximizar o desempenho, etc.

Mas acho que a solução não está dando aos programadores um hardware quase morto para uso diário. Quão estressante será se o seu estúdio visual travar duas vezes por dia, levou x segundos para criar o material, y segundos para abrir a solução, z segundos para mudar as janelas. Não acho que tenha sido muito econômico para a empresa, pois o hardware é barato e o tempo dos programadores é caro.

Como a próxima mão que manipulará o código é a equipe de controle de qualidade (teste), não seria melhor ensiná-los sobre a importância do desempenho, ter um padrão do padrão de desempenho aceitável etc. como padrão da empresa (bem, no mundo perfeito , o padrão de desempenho deve estar nas especificações, mas isso não acontece com muita frequência)? (ou seja, a página / guia comum de mudança de ee da empresa deve acontecer instantaneamente, "salvar a atualização deve ocorrer em x segundos", se for um aplicativo crítico ...). O computador em que as equipes de controle de qualidade executam deve ser o computador típico do usuário. (nós não queremos irritá-los, dando-lhes um 386, mas não lhes damos um quad core com 8 GB de RAM, por exemplo). Eles não desabafariam com os programadores se ficassem chateados o suficiente com o desempenho?

Acho que o cliente / gerente de projeto deve forçar o programador / equipe de qa / desenvolvedor / representante da equipe da empresa a fazer sua apresentação com o hardware típico mais baixo que eles possuem. (o computador mais fraco da empresa, por exemplo). Se for reescrita, eles precisarão coletar dados sobre a rapidez com que é x processar no software antigo e compará-lo com a rapidez com que é no novo software (pode ser mais lento, pois o novo software pode envolver processos de negócios extras, mas deve haver uma janela aceitável).

Eu já disse isso antes, mas vou repetir: acho que uma das melhores maneiras de lidar com isso é simplesmente fazer com que seus desenvolvedores trabalhem em hardware (relativamente) de ponta.

Para o seu programador típico, a maioria das considerações oficiais de desempenho são secundárias a simplesmente: "é irritante quando tento executá-lo?" Se eles acharem isso irritante, eles (pelo menos tentarão) consertar. Se eles estão satisfeitos com a forma como funciona, o melhor que você obtém é uma tentativa tímida de consertar. Isso também ajuda a encontrar problemas mais cedo, antes que eles se tornem muito mais caros para consertar.

Se chegar ao ponto em que o controle de qualidade precisa impor regras nas quais os desenvolvedores realmente não acreditam porque acham que o desempenho é adequado, as chances são muito boas de que a maioria das "correções" recebidas tenha formas criativas de contornar as regras, correções não reais que melhoram a vida do usuário final.

Ao mesmo tempo, devo acrescentar que raramente vejo isso como um problema. Na verdade, vi desenvolvedores gastando muito tempo tentando melhorar o desempenho, onde eu realmente não importava o suficiente para me incomodar (um pecado do qual também sou frequentemente culpado).