É porque todos eles foram escritos em idiomas gerenciados e coletados pelo lixo em vez de código nativo?
Não. O código lento terá um desempenho ruim, independentemente. Certamente, um idioma específico pode introduzir certas classes de problemas enquanto resolve outros. Mas bons programadores são capazes de encontrar soluções alternativas, com tempo suficiente.
Foram os programadores individuais que escreveram o software para esses dispositivos?
Parcialmente. Em muitos casos, é bem provável que seja pelo menos um fator contribuinte. Esse é um efeito colateral lamentável de um setor em que bons programadores têm alta demanda e pouca oferta. Também os abismos entre vários níveis de habilidade técnica podem ser bastante grandes. Portanto, é lógico que, às vezes, os programadores encarregados de implementar determinado software podem ser parabenizados apenas por fazê-lo funcionar (mais ou menos).
Em todos esses casos, os desenvolvedores de aplicativos sabiam exatamente qual plataforma de hardware eles estavam alvejando e quais eram seus recursos; eles não levaram isso em conta?
Parcialmente. Para começar, a plataforma de hardware exata provavelmente não é conhecida, pois é frequentemente negociada com vários fabricantes em paralelo durante o desenvolvimento do software. De fato, pode haver pequenas alterações (mas não necessariamente insignificantes) no hardware subjacente após o lançamento inicial. No entanto, eu concordo que as capacidades gerais serão conhecidas.
Parte do problema é que o software provavelmente não é desenvolvido no hardware, é feito em emuladores. Isso dificulta a contabilização do verdadeiro desempenho do dispositivo, mesmo que os emuladores sejam 100% precisos - o que não é.
Obviamente, isso realmente não justifica testes insuficientes no hardware de protótipo apropriado antes do lançamento. Essa culpa provavelmente está fora do controle dev / qa.
É o cara que anda por aí repetindo "a otimização é a raiz de todo mal", ele os desviou?
Não. Tenho certeza de que eles não o escutam; caso contrário, ele não seria citado com tanta frequência (isso deveria ser " otimização prematura ..."). :-D
É mais provável que muitos programadores tomem um dos dois extremos com relação à otimização.
- Ou eles o ignoram completamente.
- Ou eles se obcecam com minúcias que nada têm a ver com os requisitos reais de desempenho. O efeito líquido é que o orçamento se esgota e o código é ofuscado demais para otimizar com segurança os problemas reais de desempenho.
Era uma mentalidade de "oh, são apenas 100ms adicionais" a cada vez, até que todos esses milissegundos somam minutos?
Possivelmente. Obviamente, se Sleep(100)
foi usado como o equivalente ao papel de seda usado para retardar o sangramento de um membro cortado - então os problemas são esperados. No entanto, suspeito que o problema seja mais sutil do que isso.
O problema é que o hardware de computação moderno (incluindo dispositivos incorporados) é muito mais rápido do que as pessoas lhes dão crédito. A maioria das pessoas, mesmo os programadores "experientes", não conseguem avaliar a rapidez com que os computadores são. 100ms é muito tempo - muito tempo . E, por assim dizer, esse "tempo muito longo" corta duas maneiras:
- A primeira é que os programadores se preocupam desnecessariamente com as coisas que um computador faz com extrema rapidez. (Acontece que foi apenas uma preocupação " incrementar um valor 300 vezes por segundo " que me levou aqui em primeiro lugar.)
- A segunda é que, às vezes, deixam de mostrar a devida preocupação quando as coisas demoram muito tempo (na escala de tempo da computação). Tão:
- se eles ignoram os efeitos da latência ao se comunicar através de uma rede ou com um dispositivo de armazenamento;
- se eles ignoram o impacto de um encadeamento bloqueado e aguardam outro encadeamento;
- se eles esquecerem que, como os computadores funcionam tão rapidamente, é muito capaz de repetir uma tarefa com muito mais frequência do que deveria, sem que o desenvolvedor esteja ciente de um problema
- ... se ocorrer uma combinação dessas omissões, uma rotina será executada inesperadamente muito lentamente (na escala de tempo da computação). Algumas repetições e até serão perceptíveis pelos seres humanos - mas pode ser difícil de definir porque centenas de coisas interconectadas estão correndo rapidamente sozinhas.
É minha culpa, por ter comprado esses produtos em primeiro lugar?
Sim definitivamente. Bem, você não pessoalmente, mas os consumidores em geral. Os produtos são vendidos (e comprados ) por listas de verificação de recursos. Poucos consumidores estão exigindo melhor desempenho.
Para ilustrar meu argumento: a última vez que eu quis comprar um telefone celular, a loja não conseguiu nem oferecer um modelo de demonstração para brincar na loja. Tudo o que tinham eram conchas de plástico com adesivos para mostrar como seria a tela. Você não pode nem sentir o peso dessa maneira - muito menos desempenho ou usabilidade. O que quero dizer é que, se um número suficiente de pessoas se opuser a esse modelo de negócios e votar com suas carteiras para expressar sua objeção, seríamos um pequeno passo na direção certa.
Mas eles não, então não somos; e todos os anos, os novos telefones celulares ficam mais lentos em hardware mais rápido.
(As perguntas não foram feitas.)
- O pessoal de marketing é o culpado? Parcialmente. Eles precisam de datas de lançamento. E quando essa data se aproxima, a escolha entre "fazê-lo funcionar" e "torná-lo mais rápido" é fácil.
- Os vendedores são os culpados? Parcialmente. Eles querem mais recursos na lista de verificação. Eles exageram nas listas de recursos e ignoram o desempenho. Eles (às vezes) fazem promessas irreais.
- Os gerentes são os culpados? Parcialmente. Gerentes inexperientes podem cometer muitos erros, mas mesmo gerentes muito experientes podem (com razão) sacrificar tempo para resolver problemas de desempenho em favor de outras preocupações.
- As especificações são as culpadas? Parcialmente. Se algo for deixado de fora da especificação, será muito mais fácil "esquecê-lo" mais tarde. E se não for indicado especificamente, qual é o objetivo? (Embora eu pessoalmente acredite que, se uma equipe se orgulha de seu trabalho, ela se preocupa com o desempenho, independentemente disso.)
- Culpa a educação? Talvez. Provavelmente, a educação sempre estará no pé traseiro. Eu certamente desaprovo a "educação" que produz rapidamente iniciantes com um desenvolvimento superficial de software de entendimento. No entanto, a educação que é apoiada pela teoria e instila uma cultura de aprendizado não pode ser ruim.
- As atualizações são as culpadas? Parcialmente. Novo software, hardware antigo realmente é destino tentador. Mesmo antes do lançamento da versão X, X + 1 está em planejamento. O novo software é compatível, mas o hardware antigo é rápido o suficiente? Foi testado? Uma correção de desempenho específica pode ser incorporada no novo software - incentivando uma atualização de software não recomendada.
Basicamente, acredito que existem muitos fatores que contribuem. Infelizmente, não há bala de prata para consertá-lo. Mas isso não significa que é desgraça e melancolia. Existem maneiras de contribuir para melhorar as coisas.
Então, em que ponto as coisas deram errado para esses produtos?
IMHO não podemos realmente identificar nenhum ponto único. Existem muitos fatores contribuintes que evoluíram ao longo do tempo.
- Contadores de feijão: redução de custos, timing do mercado. Mas, novamente, teríamos feito os avanços que alcançamos sem a pressão?
- Alta demanda e baixa oferta de pessoas qualificadas na indústria. Não apenas programadores, mas também gerentes, testadores e até vendedores. A falta de habilidades e experiência leva a erros. Mas, novamente, isso também leva ao aprendizado.
- Tecnologia de ponta. Até uma tecnologia amadurecer, ela irá morder regularmente de maneiras inesperadas. Mas, novamente, muitas vezes fornecia várias vantagens em primeiro lugar.
- Complicação composta. Com o tempo, a indústria evoluiu: adicionando mais ferramentas, tecnologias, camadas, técnicas, abstrações, hardware, idiomas, variação, opções. Isso torna um tanto impossível ter uma compreensão "completa" dos sistemas modernos. No entanto, também somos capazes de fazer muito mais em um tempo muito menor como resultado.
O que nós, como programadores, fazemos para evitar infligir essa dor a nossos próprios clientes?
Tenho algumas sugestões (técnicas e não técnicas) que podem ajudar:
- No sofar possível, use seu próprio produto. Não há nada como a experiência em primeira mão para revelar coisas estranhas, lentas ou inconvenientes. No entanto, você precisará evitar conscientemente contornar as deficiências devido ao "conhecimento interno". Por exemplo, se você não tiver problemas para sincronizar contatos porque o faz com um script Python backdoor - você não está usando "o produto". O que traz o próximo ponto ...
- Ouça seus usuários (de preferência em primeira mão, mas pelo menos em segunda mão através do suporte). Eu sei que programadores (geralmente) preferem ficar escondidos e evitar a interação humana; mas isso não ajuda a descobrir os problemas que outras pessoas enfrentam ao usar seu produto. Por exemplo, você pode não perceber que as opções do menu são lentas, porque você conhece todos os atalhos e os utiliza exclusivamente. Mesmo que o manual documente completamente todos os atalhos, algumas pessoas ainda preferem os menus - apesar de serem insuportavelmente lentos.
- Esforce-se para melhorar continuamente suas habilidades e conhecimentos técnicos. Desenvolva a habilidade de analisar criticamente tudo o que aprender. Reavaliar seu conhecimento regularmente. Em alguns casos, esteja preparado para esquecer o que achou que sabia. O que traz à tona ...
- Algumas tecnologias / técnicas podem ser muito complicadas, levando a mal-entendidos sutis e implementações incorretas. Outros, através da evolução do conhecimento comum ou das ferramentas disponíveis, podem cair ou desvalorizar (por exemplo, Singletons). Alguns tópicos são tão complicados que geram um monte de "especialistas em hocus-pocus" que propagam um enorme corpo de informações erradas. Um dos meus erros em particular é a desinformação em torno da multithreading. Uma boa implementação multithread pode melhorar significativamente a experiência do usuário. Infelizmente, muitas abordagens desinformadas do multi-threading reduzirão significativamente o desempenho, aumentarão erros erráticos, aumentarão os riscos de bloqueio, complicarão a depuração etc.
- Tomar posse. (Não, sério, eu não estou jogando bingo na sala de reuniões.) Negocie com gerentes, proprietários de produtos, vendedores para recursos de desempenho que tenham precedência sobre alguns itens da lista de verificação. Exija melhores especificações. Não infantil, mas fazendo perguntas que levam as pessoas a pensar em desempenho.
- Seja um consumidor exigente. Escolha o telefone que possui menos recursos, mas é mais rápido. (Não é mais rápido CPU, UI. Rápida) brag Então sobre isso ! Quanto mais os consumidores começarem a exigir desempenho, mais contadores de feijão começarão a fazer orçamentos.