True
comentada em 19/07/2022 21:32

Isso da um rolo tão grande... Quem chega depois pra dar manutenção/adicionar funcionalidades fica perdido. Já vi casos que eu só pensava "Melhor apagar e construir do zero, sai mais barato"

O código é legado a partir do momento que você escreve.

Depende da definição. Se o código tá coberto por testes e é mantido, tá razoavelmente limpo e é legível, então ele não é legado.

Código legado é aquele que funciona, mas corrigir bugs é um parto. Ninguém quer tocar nele.

Típico caso de código legado é quando contratam uma pessoa nova pra manter e ela leva 1 mês só pra entender o básico.

Isso se não der /quit assim que ver o código e sair distribuindo currículos por aí novamente (eu já vi acontecer) 

Pessoal que é da área poderia esclarecer como que isso chega a esse ponto? Deixam de refatorar, testar, ?

A produção de código está atrelada a uma pressão financeira.

Para o código ser feito constantemente com esmero técnico, é necessário um investimento muito grande, começando pelo sponsor do projeto entender que vai demorar mais pra entregar uma funcionalidade por usar mais tempo das pessoas para refatoração de código.

Isso acontece na vida real em pouquíssimos dos casos, geralmente onde o sponsor é o próprio founder e com background de tecnologia em uma empresa recém criada.

Tem 15 anos que saí da área e o assunto é o mesmo... Impressionante...

Quem precisa convencer o sponsor a diminuir a pressão por entrega e ceder um tempo pra limpeza do código do projeto são os próprios devs e arquitetos que estão diariamente trabalhando no coding. 

Só que eles ficam o dia inteiro só recebendo papelzinho no quadro do scrum/kanban e fazendo, igual robôs em linha de produção. São ótimos pra encontrar bugs, discutir o melhor algoritmo de sort que economiza 30 ms por execução, mas na hora de vender uma ideia, não conseguem sair da página 1. Todo programador deveria dedicar um ano inteiro a estudar soft skills e deixar o hard de lado, com aquele monte de sopa de letrinha que muda a cada 2 meses o hype e não agrega muito valor.

postado por @a_mbm em 19/07/2022 09:00

Quem precisa convencer o sponsor a diminuir a pressão por entrega e ceder um tempo pra limpeza do código do projeto são os próprios devs e arquitetos que estão diariamente trabalhando no coding. 

Só que eles ficam o dia inteiro só recebendo papelzinho no quadro do scrum/kanban e fazendo, igual robôs em linha de produção. São ótimos pra encontrar bugs, discutir o melhor algoritmo de sort que economiza 30 ms por execução, mas na hora de vender uma ideia, não conseguem sair da página 1. Todo programador deveria dedicar um ano inteiro a estudar soft skills e deixar o hard de lado, com aquele monte de sopa de letrinha que muda a cada 2 meses o hype e não agrega muito valor.

Perfeita colocação. Percebo o mesmo, maioria dos devs só foca no hype, usar a linguagem da moda ou alguma arquitetura que as vezes nem é a melhor, isso contribui muito para a criação de legados.

Foram criados os agile HCAOCs ou times de produto para tentar suavizar esses problemas, mas na verdade eles são fantoches do time comercial, dado que não tem conhecimento técnico e só colocam pressão por entrega

postado por @a_mbm em 19/07/2022 09:00:19

Quem precisa convencer o sponsor a diminuir a pressão por entrega e ceder um tempo pra limpeza do código do projeto são os próprios devs e arquitetos que estão diariamente trabalhando no coding. 

Só que eles ficam o dia inteiro só recebendo papelzinho no quadro do scrum/kanban e fazendo, igual robôs em linha de produção. São ótimos pra encontrar bugs, discutir o melhor algoritmo de sort que economiza 30 ms por execução, mas na hora de vender uma ideia, não conseguem sair da página 1. Todo programador deveria dedicar um ano inteiro a estudar soft skills e deixar o hard de lado, com aquele monte de sopa de letrinha que muda a cada 2 meses o hype e não agrega muito valor.

Comentário que vai direto ao ponto.

Devs em geral são péssimos em soft skills e não conseguem convencer os stakeholders que às vezes uma feature pode demorar um pouco mais pra ser entregue porque o código anterior não tá bom e precisa de refatoração. Ou que precisam dar um tempo nas novas features para atualizar dependências. Etc.

É algo que venho tentando praticar dia a dia, quando vem feature nova de caminhão, convencer os interessados que não é bem assim que a banda deve tocar, e que se for assim no futuro não tão distante os gastos com desenvolvimento vão subir sem necessidade porque vai se tornar um parto adicionar qualquer funcionalidade nova. 

