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

32

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?

Crashworks
fonte
2
Isso me lembrou um post recente de Jeff Atwood .
rahmu
2
Comentaristas: se você gostou da pergunta, faça um voto positivo. Se você tiver uma resposta, deixe-a como resposta , não como um comentário. Caso contrário, deixe um comentário apenas se achar que a pergunta foi esclarecida ou melhorada ou se você tiver um link para um recurso relacionado.

Respostas:

34

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.

MainMa
fonte
2
Seguindo esse comentário, acho que a melhor maneira de garantir que pelo menos os desenvolvedores (e testadores) estejam bem cientes desses problemas é testá-los SEMPRE na extremidade inferior mais antiga dos requisitos de hardware ou nas Máquinas Virtuais . Como desenvolvedor, é difícil para mim dizer essas palavras, mas algumas vezes não trabalhamos para corrigir um problema até experimentá-lo por nós mesmos. Portanto, pelo menos, forçar seus desenvolvedores a testar seus aplicativos em sistemas inferiores, forçará-os a encontrar soluções eficientes devido ao baixo desempenho que eles experimentam diretamente.
RLH 28/09
3
Eu não sugeriria isso diariamente, pois diminuirá o desempenho geral do departamento de controle de qualidade e deprimirá os funcionários que trabalham em máquinas lentas. IMHO, colocar métricas de desempenho como requisitos é suficiente, se especificado corretamente (ou seja, em qual máquina o teste automático de desempenho deve ser realizado, com qual carga, quantas vezes uma média, etc.).
Arseni Mourzenko
1
Eu trabalho com um requisito que tem um requisito de desempenho formal (não funcional). É um software essencial para a vida em tempo real. As especificações são "resposta dentro de x em média e y 95% do tempo". O software ainda é lento comparado ao que poderia ser, mas sabemos quando melhorar o desempenho, pois ele se torna um defeito, assim como qualquer outra coisa que o sistema faz incorretamente. Deixar os desenvolvedores decidirem é uma péssima idéia. A maioria dos desenvolvedores, deixada para lá, possui dispositivos, faz engenharia em todos os aspectos e o triplica com preocupações de desempenho.
mattnz
3
Outro problema com o desempenho é que você não pode testar o desempenho em nada além de um sistema trivial até que a integração final seja concluída, geralmente muito tempo depois que os desenvolvedores de software terminarem seu trabalho. Tome um aplicativo de telefone - funciona bem no nu-ossos brilhante fábrica novo telefone, como alguns aplicativos baixados e a memória fica cheia, eo desenvolvedor de software é acusada de escrever software de baixa qualidade ......
mattnz
2
O problema aqui é que você NUNCA obtém "requisitos escritos e completos corretamente". Não em um aplicativo de qualquer tamanho ou complexidade.
CaffGeek 29/09
12

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.

Jaap
fonte
Eu sei disso muito bem, apenas cronometrando +1
mKorbel 28/09
8

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.

CaffGeek
fonte
3
Isso só é corrigido quando o PM fornece um "recurso" chamado "desempenho aprimorado"!
FrustratedWithFormsDesigner
4
Até o momento a PM quer melhorar o desempenho, a única maneira real para fazê-lo é uma reescrita :)
O ponto principal aqui é que, para a maioria dos aplicativos de consumo, o desempenho não é um recurso que vende software. Não é algo que parece brilhante na lista de verificação "Coisas que este software faz". Jogos de computador são um exemplo brilhante desse pensamento. Os requisitos de sistema para jogos aumentaram constantemente ao longo do tempo, o que significa que os novos jogos são mais lentos com o mesmo hardware que você possuía antes, porque uma taxa de quadros maior não moverá essa caixa da prateleira, mas ambientes realistas renderizados em tempo real com detalhes fractais vai ... #
29511 Malachi
1
+1 Aqui é onde realmente ajuda ter um concorrente com bom desempenho. Quando os PMs veem isso, ficam assustados e pedem para você fazer algo a respeito.
precisa saber é o seguinte
1
@ Chade, a probabilidade condicional é alta, mas a absoluta é baixa. Eu trabalho em um aplicativo que começou como um programa C de 16 bits para a versão Windows "pouco depois de eu nascer". Avance rapidamente para hoje e muitos anos e dezenas de programadores mais tarde, você terá uma mistura de C, C ++, C #, VB.Net e muitos fornecedores de SQL. Reescrever algumas partes-chave do aplicativo na F # não soa como uma idéia terrível agora ...
4

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 -

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

Mike Dunlavey
fonte
4

Faça do desempenho um requisito.

