Novos programadores não sabem otimizar código (fato!)

Fui olhar aqui um app similar ao Scratch (uma game engine para aprender programação).:
https://make.gamefroot.com/games/new
Abri o site, fui olhar o editor e p.qp, que app pesado cara! Meu processador vai a mais de 100% só com a janela vazia sem nada adicionada lá.

Como é que pode isso? A tecnologia avança e no lugar de melhorar a qualidade do código, tem-se programadores relapsos que criam código m3rda que usa 100% do processador SEM usar nada do app. Não é atoa que o discord é tão pesado no meu celular, até o youtube que antes era mais rápido no android, agora tá lentíssimo.

Não se trata do meu pc e celular serem velhos, mas sim que o programador que faz esses apps simplesmente não sabe otimizar código, e então, faz de qualquer jeito (do pior possível, diga-se de passagem).

Agoar entendo o ponto de vista dos meus ex-professores dizer que se deve ensinar C na faculdade: tem que aprender usar bem a memória. Mas parece que a expansão do conhecimento via web fez com que a qualidade do aprendizado se deteriorasse e ai vemos esse absurdo de gasto de energia elétrica no processamento de código num app não otimizado.

O que vcs acham disso?


https://nerdki.blogspot.com/ acessa ai, é grátis

Eu já levanto essa lebre aqui no Vol a um bom tempo.

Programadores escolhidos a dedo por questões ideológicas, e sem capacitação técnica.

Uma vez eu tive umas "faíscas" com um participante do vol sobre esse consumo insano de hardware atualmente, quem defende que é normal um sistema terminar sua inicialização consumindo 4fuckingigas tem que ser mandado para o olho da rua! e olha que eu acho que estou sendo bonzinho, na minha opinião nenhum sistema deveria consumir mais de 500 mbs com sua inicialização concluída.

Os navegadores por exemplo são uma raridade a parte, o que se mais ouviu falar nos últimos 15 anos é que "a nova versão consome menos memoria ram" e o que mais e viu foi um maior consumo de memoria ram e cpu, versão após versão.

Deve ter gente por ai formada, trabalhando, que não sabe nem a diferença de variável global e local, escrevendo códigos que poderiam ter saído do programa de tv "kilos mortais"


https://odysee.com/@sabotagem:b

Ai acho que entra algumas opções que podem variar de cada caso:

1 - Não querer mesmo, com aumento do HW básico, não "compensa" o tempo gasto com otimização

2 - Não podem "perder tempo" com isso, pois precisam forma no "core" da aplicação ou pq o "patrão" acha que não vale a pena

3 - Não sabem mesmo (rsrs)

E pensando agora podem ter ainda mais variáveis. mas eu acho que 2° deve ser o caso maior , geralmente esse tipo de coisa o "patrão" não entende a real necessidade....

#-------------------------------------------------------------------------------------#
"Falar é fácil, me mostre o código." - Linus Torvalds
#-------------------------------------------------------------------------------------#

Concordo, já acho um exagero meu chrome com 2GB de ram usada, num único programa! Se vou abrir outro lá se vai mais 1GB. Ter formação nem é tão problemático, digo, porque a chance do cara ser inexperiente é mais baixa, mas existente também. Dia desses vi um cara trabalhando numa empresa com apenas 6meses que programava, não é dois anos, não é 5 anos, é 6 meses! Imagina a qualidade do código do cara que programa há 6 meses? Isso não seria ruim, mas o cara tá numa grande empresa trabalhando como programador.