Falar que quem tem que cuidar da qualidade é o dev é fácil mas quem vai ficar com aquele código ruim pra sempre é a empresa.

Quem tem que entender que qualidade de código é importante é a empresa, mas quem sabe o que tá ruim e precisa ser melhorado é o dev. Esse balanço é complicado, tem dev que se deixar só fica refatorando coisa o dia todo, então é um equilíbrio a se atingir com entrega de demanda e manter um nível de qualidade aceitável. Dev é pago pra resolver problemas e não ficar escovando bit.

Com a fácil navegabilidade do mercado de hoje, dev não tá nem aí, tá ruim ele troca. Se se chegou a um ponto que não dá mais pra manter e/ou melhorar, a responsabilidade é da empresa. Sem saber a situação especificamente é difícil de julgar o dev, muitas vezes ele ficou tempos levantando a bola e sendo ignorado, mas tem dev incompetente (ou inexperiente sem alguém mentorando) também que deixa rolar.

Qualidade de código é pra manter o sistema relevante. Tem sistemas que precisam de mais ou menos atualização, tem código que você pode escrever e rodar em produção por 20 anos, tem código que fica defasado em 3 meses. Cada lugar vai ter um cenário diferente, mas uma boa métrica é lean time, o tempo que uma feature ou bug demora de cabo a rabo a ser implementada/corrigido. Muitas vezes é problema de processo, mas processo e sistema estão fortemente interligados.

@Sardinhes depende muito. Já vi:

- Incompetência da gestão (donos, diretores, gerentes)
- Incompetência técnica (gerentes, líderes técnicos, devs)
- Dificuldade financeira (realmente não tem grana pra manter/melhorar)
- Relevância do sistema (o negócio não dá mais tanto dinheiro, similar ao anterior)

Geralmente é uma das incompetências, já que se o sistema não dá lá mais tanta grana ele não ficaria vivo por muito tempo. E incompetência acaba sendo muito genérico também, muitas vezes a galera simplesmente desconhece os benefícios de manter a qualidade do sistema ou não se importa no longo termo porque não tem incentivo.

@ThiagoDV  Além disso, o mercado tá muito aquecido.  Tá cheio de dev que participou de 2 projetos e já se auto intitula sênior, mas não sabe de nada ainda.

O código, obviamente, é horrível. Ou não tem nenhuma estrutura ou tem estrutura demais (overdesign) ou, pior ainda, um devops turbinado com esteróides e um código horroso.

Aliás, não faltam devs com 5 anos de profissão que já estão lançando cursos e ensinando e que não sabem de nada, nada nada!!!. Literalmente reproduzem fórmulas prontas recheadas de overdesign (pq o Facebook usa assim, pq o Google usa assado) que são lindas no powerpoint, mas na prática....

No fim, vira um código monstruoso que faz o mesmo que outro super básico faria, só que pior.

Eu vi isso na prática em um projeto que estou alocado para fazer funcionar.

O cara anterior era um senior desses fake que fez um overdesign GIGANTESCO, que, claro, começou a dar um monte de problema.

Uma tonelada de bug apareceu em features desnecessárias... fora o uso de ferramentas que não tem nenhuma utilidade, só pelo hype.

Para se ter ideia, o cara usa um Redis para comunicar 2 partes do mesmo código rodando no mesmo processo kkkkkk

Estamos deletando tudo, refazendo tudo, praticamente do zero. 

Claro que tem gente que é ponto fora da curva, que é bom mesmo sendo mais novo na profissão. Mas é raro.

Precisa apanhar muito na vida pra aprender a programar direito. Programação é profissão de prática. Só com bastante tempo é que o dev vai entendendo como fazer direito.

postado por @FlyCavok em 19/07/2022 18:30

ThiagoDV   Além disso, o mercado tá muito aquecido.  Tá cheio de dev que participou de 2 projetos e já se auto intitula sênior, mas não sabe de nada ainda.

O código, obviamente, é horrível. Ou não tem nenhuma estrutura ou tem estrutura demais (overdesign) ou, pior ainda, um devops turbinado com esteróides e um código horroso.

Aliás, não faltam devs com 5 anos de profissão que já estão lançando cursos e ensinando e que não sabem de nada, nada nada!!!. Literalmente reproduzem fórmulas prontas recheadas de overdesign (pq o Facebook usa assim, pq o Google usa assado) que são lindas no powerpoint, mas na prática....

No fim, vira um código monstruoso que faz o mesmo que outro super básico faria, só que pior.

Eu vi isso na prática em um projeto que estou alocado para fazer funcionar.