Robert Harvey
fonte
+1: é tão simples quanto isso. "A função X deve ser concluída em milissegundos Y".
não se esqueça de especificar o ambiente em que será executado - por exemplo, temos um NFR que executaria com um padrão quando executado em uma rede com latência de 40ms (ou seja, uma WAN). Caso contrário, os desenvolvedores apresentarão algo que só funciona bem em um supercomputador.
Gbjbaanb
2

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.

Karl Bielefeldt
fonte
Além disso, até grandes programadores precisam de ótimas ferramentas de instrumentação e perfil para obter informações sobre problemas de desempenho. (Existem muitos paradigmas de programação com características de desempenho que desafiam a análise de rastreamento de pilha.) Essas ferramentas geralmente estão disponíveis para plataformas Linux no estilo de código aberto, mas em plataformas proprietárias e personalizadas, essas ferramentas são frequentemente negadas aos funcionários.
Rwong 29/09
Eu discordo do sentimento expresso. Obter o máximo de desempenho pode ser muito difícil, mas muitas vezes há muitas frutas baixas a serem consumidas. Portanto, faça alguns perfis simples (talvez a técnica sugerida por Mike Dunlavey acima) e tente corrigir os problemas óbvios. Muitas vezes, isso irá percorrer um longo caminho.
precisa saber é o seguinte
2

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.

Tim Williscroft
fonte
2

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

geoffjentry
fonte
2

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.

gnat
fonte
downvoter - aconteceu com você trabalhar com testadores profissionais, cobrindo as necessidades da equipe de desenvolvimento no controle de qualidade e nos testes de desempenho? Se não, considerar dar-lhe uma tentativa
mosquito
1

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.

SoylentGray
fonte
1

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.

scunliffe
fonte
1

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

jqa
fonte
Os exemplos que dei foram todos os casos em que o desempenho foi ruim em um ambiente puramente local - o DVR fica apenas navegando no menu de programas gravados localmente. O iTunes é lento apenas navegando nos dados locais, sem olhar para a loja. Mesmo no "modo avião" - sem nenhuma rede - o iPhone 3G leva tanto tempo para exibir fotos que, às vezes, o cão de guarda do sistema operacional mata o aplicativo antes de iniciar. Todos esses são exemplos de casos em que os programadores sabiam exatamente qual hardware eles estavam alvejando quando escreveram o código e o iPhone, especialmente porque fica pior a cada atualização.
Crashworks
@Crashworks - alguém removeu esses exemplos da sua pergunta. Você pode adicioná-los novamente com detalhes? O exemplo de foto parece que algo está acontecendo, como falta de dependência ou está tentando procurar algo na Internet e atingindo o tempo limite. Você executou uma depuração para ver o que está acontecendo? Uma boa história é quando a MS lançou o HyperV, um revisor do VMWare apontou com satisfação que, embora o tenha instalado no dia seguinte ao lançamento, ele teve que baixar um monte de atualizações do Windows. Por quê? o processo de ativação do HyperV reutilizou uma DLL do IE8. Existem muitas dicas em ambientes modernos.
jqa 29/09/11
1

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?

Paddy3118
fonte
0

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.

Wayne Koorts
fonte
0

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

hotpaw2
fonte
0

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.

James Anderson
fonte
0

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

Squee
fonte
-1

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

Jerry Coffin
fonte
1
É fácil cair na armadilha de ficar obcecado com coisas que não importa, mas se um telemóvel vem com uma interface tão lento que as chamadas recebidas para a caixa postal antes de a "resposta" responde botão, claramente alguém não conseguiu melhorar o desempenho quando se fez importam.
Crashworks
4
Nesse caso, a empresa deve me comprar uma espada decente, porque vou passar a maior parte do tempo compilando.
David Thornley
Metade do problema é que é difícil testar em uma máquina de desenvolvimento. As máquinas Dev tendem a ser grandes e rápidas, portanto, um desenvolvedor nunca pode ver o problema. É difícil consertar alguma coisa se você não pode ver a medida (afetada) do problema e muito menos como a sua correção mudará o comportamento.
Martin York
7
Isso foi sugerido em um comentário do Slashdot (sobre algo) anos atrás. A resposta foi: "os desenvolvedores devem desenvolver em máquinas rápidas e testar em máquinas lentas".
user16764
1
@ user16764: Muitas vezes, é dada pouca atenção a dar aos desenvolvedores ambientes de teste diferentes do ambiente de desenvolvimento. Minha esposa teve muita dificuldade em obter uma conta de administrador (para desenvolver) e uma conta mais limitada (para teste), e antes disso tinha problemas constantes ao colocar acidentalmente algo em uma correção de manutenção que não era executada em um usuário comum conta.
David Thornley