Como falta de uma mão de obra mais "experiente" as empresas e os empregadores preferem pagar o fulaninho que faz app em cordova do que pagar um profissional que vai fazer código limpo e otmizado. Na última empresa que trabalhei, que me arrependo até hoje de ter entrada nessa desgraça, código m3rda era tradição na diretoria, que era formada por diversos exprogramadores. Dái lá se vai o besta (eu!) fazer um código limpo e otimizado e digo: vai levar mais dois dias. E meu exchefe: ainda?
O que ele quis dizer foi, faz rápido ai e com qualidade que é pra isso que te pago. Só que, qualidade e rapidez são duas coisas que nunca vão andar juntas. E ai sai dessa bagaça com uma baita crise de ansiedade. No fim, o que vale é: faz o código na doida, nem que seja um sql que consuma toda a mem[oria do servidor, o que importa é que funcione (estratégia da gambiarra).


https://nerdki.blogspot.com/ acessa ai, é grátis

Concordo com esses teus pontos e digo mais sobre esse 2 ai, patrão é culpado por todo código m3rda que é feito e não o programador sozinho. Já começa errado quando vai contratar por não saber avaliar o individuo (RH fraco) e ai escolhe o carinha que cobra mais barato. E por fim, quem paga é quem tem que programar e lidar com código ultra complexo que poderia ser muito bem só 15 linhas, mas são mais de 100 porque o programador júnior que se acha sênior fez por ser a "melhor" forma de fazer a tarefa.



https://nerdki.blogspot.com/ acessa ai, é grátis

Não resisti a esse tópico... Vou contar um caso real.

To contratado de Supervisor no IBGE pro Censo Demográfico. O Censo está atrasado por diversos fatores, mas um deles com certeza são os Apps Bugados do Censo Demográfico.

Primeiro, o sistema online do IBGE via webbrowser é razoavelmente lento, isso quando não trava por completo! Quando estávamos mais no começo do Censo, o sistema, chamado de SIGC, dava sempre travadas durante o dia, muitas vezes por dias seguidos e assim não conseguíamos adicionar mais dados e fazer os procedimentos seguintes. A desculpa era que o sistema estava sobrecarregado.... Oras!!!!!! Como é que não pensaram que 100 mil recenseadores usando o sistema todos juntos não iria sobrecarregar o sistema? Pior é que se tivessem contratado um serviço bom, um servidor bom, sei que a Amazon oferece banda dinâmica, então o sistema não sobrecarrega nunca..

Mas esse é um outro problema, na verdade.. Não acho que esses dados deveriam passar pela Amazon ou por qualquer outra empresa privada! O IBGE deveria ter uma boa equipe de programadores da casa. E deveria desenrolar todo o serviço, desde hospedagem dos dados em servidor próprio, enfim..

Agora chegamos na maquininha que o Recenseador usa para coletar os dados dos Moradores, chamado de DMC (Dispositivo Móvel de Coleta).

Um Recenseador recebe uma semana de treinamento e tem que recensear milhares de pessoas depois. É claro que eficiência é muito importante.

Recebemos um smart-phone ou um tablet, a maioria marca Positivo. O smartphone/tablet nem é tão ruim assim de poder de processamento, então essa não pode ser a causa dos Aplicativos de Coleta e Supervisão serem extremamente lentos..

Os Apps são desenvolvidos por uma empresa terceirizada, chamada NAVITA... Que empresa medíocre deve ser... Enfim, descobri que os Apps importantes foram todos escritos em.. PYTHON! Não consegui descobrir a versão do Python, mas eu nem ficaria surpreso se estiverem usando Python2..... Sinceramente...

E todos sabemos que Python é muito lento. Os programadores tentaram fazer uma interface bonita, mas eles devem ter 17 anos de idade e desenvolvem tudo em um iPhone de última geração... Vi umas versões antigas dos Apps, e tinham ícones grandes e contrastantes. A nova versão do App tem ícones bem pequenos e estranhos, letras bem pequenas, ao invés de meterem uns 100 botões com NOME de cada função, não! Colocaram o tal do MENU de TRES PONTINHOS , putz, um inferno ficar clicando nele para desenterrar opções que a gente usa toda hora.. Tem Recenseador que desistiu pq não consegue enxergar as letrinhas! Cadê a acessibilidade ou todo mundo tem 17 anos e visão 30/20?

Enfim, os Apps são extremamente lentos... Ao invés de ajudar, a forma que eles programaram a interface torna tudo mais difícil, haja dedo para ficar tapeando um monte de confirmação desnecessária. Outra coisa, ao invés de colocarem todas as perguntas na mesma tela, tem que clicar em avançar a cada pergunta, então só gasta tempo à toa...

Não precisa nem de Python. Gente, eu desenvolvi meu blog HTML from scratch, e poxa ele roda super rapidamente (só uso o framework do w3.css)... Eu acho que se fizesse tudo em HTML+CSS+JAVASCRIPT offline se pá ia ser uma interface beeem melhor e mais rápida! Seria demais pedir que programassem em C para o App voar...

Uma outra coisa muito grave: o App trava, bugado, perde Questionários já feitos. Os Questionários simplesmente somem, e com isso , se a Recenseadora não refizer o Questionário com o Morador de novo, ela fica sem o pagamento daquele questionário... Uma desistiu depois que mais de 40 questionários desapareceram! Os meus Recenseadores mesmo perdem uns Questionários de vez em quando, mas temos sorte que este bug não tem nos afetado muito..

Conclusão: Não dá para lamber pão pintado. Questionários em PAPEL como era feito nos Censos anteriores são melhores. Esses programadores usam a tecnologia contra eles mesmos!

O conselho que estou dando é para os Recenseadores fazerem uma cópia do cartão de memória do smart-phone onde ficam guardados os backups. Gente, não podemos confiar no IBGE e no sistema digital deles para guardarem os Questionários, os Recenseadores precisam de uma prova para demonstrar que fizeram os Questionários mas que eles desapareceram da maquininha sem deixar rastros...

Até consegui instalar o Termux no DMC do IBGE mas infelizmente tem que fazer um monte de hack para fazer o Termux rodar então não é nada prático...

Acredito que são vários fatores que influenciam na baixa qualidade. Tem culpado dos dois lados, tanto de programadores quanto de empresas e/ou clientes.

- Das empresas e/ou clientes, que querem pagar pouco exigindo mais; e rápido!
- Dos gerentes de projeto e/ou donos do produto, que em muitos casos, não conhecem totalmente as regras de negócio, deixam para ver tudo em última hora, exigindo alterações perto do prazo e prolongando a entrega final;
- Dos programadores inexperientes, que entregam funcionalidades sem testar, sem a mentoria de desenvolvedores seniores por perto;

Esses são apenas alguns, mas a lista é bem maior rs!

Interessante suas colocações aqui no tópico @SamL


-------------------------------------------------------------------------
Estai, pois, firmes na liberdade com que Cristo nos libertou, e não torneis a colocar-vos debaixo do jugo da servidão.
Gálatas 5:1

@storma
Caramba, não sabia que a situação fosse tão crítica, mas conhecendo esse meu país de deus me livre, deve ter superfaturamento e desvio de verba na contratação dessa empresa. Aposto como esses programadores dessa empresa devem ter menos de 20 anos, ou no máximo 23, isso porque quem sugeriu usar python como linguagem desse app e pelo que tu fala da interface.

Essa onde atual de minimalismo foi inventada por um cara ai que não lembro o nome agora e ai google e outras aderiram. Acho simplesmente inútil e feio certas interfaces de apps android, não são úteis, são vazias de funções, simples assim, ainda mais com o que tu falou de ter de clicar excessivamente. Isso mostra que esse minimalismo ridículo é inútil na prática e dia a dia do usuário. Basta ver o "bot" das inscrições do enem, trata a gente como se fossem retardados e que não sabem nada de tecnologia.

Enfim, triste realidade.


https://nerdki.blogspot.com/ acessa ai, é grátis

Esses dias fui estudar construção de apps. Fui instalar o ionic, mas deu tanto trabalho e foi tão confuso por conta das mudanças entre uma versão e outra que pensei por que não apenas instalar o android estúdio??? Um framework se propõe a facilitar e torna as coisas confusas demais. A culpa do mau desenvolvimento também é dos frameworks, que enchem de funcionalidades e aumentam o custo de memória em troca de facilidade de desenvolvimento.

Para construir apps cross-platform, prefiro Expo (React Native), pois a comunidade é mais ativa e tem muito mais conteúdo na rede. O Flutter também é uma boa!

Com o Expo é bem fácil e rápido iniciar um projeto.

Fora isso, só partindo para o nativo mesmo (Kotlin/Android, Swift/iOS).