O cara anterior era um senior desses fake que fez um overdesign GIGANTESCO, que, claro, começou a dar um monte de problema.

Uma tonelada de bug apareceu em features desnecessárias... fora o uso de ferramentas que não tem nenhuma utilidade, só pelo hype.

Para se ter ideia, o cara usa um Redis para comunicar 2 partes do mesmo código rodando no mesmo processo kkkkkk

Estamos deletando tudo, refazendo tudo, praticamente do zero. 

Claro que tem gente que é ponto fora da curva, que é bom mesmo sendo mais novo na profissão. Mas é raro.

Precisa apanhar muito na vida pra aprender a programar direito. Programação é profissão de prática. Só com bastante tempo é que o dev vai entendendo como fazer direito.

essa do Redis eu ri alto aqui ahahahaha

@buy_and_nemo kkkkk
É rir pra não chorar

Uma vez eu fui em uma conferência sobre cloud e tinha uma startup dando palestra sobre como transformaram um sistema monolítico em microsserviços.

Daí o próprio cara foi falando que foram quebrando e quebrando em subpartes e tal e daí, lógico, o negócio parou de performar....

Aí ele dando a dica de que tinha que meter cache em tudo.

Aí eu só pensei: puts, o dono desse sistema tá muito ferrado. Pq assim, o negócio virou um trambolho enorme. Coisas que eram absolutamente afins tinham sido quebradas pelo puro hype.

No fim o I/O ficou tão monstruoso que tiveram que usar um zilhão de containers e um monte de cache pra compensar.

E eu só pensando: que massa, era ruim e ficou mais ou menos, só que agora custando 4x, mas pelo menos escala (custando os olhos da cara, mas escala) kkkkkkkk

É assim galera. Tá cheio, cheio mesmo de hype... Pior é que vende bem. 

Tem muita gente aí que empurra coisa desnecessária só pra por no currículo que usou tecnologia X.

Eu logo desconfio que um cara ficou 1 ano na empresa e trabalhou com 10 tecnologias ...

Ou ele tá listando todas as tecnologias envolvidas no projeto todo (do qual ele era uma parte pequena), ou ele socou um monte de tralha lá só pra aparecer...

postado por @FlyCavok em 19/07/2022 19:41

buy_and_nemo kkkkk
É rir pra não chorar

Uma vez eu fui em uma conferência sobre cloud e tinha uma startup dando palestra sobre como transformaram um sistema monolítico em microsserviços.

Daí o próprio cara foi falando que foram quebrando e quebrando em subpartes e tal e daí, lógico, o negócio parou de performar....

Aí ele dando a dica de que tinha que meter cache em tudo.

Aí eu só pensei: puts, o dono desse sistema tá muito ferrado. Pq assim, o negócio virou um trambolho enorme. Coisas que eram absolutamente afins tinham sido quebradas pelo puro hype.

No fim o I/O ficou tão monstruoso que tiveram que usar um zilhão de containers e um monte de cache pra compensar.

E eu só pensando: que massa, era ruim e ficou mais ou menos, só que agora custando 4x, mas pelo menos escala (custando os olhos da cara, mas escala) kkkkkkkk

É assim galera. Tá cheio, cheio mesmo de hype... Pior é que vende bem. 

Tem muita gente aí que empurra coisa desnecessária só pra por no currículo que usou tecnologia X.

Eu logo desconfio que um cara ficou 1 ano na empresa e trabalhou com 10 tecnologias ...

Ou ele tá listando todas as tecnologias envolvidas no projeto todo (do qual ele era uma parte pequena), ou ele socou um monte de tralha lá só pra aparecer...

Minha experiência é similar.

No fim quem ganha com o hype são as big clouds... Dale gasto com "cache" pra compensar a performance.

Eu trabalhei numa startup que o sistema legado monolito em Java+Oracle custava 20x menos que o novo em Rails+PostgreSQL (já somada a licença do Oracle Enterprise), detalhe é que o novo transacionava 100x menos que o antigo! E obviamente não escalava

O antigo era 100% Java, o novo tinha de tudo. Tinha job em go! e haskel que ninguem sabia dar suporte pq um arrombado resolveu usar isso pq quis

No início eu tinha pena da empresa, mas no fim a culpa é deles. Contraram amadores ou pessoas de business para liderança técnica...

A pérola foi o CTO trocar AWS por Oracle Cloud kkkk

postado por @a_mbm em 19/07/2022 08:55

Tem 15 anos que saí da área e o assunto é o mesmo... Impressionante...

Em 1968 a Organização do Tratado do Atlântico Norte, a.k.a. OTAN, bancou uma conferência sobre uma área de conhecimento que começava a se espalhar por todos os ramos de organizações no mundo: Informática

Em uma das mesas de discussão um participante clama por melhorias no processo de produção de software. E, compara o atual ao processo dos Irmãos Wright: constrói tudo e empresa só precipício pra ver se funciona.

Em 1975, Fred Brooks publica o livro The Mythical Man-Month. Onde crítica os processos e "melhores práticas" de gerenciamento de projetos de software da época.

Uma referência recorrente é a crítica que adicionar mais pessoas a um projeto de software atrasado tende a atrasar mais o projeto. Ou, 9 mulheres grávidas não geram um filho em 1 mês.

Quem reparou nas datas vai entender que tem um pouco mais de 15 anos que cometemos os mesmos erros.

postado por @a_mbm em 19/07/2022 09:00

Quem precisa convencer o sponsor a diminuir a pressão por entrega e ceder um tempo pra limpeza do código do projeto são os próprios devs e arquitetos que estão diariamente trabalhando no coding. 

Então, isso é muito legal até tu descobrir que está ferindo o EGO do Product Manager/Project manager/Gerentao/Diretor/CEO/Dono que teve uma idéia FANTÁSTICA E VAI SER SALVAR a empresa ou TRANSFORMAR A EMPRESA EM UM UNICÓRNIO.

No final, o cara correndo atrás das siglas ESTÁ trabalhando soft-skills. Ele identificou que existe um mercado que acredita que 1 ferramenta vai fazer algum milagre. E, tá vendendo o conhecimento adquirido estudando as ferramentas.

Esse é um papo muuuuuito interessante. 

postado por @buy_and_nemo em 19/07/2022 09:37

[...]mas na verdade eles são fantoches do time comercial, dado que não tem conhecimento técnico e só colocam pressão por entrega

Não tem mistério, nessa caso. É só um reflexo da incompetência da área estratégica da empresa: diretoria, C-level, o dono.

Incapaz de balancear "cortar árvore" com "afiar o machado".

postado por @buy_and_nemo em 19/07/2022 20:20

A pérola foi o CTO trocar AWS por Oracle Cloud kkkk

Porque seria pérola?

postado por @ThiagoDV em 19/07/2022 10:16

Devs em geral são péssimos em soft skills e não conseguem convencer os stakeholders que às vezes uma feature pode demorar um pouco mais pra ser entregue porque o código anterior não tá bom e precisa de refatoração. Ou que precisam dar um tempo nas novas features para atualizar dependências. Etc.
É algo que venho tentando praticar dia a dia, quando vem feature nova de caminhão, convencer os interessados que não é bem assim que a banda deve tocar, e que se for assim no futuro não tão distante os gastos com desenvolvimento vão subir sem necessidade porque vai se tornar um parto adicionar qualquer funcionalidade nova. 

Então, quem gerencia a prioridade não é a área técnica. A área técnica apresenta os elementos pra área de negócio decidir o que priorizar.

Se a área de negócio tem limitação o problema é que as pessoas tomando essas decisões tem limitações que impedem elas de tomar uma decisão melhorar, sabe?

Sobre alertar que código ruim é código que impede mudanças tem literatura suficiente disponível. Não é uma novidade, sabe?

Se o gestor trocar de empresa e for trabalhar no McDonald's. Ele vai ignorar quando a área técnica requisitar tempo pra limpar a cozinha?

Percebe como não faz sentido colocar na conta da área técnica as incompetências da área de gestão?

O complicado é que, ao menos em TI, gestão e tecnologia tem essa relação "abusiva", sabe? Com gestores apresentando comportamento narcisista.

No final, é só uma forma de explicar o porquê tu não vai receber aumento.
 
 
 

postado por @FlyCavok em 19/07/2022 19:41

E eu só pensando: que massa, era ruim e ficou mais ou menos, só que agora custando 4x, mas pelo menos escala (custando os olhos da cara, mas escala) kkkkkkkk

 Eu adoro essas histórias de "adotamos X para ganharmos capacidade de escalar mais".

Veja, não existe escalar infinitamente. Tudo sistema cai, se houver dedicação suficiente.

Quer ver a mágica acontecer? Questione:

* Qual o tráfego esperado? No caso, quais cenários foram especulados e qual a probabilidade deles acontecerem?
* No cenário mais provável, de estimativa de tráfego, quanto custava na solução anterior e quanto custa na nova?
* Qual o tráfego atual?

E, a que eu mais gosto:

* O que significa, para o produto, não aguentar esse cenário de tráfego? E, para a empresa? É mais ou menos que o custo pra mudar?

Experimentem.
As respostas costumam ser... Fascinante.