Reescrever do zero não é boa ideia (Rewrite levou empresa a falência)

💜Comunidade do Discord: / discord
✅ Torne-se membro para obter aulas técnicas exclusivas comigo:
/ @lucasmontano
❤️ Ajude o Rio Grande do Sul, informações em lucasmontano.com/
Fontes:
x.com/GergelyO...
• SCRUM vs SAFe : What's...
✅ Meu site parece que foi feito por um DEV backend né?! Mas lá tu encontra tudo que precisa saber sobre o que tenho feito e onde estou:
lucasmontano.com/
✅ 𝗢𝗦 𝗠𝗘𝗟𝗛𝗢𝗥𝗘𝗦 𝗩𝗜𝗗𝗘𝗢𝗦 𝗗𝗢 𝗖𝗔𝗡𝗔𝗟
▸ 3,700,000 requests do MrBeast na API do X (eu tentei e não foi barato)
• 3,700,000 requests do ...
▸ Programação realmente é muito difícil?
• Programação realmente ...
▸ DEV Precificando Projeto tipo Netflix (bem simples)
• DEV Precificando Proje...
▸ Gemini Impressiona ao Superar Humanos : Nova IA do Google • Gemini Impressiona ao ...
▸ OpenAI choca o mundo +1 (mas Sora não é sobre gerar videos)
• OpenAI Sora não é apen...
▸ IA que utilizo & a mentira da Gemini (Nova IA do Google)
• IA que utilizo & a men...

[@LucasMontano]

Comunidade do Discord discord.gg/5uV96SVF

[@GabrielTegani]

está dando como convite invalido luqueta

[@TheKlein550]

Não tá pegando Lucas Montano do Canal Lucas Montano!!!

[@KAPPA-sg4of]

Vamos discutir esse link que não esta funcionando na daily de amanhã.

[@TheKlein550]

@@KAPPA-sg4of Precisamos marcar uma reunião com Lucas montano do canal Lucas montano para entender o porque disto está acontecendo. Ações deste tipo não podem mais continuar a ocorrer.

[@pvictorc]

Não querendo ser advogado do diabo, mas isso aí realmente não parece ser problema de Scrum. Parece ter sido uma incompetência MONSTRA 1) dos líderes gestores e técnicos, e 2) dos desenvolvedores sem competência para executar... E óbvio uma sequência de péssimas decisões no começo e no caminho 😂😂😂

Exatamente. Galera tem q parar de colocar a culpa em métodos. Nem pro bem e nem pro mal.

[@ronaldoperes1202]

Pensei o mesmo, usamos scrum aqui e nunca tivemos problemas - me parece que problema ai foi de BIOS mesmo... Refatorar é bom, mas aqui só fazemos quando nao é nada critico e se faz sentido também.

[@tkmoreirabr]

Sim, mt mais é quem executa do que como é executado...

[@fabioa8059]

Me parece que o método não é o erro, mas a falta de planejamento e de um gerenciamento do projeto todo possibilitou a bagunça Extrema

[@robertopc]

Esse caso têm uma máxima: "mal feito é melhor que não feito". O que está mal feito você pode melhorar, o que não existe não se tem melhora.

[@guilherme-argentino]

Eu já vi gestor dizendo que o projeto fracassou, mas a gestão do projeto foi um sucesso. Então ver culparem a metodologia não é novidade, vai?

[@roberotto]

Sim, isso acontece com certa frequência por aqui. Inclusive foi tema de um e-mail esculhachado e inédito, à nível de alta diretoria, por conta de uma Curva de Avanço 100% perfeita, porém, 3 dias de processo parado além do planejado, incorrendo numa perda de quase US$ 3kk/dia. No papel, o planejamento, Bettencourt e avanço do projeto estavam perfeitos, na prática, prejuízo absurdo. Conforme piorou a situação, o que "salvou o dia" foi uma rede forte de contatos para pôr a mão na massa e fazer o troço rodar.

[@regismaciel6855]

Pofexor Luxa sempre ensinou: Eu ganho, nós empatamos, vocês perdem.

[@israels3550]

O bom e velho: A culpa é minha, então ponho em quem eu quiser! 😂

[@detinhorp]

Logo no início da minha carreira eu participei de uma grande reescrita: migrar um ERP flagship (Clipper que roda no linux) onde cada cliente tinha uma cópia inteira do sistema (sim a cópia do fonte) para um sistema em Delphi (sim sou velho) onde teríamos uma única versão com feature flags. Foi um projeto de anos, mas que vingou e roda até hoje. Hoje não trabalho mais lá, mas a sensação que tinha quando saí de lá é que uma reescrita completa não vai ser feita tão cedo. A diferença é que quando eu entrei a empresa era muito menor. Chutaria umas 20x menor. Outro fator é que o sistema antigo era modo texto e tabelas DBF. Isso limitava tanto tecnologicamente quanto comercialmente. Com o sistema de hoje conseguiram dar muita sobrevida, até rodando "na web", então não é mais um impedimento tão grande.

[@gepetovovo2509]

eh amigo.. imagina esse delphi sendo reescrito pra modinha "clean architecture" aonde terá q ser quebrado em vários microservicos, front end com várias linguagens.. kkk e retestar toda a regra de negócio e ai colocar mais um monte de gente pra fazer... vai pra falência isso.. só pra dizer q tá na modinha e alisando codigo.. e pode anotar ai que será mais lento ainda por cima..

[@ricardojlrufino]

Isso seria verdade ... Mas tem uma outra verdade que é a escalabilidade , existe um ponto que um software ele não fornece uma forma fácil de escalar comercialmente. Se você precisa instalar o sistema para um cliente usar , isso afeta a escalabilidade ( comercial ). Se é na nuvem e não tem um trial , também é outro fator que pode limitar. A vantagem da web é o modelo de distribuição que é mais eficiente.

[@detinhorp]

@@ricardojlrufino acho que esse sempre foi o maior gargalo. Dito isso conseguiam tirar leite de pedra, tinham e devem ter um processo mega eficiente de implantação e depois de atualização dos clientes.

[@Adams456]

Participei de uma implementação de SAFe em uma corretora de investimentos que foi comprado pelo roxinho depois, uma das coisas que me impressionou inicialmente foi a visibilidade dada aos stackholders de como estava o progresso de todos os times (não estou atribuindo isso ao SAFe). Sendo o SAFe um framework, você pode utilizar o que for necessário e nao implementar tudo. E como o Lucas falou, o problema não é o SAFe, não é o scrum... Todo nós, desenvolvedores com uma certa experiencia sabe qual o problema

[@edmilson1178]

Se o sistema estiver muito ruim, tem que fazer do zero mesmo! Mas o sistema antigo tem que ser mantido até que o novo sistema esteja homologado. Uma outra alternativa, é ir criando os módulos no sistema novo e fazendo com que o sistema antigo passe a utilizar as novas implementações os "Micro-Servicos" caem como uma luva nesses cenários.

[@gepetovovo2509]

certo e qual cliente vai querer pagar o duplo desenvolvimento?? pq tu acha q a mesma pessoa consegue mexer no legado e mexer na interface nova?? kkk.. tem empresa que as pessoas não estão mais lá do legado, e retestar toda a regra de negócio??.. é falência na certa, erro muito grande.

[@AlexeiDimitri]

@@gepetovovo2509 Se vc tem uma arquitetura em serviços a questão do serviço A conversar com o serviço B é apenas uma questão de vc mudar a configuração do ESB para apontar a classe nova do serviço Ou seja vc não precisa mudar código dos serviços antigos, pq ele vai se comportar exatamente como os antigos se comportavam Essa é a vantagem do SOA Isso é, se vc realmente usou o SOA, com baixo nível de acoplamento. Se fez um SOA meia boca, aí sim vai ter que reescrever...

[@edmilson1178]

@@gepetovovo2509 A alternativa é ficar segurando "a granada sem pino" até onde der... Quando não der mais o resultado será o mesmo... Falência!!!

[@gepetovovo2509]

@@edmilson1178 Pergunta lah pro Itau se eles conseguiram migrar o Cobol pra JAVA...rs.. foi milhões por ralo e não conseguiram.. por isso Cobol tá vivo e forte e essa granada ai q vc se refere já esta a mais de 50 anos!!!..

[@edmilson1178]

@@gepetovovo2509 Vc esta pegando um caso do maior banco do Pais, e comparando com software house (de esquina) e Startup?? Os 5 grandes bancos do pais, conseguem segurar isso ai por mais 50 anos tranquilamente... Pega qualquer empresa com faturamento dentro da realidade média, se aguentarem 2 anos de prejuízo é muito...

[@Foxtrroy]

Eu acho, só acho que: 1. O arquiteto não era arquiteto; 2. O engenheiro não era engenheiro. Por fim, foram enrolando e enrolando até onde deu... E depois, para não queimar as pessoas, a culpa é do método... E não de quem...

[@franklinsantos92]

Pow Lucas poderia fazer um vídeo maneiro explicando nosso querido XGH na prática hein

[@SpockChaim]

E é por isso que tem banco usando COBOL e ninguém toca, muito menos troca.

[@ricardojlrufino]

Tá trocando ... Trabalho em banco , mas é lento isso. Alguns partes talvez vai demorar bastante.

[@a-drew]

Um bancão australiano resolveu migrar o Cobol pra algo mais "moderno". Resultado: anos e anos de migração e quase 1 bilhão de dólares gastos.

[@guilhermebraga8483]

Banco do Brasil é cobol até hoje.

[@jhony_tech]

Mais fácil comprar um banco moderninho que já tá com a tech atualizada kkk

[@trcvince]

Tive um agile tambem e me faliu quando fundiu o motor e descobri que é um motor argentino que nenhum outro carro usa.

[@fernandoferreiradentalpres5315]

Estou em um projeto de uma editora onde tem um sistema de streaming onde precisa ser totalmente reescrito. Minha atitude com lider de projeto fiz manutenção até onde podia e o projeto esta rodando com uma cara totalmente nova sobre um midware e o core é o mesmo que tinha. Agora que esta tudo estavel depois de 2 anos estou reecriando totalmente o sistema para poder fazer a migração com calma e para que o novo core seja totalmente conforme desejamos. Melhor metodo para casos como esse

[@gustavodarrn]

Provavelmente eles falharam na questão do Fallback. Nas questões de reescritas de código, normalmente eu fiz em códigos que foram feitos em Cobol e precisaram mudar para Java. A parte mais complicada era garantir que as funcionalidades estavam dando o mesmo resultado. Funcionalidades novas precisavam ser feitas no Cobol e no Java. Em relação a refactory evite fazer modificações se o código tiver pouco ou nenhum teste. Caso esteja com muita vontade de fazer o refactory, faça os testes funcionais automatizados primeiro e depois faça seu refactory e verifique se os testes quebraram.

[@justinosachilombo2895]

Bem muito bom o vídeo. Formalmente, pelo que aprendi em disciplinas como Compreensão e Evolução de software no mestrado posso dizer que: Refactoração é basicamente melhorar um código ou estrutura existente em um software sem adicionar ou modificar funcionalidades existentes no mesmo. Mesmo q resulte num código totalmente diferente se o objectivo foi melhorar algum aspecto como legibilidade, remoção de divida técnica, adaptação a um novo ambiente ou mesmo qualquer coisa que melhore a manutenibilidade futura do aplicativo ainda assim será refatoração. Rescrever ou fazer reengenharia é praticamente a mesma coisa porém mais comum em projectos legados ou em projectos em faze de manutenção. Ao passo que refatoração aplica-se mais em etapas de desenvolvimento de software comuns dentro de sprints. E definitivamente, se um software possui alto valor de negócio (caracteristicas comuns em software legado), rescrever tudo do zero não deveria ser uma opção. Mas sim iniciar uma etapa gradualde reengenharia em partes criticas do app que precisa muito melhorar sua manutenibilidade. Rescrever do zero uma aplicação de alto valor negócio pode dar mesmo muito errado

[@colthrane]

O que sempre me vem à cabeça nesses casos é que com certeza, na reunião de decisão de 'vira não vira a chave', alguém falou: gente, é melhor não fazer isso, olha... Toda merda grande que eu já vi em sistemas críticos sempre alguém avisou antes que não era hora de fazer isso e alguém bancou a mudança. Agora, eu nunca vi nada crítico não ter rollback. Por mais que eu ache Agile e Scrum um modismo aplicado de forma apressada e, muitas vezes, incorreta esse tipo de caso não foi só culpa do processo. Foi uma cascata de erros.

[@LucasFavaretoSantos]

Já trabalhei numa migração de um projeto feito em angularJs para Angular 14, sem documentação, apenas vendo as telas do antigo e tentando replicar, o backend era do tipo “success”: false com status code 200 Tiveram dias que eu literalmente chorava de raiva

[@SchettinoRafael]

Precisam contratar o Haddad para consultoria. Ele sabe cobrar impostos sem atraso e inventar novos impostos.

[@MichelAraujo2014]

Trabalho com desenvolvimento desde 1997, sou macaco velho. No inicio eu era apegado a tudo que era metodologia que surgia, mas nesse tempo todo o que eu vi de empresa que seguiram as melhores práticas falhando miseravelmente em seus projetos, e empesas que fazem quase tudo em Go Horse entregando e prosperando mudou muito minha forma de pensar nesses anos todos. Continuo achando que processos são importantes, planejamento é importante, mas não devemos nos apegar firmemente ao mapa, devemos dar muito mais importância também ao terreno. Outra coisa que percebi é que de um tempo para cá modelos de negócios estão mudando de forma muito acelerada, empresas mudam sua forma de trabalhar e operar com muito mais frequência do que no passado e isso torna as coisas muito mais complexas, por isso que reescrever as coisas aos poucos é muito melhor e migrar aos poucos é muito melhor.

[@cristianoseixas2417]

Existe uma certa particularidade que complica um pouco. Por exemplo quando se tem um sistema em Delphi com firebird funcionando e há um desejo de se migrar o sistema para Java por exemplo, nessa situação acredito que não existe refatoração ,na minha visão tem que fazer do zero mesmo, sempre correndo o risco de ser criado um novo requisito. Claro que funcionalidades mais simples podem ser recriadas se baseando na antiga, já dá para ganhar tempo.

[@gepetovovo2509]

itau tentou fazer isso no Cobol deles, migrando pra java.. resultado foi milhão jogado no lixo.. e por isso o Cobol continua vivo e forte.

[@cunhafpv]

Comecei recentemente como pleno em uma nova empresa, cliente do setor financeiro. Estou atuando em migração de micro serviços com java 8 para java 17. Espero aprender coisas novas e me tornar Sênior com tal experiência.

[@eduardomaes]

Um dos problemas é quem só tem martelo achar que tudo é prego. Pessoal querendo colocar agile em áreas de suporte, serviço, operação, áreas que nem tem roadmap de produto, que atuam com tickets ou com projetos longos com começo meio e fim quando um gráfico gantt já resolve a gestão. Por fim vira um: nem cascata, nem agile, um monstro.

[@rafaspimenta]

Eu trabalho com SAFe há alguns anos. Eu diria que ele adiciona uma camada acima das sprints para conectar o que está sendo desenvolvido com o roadmap de um produto. Por exemplo, o SAFe sugere ciclos chamados Program Increments (PIs), que duram geralmente de 8 a 12 semanas, ou 4 a 6 sprints. Então, a cada PI, se planeja o que será desenvolvido nessas sprints pelos times.

[@darlanluzo]

Se o prazo para arrumar for mesmo 6 anos, temos um provavelmente problema na de concepção do projeto. Encontrei uma situação em um projeto que se dizia pronto, porém não atendia o requisito de ter os dados históricos. O banco de dados escolhido não tinha esse mecanismo e fazer nele da forma que queriam era inviável. Ou seja era melhor trocar a tecnologia de persistência dos dados. A sorte que aceitaram um nível mais simples de auditoria. Agora se fosse uma exigência teríamos um belo retrabalho. Quanto a não poder voltar, pode ser também a fatores de legislação/features que só tem no novo. Deixando assim a impossibilidade de voltar.

[@InazumaRyoushi]

já realizei ambos (refactor e rewrite), uma solução boa foi reutilizar uma peça de integração entre os sistemas e cadastrando uma nova lógica de integração para a peça reescrita, hoje utilizamos ambas as peças de acordo com o tipo de investimento e temos cerca de 20% na peça legada e 80% na peça nova realizando uma migração parcial de acordo com a priorização dos projetos (a velha disputa de prioridade entre novas features na peça nova e matar de vez o legado)

[@InazumaRyoushi]

são aqueles 20% q atualmente não pagam o custo benefício de migrar, e possui mais ganho focar em features novas para a nova peça

[@Helheaven]

Eu fiz a proeza de reescrever dois sistemas, no primeiro sistema foi em equipe passando um sistema um sistema delphi para web, o segundo por conta da dificuldade de desenvolvimento resolvi reescrever e no fim perdemos um cliente por isso. Mas a experiencia desta reescrita permitiu fazer um outro sistema mais estável e que passou a ser usado por outro cliente. A reescrita parece um sonho para muitos, mas é muito arriscada e nem sempre se torna possível. Estou examinando algumas POCs para isso e esta sendo bem complexo.

[@BrocchiRodrigo]

Eu tenho certificação no SAFe PO/PM e Teams, treinamento de leading tbm. Para grandes companhias como Petrobras, B3, Cogna (Kroton), Globo, entre outras com uma quantidade de projetos e times pulverizados, funciona bem melhor que o velho cascata com zilhões de casos de negócio perdidos sem atualização alguma nos sharepoints da vida. E sim eu já vi esse cenário e deu certo. Lá fora até a Nasa adaptou a metodologia para rodar e tem muitas empresas gigantes no EUA que rodam. Inclusive a NASA é um dos cases de sucesso a nível global. Pouca maturidade dessa liderança que provavelmente terceirizou as decisões da entrega gerou esse problema. Na vdd esse é um cenário mais comum do que parece, e aí é exatamente quando todo o processo está baseado em métodos antigos, adaptado errado e aí realmente ele desaba totalmente. Aqui no Brasil as empresas que rodam tem cases de sucesso muito bem falados inclusive. A Petrobras inclusive alinhando a metodologia é praticamente uma máquina de entregas em um nível fantástico, mas o primeiro case que tive oportunidade de presenciar e que funcionou perfeitamente adaptada por um ex VP da Globo e B3 foi na Kroton. Foi uma loucura no começo, mas depois rodava muito bem.

[@medeirosnvk]

Isso se encaixa muito com a minha situacao de trabalho atual! A empresa do setor de cobrancas em questao usava PHP/Delphi e me contratou para reescrever em Javascript usando Node.js. Fizemos tudo do zero e a aplicacao atual é independente e funciona com o banco, entao um sistema nao interfere no outro. Mas claro, fizemos isso tudo sem time (apenas o lider TI e eu, dev JR), sem prazo e aos poucos, justamente por coexistirem. O prazo e a pressao mudaria tudo.

[@jefersonvr]

No scrum é possível fazer microgerenciamento, fingindo dar autonomia as equipes. É possível o negócio determinar os prazos, fingindo que a equipe está no controle. É possível apontar culpados, mesmo que o culpado seja quem está apontando o dedo. O Scrum é sim um bom framework, mas sempre é usado da forma “certa”, certa para alguns gestores. Acredite em mim, já estive dos dois lados.

[@JuninhoImperatori]

Já vi gestores de TI venderem sonhos para a Alta Administração, mas não os informarem adequadamente sobre os riscos da "missão", seja por quererem bancar o herói ou por excesso de boa vontade/destemor megalomaníaco por desafios. Só pensar no caminho feliz, não conhecer bem as (in)competências do time técnico, não trabalhar na capacitação da equipe (ou na contratação externa destas competências, dependendo do caso) e, principalmente, não repassar corretamente informações sobre riscos, de forma sóbria para a Alta Administração, deixando que a decisão seja dos cabeças e não da TI, não é suicídio, mas terrorismo, pois leva muita gente na carona do próprio ego.

[@dinossauroromano]

Pode rir, mas esse exemplo que você deu do check-out foi exatamente o que a epic games fez com o epic store, nem carrinho tinha!

[@btkcompany1]

O processo muitas vezes só existe pra ter quem culpar, é muito mais fácil para uma gestão implantar e seguir processos e culpa-los pelos resultados do que assumir riscos e o ônus da responsabilidade.

[@sedraccalupeteca5769]

Todos sistemas que trabalhei são legados, eu sempre faço a escolha de uma metodologia tradicional para o desenvolvimento (RUP, CASCADE) para os meus projectos na fase de construção depois de estarem em produção alí penso em utilizar uma metodologia ágil. Não entendo bem a ideia deste movimento ágil, na minha experiência encontrei mais pessoas preocupadas em terminar projecto em tempo curto como maior prioridade e são aqueles projectos em produção ficam sempre a receber tantas feature para correção de erros. Por isso que fico sempre começo em Cascata (testando todo fluxo de forma rigoroso, prefiro ficar preso num fluxo até resolver o problema para prosseguir, do que passar por cima).

[@Demetriofim]

Fazia uma v2 em paralelo, depois que tivesse sido testado em homologação com casos reais, subia para produção e vai migrando por departamento, se for dando bom, vai migrando até virar tudo. Aí é só desligar a v1.

[@mpjogos]

"Se você quer rápido, vai no xgh!" Montano, Lucas. 2024

[@bernardo1496]

Lê se isso faz sentido, Lucas montano do canal lucas montano. "Toda rewrite é uma refactore, mas um refactore não é uma rewrite."

[@eliass.monteiro9331]

Estou com 3 anos como backend e ja fiz tanta refatoracão que perdi as contas. Seja na implementação ou melhoria da arquitetura, planejando a implementação de um design patterns ou refazendo regras de negócios para otimizar algum processo e melhorar principalmente a vida do cliente. Mas rewrite só fiz um e já estou responsável por mais dois sendo que um desses dois é mudar o EDA de SSE para WS. Pra mim, rewrite é bem mais complexo e difícil porque tem que ser algo bem planejado, principalmente entre a liderança pois todos tem que estar ciente e saber quais são os riscos e benefícios a serem encarados. Obs: sempre que tenho a oportunidade de conversar sobre rewrite e refactor, eu digo que é "perda de tempo", não só sentido literal, mas sim que se não for planejado e tiver uma real necessidade, não tem motivos para mexer. Vira perda de foco, desvio de prioridade e o principal que pode ser perda de verba. Nós como desenvolvedores temos sempre que nos questionar se tem necessidade, qual objetivo, quais impactos, riscos e benefícios que tal "task" vai causar dentro daquele escopo ou regra de negócio.

[@alejandrokennedy]

Estoy trabajando en un proyecto de re write, mantenemos las dos versiones del sistema y vamos migrando de a poco, habilitando feature flags, muchos flujos todavia son redirigidos para el sistema legacy. Trabajamos con scrum y vamos bien. Cada vez veo mas cerca suprimir el monolito. No se puede tener una feature que este bloqueando el negocio completo. El sistema Legacy deberia seguir operativo y mas aun cuando la parte mas importante del business flow no estaba lista.

[@Leanst.]

Rapaz, eu tenho muita curiosidade do porque estas catástrofes acontecem, na cabeça da gente fica claro as merdas que podem acontecer e geralmente nos mobilizamos para elas não acontecerem num refactoring, mas deixar chegar a essa tragédia aí é incrível, ainda mais em uma equipe experiente.

[@esgrijo]

Isso ai esta mais ligado a falta de gestão do que ao SAFe em si, o SAFe é adaptável às necessidades de cada cliente.

[@JonatanEdOrtiz]

Nem precisa ser uma mudança grande, isso sempre acontece quando o backend precisa alterar algo em um endpoint já utilizado pelo front por causa de uma feature nova no front que precisa de uma modificação no recebimento dos dados. Se você adicionar novos campos geralmente não tem problema nem para web ou Android ou iOS, porém se modificar dados já utilizados as versões antigas do front vão quebrar e no caso de mobile dependemos do usuário atualizar o app. Ou seja, as duas (ou várias) versões precisam ficar rodando para não perder usuários, ou se não, fazer o force update, mas isso tbm leva usuários a desinstalarem porque não gostam de aplicativos que forçam atualização pra que possa ser utilizado. Enfim, geralmente a empresa opta por manter o back suportando várias versões do front e tbm gera um custo. Se não ficarem espertos a empresa pode se ferrar no futuro.

[@thommy_80]

Lucas, desculpe, mas já há algum tempo assisto seus videos e seu topete sempre me traz a mente o filme Quem vai ficar com Mary? 😂😅

[@assiszang6191]

Dividir para conquistar, concordo plenamente em fazer pequenas refatoracoes e ir lidando com os bugs de forma isolada. Só na questão da responsabilidade, acho que o arquiteto que permitiu algo assim também tem uma parcela de culpa

[@bz_starfox]

A Holanda ta te mudando kkkk… Primeiro a franja do Tim-tim, agora o alargador hehehehe. Bom vídeo, curti a análise.

[@LoneDWispOfficial]

Sou sênior com tempo de experiencia de junior, pois oq eu mais tive que fazer era resolver bug, e refatorar o escopo para melhorar a manutenção do escopo das UI legado de react contendo useEffect com callback de 100 linhas dentro do hook, com múltiplos setters dentro do callback e 15 re-reenders com vários fetchs entrelaçados. Detalhe, refatorando sem quebrar as funcionalidades e componentes, pois muitas pessoas mudam o código quebrando features e consertando, e chamam isso de refatoração.

[@LassNoches]

por isso que para mim hoje em dia iniciar projeto react sem uma arquitetura tipo mvvm é uma doidera, eu sei exatamente do que vc ta falando pq o projeto que trabalho atualmente é assim, react por ser "simples" no inicio acaba fazendo todo mundo achar que sabe tudo e no fim o codigo é um LIXO, é vazamento d ememoria em tudo quanto é tela, codigo misturado de varios tipos e um monte de retrabalho todo dia

[@rodrmore]

Já passei por reescrita, e é um desafio grande. No meu caso as metodologias ágeis foi um ponto crucial para o sucesso do projeto. Sistema muito grande, legado muito antigo com muitas incertezas. Tínhamos que fazer entregas parciais que fossem transparente para os usuários. E quando aparecia alguma nova demanda evolutiva tinha que se decidir se poderia esperar até o ponto onde pudesse ser desenvolvido apenas no novo, se poderia ter uma solução paliativa no antigo ou se era urgente ou crítico e precisaria desenvolver nos dois e duplicar os custos da demanda. No final, apesar de aumento de custo e prazo por conta dessas situações e de outras, finalizamos e superamos a expectativa dos clientes/usuários.

[@xlucioflavio]

Metodologias não são nem nunca serão bala-de-prata. Isso é apenas o setor público sendo setor público.

[@sama_gotec]

08:03 foi a primeira coisa que pensei ao ver o título do vídeo. kkkkk

[@ideiasBrasil2023]

Se Agile faliu a empresa, ela falaria muito mais rápido com qualquer outra tecnologia de desenvolvimento.

[@abimaeelmouraa]

Antes de lidar com uma refatoração é muito importante planejar toggles técnicas (ler Refactoring) e testes automatizado. Caso contrario, é assumir que um b.o vai cair no seu colo pra resolver. Se tivesse toggles era só mudar pro sistema anterior e tava tudo certo. Concluo que talvez o problema não tenha sido o scrum, talvez tenha sido a péssima execução?

[@wdscode]

Quem nunca.... 😂😂😂😂😂

[@thiagoepaminondas7215]

lucas esse caso tem cara que o antigo dev pediu conta e jogou o hd no fogo

[@fooxmotoroad]

O que leva a uma falencia é decisao de diretor que vem top-down... TI nao define negócio.

[@dvdonadelli]

agile é o "paradoxo do barco de teseu" da engenharia de software, quando terminar de trocar a última peça, será que estamos trabalhando na mesma coisa que começamos ou é algo totalmente novo? isso significa que a partir de agora é um novo barco e vamos ir continuar precisando trocar peça

[@rafaelschueng]

Quando você vê algo grande dando problemas dessa forma normalmente não existe um culpado mas sim vários culpados. Normalmente um conjunto de decisões erradas somadas à outros fatores como desenvolvedores e gestores e etc... Eu gosto de fazer analogia dizendo que construir um software é como construir uma casa/prédio. Uma casa não cai por causa de uma pilastra fraca ou ruim... A casa tem várias pilastras e elas normalmente são projetadas para lidar com a falha eventual de uma ou outra mas também se não tiver noção da quantidade e da necessidade dessa pilastra no lugar certo, teu projeto pode afundar já que você não tomou a decisão de calcular os número necessário delas, construir o número certo delas e etc... Você acaba sendo cobrado pela sua decisão errada no futuro. Não existe injustiça aqui... Apenas engenharia, tradeoff e etc... Você foi livre pra escolher mas refém das consequências.

[@winstonchurchill9721]

Teve uma época que existiam promessas de ferramentas que iam permitir gerar código a partir dos UML, casos de uso em diagramas e assim diminuir trabalho com códigos. Depois veio a agile em reação contra esse hiper foco em ferramentas que eram usadas pelos analistas. Ao fim na prática o Agile matou a formação de bons analistas de sistemas, analistas de requisitos 😂. O importante é cada um no seu quadrado. E preciso bons engenheiros, analistas, arquitetos e programadores. Faltou isso nessa empresa.

[@racoelho]

Eu precisei reescrever a API de Acordo de Dívida de um banco digital. E foi bem parecido: desligaram COMPLETAMENTE o aplicativo até que o rewrite estivesse completo. Mas isso porque uma das razões do rewrite era de medida de segurança. Então, por 3 meses, o banco ficou com o serviço que significava 20% da receita completamente fora

[@fabioa8059]

Gosto da estratégia de rescrever o sistema por partes, isolando cada funcionalidade do legado, e reescrevendo elas uma a uma como micro serviços que se comunicaram com o legado. É crítico garantir a performance nesse cenário, ja que as aplicações vão interagir ao invés de ser um grande Monolito

[@asdyull-dk4nt]

Bixo... Como alguém decide fazer um rewrite e escolhe dynamics como destino e ainda leva 6 anos? Eles estavam copiando o SAP dentro do dynamics?

[@smcodesp]

Complementando, acredito que um desenvolvedor senior se torna senior quanto ele consegue de maneira pratica e direta a refatorar e reescrever codigo de outro ser e não exatamente só de si mesmo, planejando o processo e executando de maneira sustentável.

[@MateusMorais-ug1vl]

O problema das refatorações é que geralmente uma refatoração chama a outra, que chama a outra... Não dá para refatorar um código e replicar até mesmo os bugs da versão antiga, aí você chega no PO e diz que X vai ter que ser X + Y e ele acha que você só está sendo displicente. Eu refatoro, mas se na primeira oportunidade o teste não bater com o resultado antigo, eu volto ao estado anterior e só reporto como incoming bugfix mesmo (quem pegar primeiro a task, leva, igual pescaria, já sou quase o próprio apresentador da Fish TV)... Já lidei com um caso onde um endpoint importantíssimo estava descoberto pelo middleware de autenticação e roling, apliquei a correção, mas quebrou pois esse endpoint prevê uma ordem específica de middlewares a serem executados sem muita margem para novos middlewares. Só reportei. Uma semana depois eu vi a correção que fizeram: aplicaram no início do controlador uma raw query que verifica se o usuário é role > X. Hehe. É a mágica da multiplicação: transformaram um refactor a ser feito urgente em dois.

[@machinen2]

Esse caso diz muito mais sobre eficiência dos serviços públicos do que a metodologia scrum... Scrum foi só um detalhe nessa história toda

[@MrClicaaqui]

Já trabalhei com safe foi um pesadelo, pior organização que já vi em uns 15 anos de carreira 😅

[@andrewinkler9538]

Por isso então que tem Data Engineer virando sênior em dois anos. Toda hora estamos reaftorando alguma velharia ou migrando esses legados para a Cloud. 🤣

[@refatorador]

Em breve no meu canal técnicas de refatoração, com sorte, chegue até eles kkkk

[@LeandroGuilhermano]

o Agile resolve TANTO problema do gohorse / waterfall que dizer que não serve é total desconhecimento. -Precificar projetos (pontos médio por dev, custo de cada ponto, custo do projeto) -Simplificar o contato com o dev através das agendas daily, planning de forma a deixar o dev livre pra codar -Alta rotatividade na equipe? sem problemas, todos temos uma curva de aprendizado e com o tempo conseguimos mensurar isso através dos pontos fora muitos outros

[@csakamatsu]

Fazer do zero significa jogar todo o conhecimento adquirido na construção pelo método antigo fora. Ou seja, muitos desconsideram esse conhecimento como algo que não deve ser feito, levando a briga de achar outras soluções, sem esse conhecimento. É uma lacração temporal. Muito comum em Administração, culpando a Administração anterior, e, diga-se de passagem muiito comum em política.

[@Olavo_Carvalho]

Mano se for pra dynamics tá explicado 😂. Tem um bang que dá no dynamics que é você precisar reestruturar o sistema. Eles falam que se chama restruturação de BU. Basicamente a empresa montou um prédio de 3 andares e daí começou escalar o dynamics para um prédio de 72 andares em Dubai 😂. Sistema ele não Guenta

[@luislobo9b]

Nesse critério aí sou sênior fácil kkkkk. Há uns 5 anos eu entrei em uma empresa que não usava github e tinham perdido os arquivos originais e só existiam os arquivos do build minificado. Quando entrei já tinha um maninho bem Jr. que ficou se matando e entendia o projeto em partes. Ele me auxiliou e depois fui eu, um ano e pouco, refatorando pedaço por pedaço. Ué, mas não seria melhor recriar? SIM, mas quem disse que autorizavam? kkkkk. Pois é, foi hard, mas quando sai de lá já estava quase 100% fora uma porrada de novas features

[@Eduardozsh]

Deram um gh delete repo antes de iniciar o novo projeto kkkk

[@decosimpatia]

Raramente uma migração é 1 pra 1, mesmo que seja 1 pra 1 alguém sempre vai fazer besteira e antecipar essa descoberta vai ajudar o fluxo do processo como um todo com um custo menor. Eu já fi migração de sistema utilizando o pensamento Ágil e foi excelente, pois além do que disse acima, você pode repensar como cada feature é de fato necessário para o contexto mais atual da empresa e seus usuários.

[@thyagojunior2542]

Quando o sistema legado não tem boa cobertura de testes é péssimo de refatorar, muitas vezes se torna viável a reescrita. Aí que entra a conta de não "perder tempo" escrevendo testes

[@StefanoCibi]

No Brasil o governo cobra primeiro e só anos depois entrega o serviço, serviço bem porco...

[@gepetovovo2509]

mas privado tb é assim amigo.. ou tu acha q só tem sistemas redondos ai ??? kkk

[@edusilva.mp4]

Rapaziada, eu trabalho como solution architect aqui nas trincheiras (com Dynamics 365 ERP), em quase todo projeto de migração/implantação do ERP a equipe de desenvolvimento sofre com decisões da diretoria/gestão do projeto que querem forçar o go-live do sistema mesmo ele não estando pronto. Mas pelo que percebo aí teve uma falha geral na migração: 1. O código legado que tem nesses ERPs antigos e precisamos migrar pro 365 cloud-based na maior parte das vezes não atende os novos requisitos e a solução precisa ser pelo menos parcialmente reescrita. 2. Fizeram o go-live do 365 cloud-based e inutilizaram o ERP legado???? Queria mais detalhes da merd*. Se o problema foi a parte de cobrança então quer dizer que a venda nunca integrou no ERP, o valor nunca pôde ser acompanhado pq o ERP antigo foi desligado. 3. E o pior, durante o desenvolvimento do projeto, pra onde foram as etapas de teste integrado e o QA? Os caras não testaram faturamento, recebimento e etc? Pqp que bizonho kkkkkkkkkkk

[@LucasMontano]

cara deve ter sido uma decisão errada grande, com muito otimismo envolvido

[@freitasLeafar]

SAFe é o cascata que se vende como ágil, acho que hoje o maior problema das metodologias são as pessoas. Existem muitos "agilistas" que pregam scrum, XP, safe, etc. mas que não conhecem nada de engenharia de software, não entendem nada de métricas e como deixar o time trabalhar. Já passei muito por isso, empresas que estão adotando o ágil, mas que cobram uma quantidade de métricas absurdas, fazendo os dev's perderem mais tempo com processo e preenchendo tasks no Jira do que codando. Fora que ainda não entendem o ágil em si. Criam um backlog, sprints e tudo mais, mas esquecem que o objetivo é ter o "core" do software pronto o mais rápido possível, e, a partir daí, incrementar, adicionar mais features. Nisso boa parte olha para sprints como cascata, pensando em uma data fixa e trabalhando pra entregar o produto somente nessa data (funcionando), perde-se a ideia de ter um MVP desde o início.

[@Kimitri]

Mds eu sou sênior e não sabia kkk eu reescrevi um sistema legado monolítico inteiro, foi um infernoo mas deu um alívio quando acabou kkk

[@pauloacosta2115]

Larguei a área de desenvolvimento e virei analista de requisitos Meu time com 3 devs entregava mais que todas as squads somadas, justo porque vimos que não precisávamos de todas aquelas etapas que só faziam perder tempo. Conhecíamos como as ordens vinham e como funcionavam e agíamos em cima disso.

[@juniorstreichan-dev]

Reescrever sistema, gostoso demais!

[@rafahsistemas]

Cara, mas em Amsterdam?!?!?! O que você acha que eles tinham na cabeça quando tiveram essa ideia?!?!?!

[@andersonl.sergio166]

Para mim é estranho que refatoração (pelo menos nos termos do Martin Fowler) não seja o dia a dia de um SW minimamente experiente. Pois não se trata apenas de melhorar aspecto ou desempenho de software legado, mas também de constantemente evoluir o code base conforme requisitos novos vão entrando. Se não houver refatoração estratégicas e pontuais no dia a dia, é ai que o code base “apodrece” aos poucos precisando de um esforço monumental e dedicado para a reescrita ou refatorações intrusivas (claro que esse não é o único motivo, mas um dos principais)

[@lexgameplay8041]

Metodologias para gestão do projeto, são apenas formas de de organizar o trabalho. Neste caso ai nitidamente não foi culpa do SAFe, do scrum ou qualquer outro processo. A metodologia não decide se vc vai refactorar ou reescrever código e nem se fará o desenvolvimento em módulos, em pedaços ou seja como for. Me parece que a equipe que plenajou tudo isso ai não sabia nem o que estava fazendo ou sequer onde queriam chegar com isso. Mas tenho certeza que este projeto seria furada até mesmo no waterfall.

[@gstella]

reescrever é a primeira red flag de que o time não é bom

[@jhony_tech]

É fácil culpar o refactoring ou metodologia X, quando o problema muitas vezes é devs fracos. Obs: vi que chegou a mesma conclusão

[@Rodolfomatbar]

Se for relacionado a gestão publica, e você tem um saldo devedor para o governo, o governo vai cobrar, mesmo que seja depois. Para uma empresa privada fazer isso, precisa ter um bom investimento, e um planejamento estratégico a longo prazo.

[@esmaellwinter]

Já fiz uma reescrita com SAFe.. que inferno!!! Na hora de entregar o sistema ficou parado em produção por 1 mês, mas conseguimos botar de pé!

[@ros2211]

Aconteceu pq o sênior em 6 meses deletou o antigo, pq era muito pica!!!!

[@rafaelaraujodynamics]

Eu trabalho como dev no sistema Dynamics 365 (mencionado no vídeo) e é um ERP pronto como o SAP. “Reescrever” ele todo não acontece, simplesmente não existe isso. Quem escreveu no X nem leu sobre o que é o sistema. Certeza que o problema foram os profissionais, que não conseguiram migrar os dados e fazer as integrações pra versão nova.

[@josoebraga]

Eu sou do time " se está funcionando, não mexa".

[@jricardoprog]

Isso é falta de conhecimento, experiência e testes automatizados.

[@AlexeiDimitri]

Acho que sua diferenciação de rewrite e refactor não fazem sentido. Isso tudo depende da arquitetura do sistema. Se vc usa um Kafka ou algum outro sistema de mensageria, vc divide os pedaços do sistema em módulos, que em tese funcionam como serviços Logo, é independente como um serviço funciona ou foi feito, basta ele seguir a especificação Eu dificilmente vejo um time de TI hoje em dia que não use GIT ou outro sistema de controle de versão para fazer software, então relegar reescrita simplesmente a controle de versão tá errado A ideia da reescrita é vc escrever do zero, ignorando o que tinha antes, perseguindo apenas o que o serviço deve entregar Já o refactor é uma PEQUENA correção, cujo objetivo não é mudar o que as coisas entregam, mas apenas seus aspectos internos (por exemplo a mudança no nome de uma variável e todas suas ocorrências, o empacotamento de funcionalidade de uma classe por uma factory, etc). O que aconteceu com essa empresa ao que parece é que o sistema antigo foi todo desmontado (o que incluir hardware e sensores) e o software dele foi feito em alguma arquitetura e linguagem legadas, que impede o software novo de conversar com o antigo. Como tem dinheiro público envolvido, eles ficaram muito focados em ficar fazendo marketing e pagando propina para várias pessoas e deixando o desenvolvimento do sistema de lado. Quando alguém começou a exigir que algo fosse entregado, eles simplesmente deixaram a etapa mais importante por último e na hora de virar a chave (trocar o novo pelo antigo) já não dava mais pq tinha muita coisa velha que provavelmente foi quebrada e que já não dava mais para fazer voltar a funcionar.

[@elecmanuau7957]

Scrum é dado em algumas faculdades, métodos ágeis, gestão em ti, etc.

[@bobs123123]

na projeto que eu trabalhava aqui na firma, entrou um "dev SR" e ele achou uma boa ideia sugerir fortemente a refatoração TOTAL do sistema, resumo, a diretoria preferiu terceirizar o "serviço de software" do que manter um sistema próprio. Resumo: 6 devs realocados e um Tech Lead demitodo kkk

[@taisamachado5727]

Apenas migrar uma aplicação grande pra cloud já é o CAOS e precisa de um bom planejamento de rollback, imagina reescrever sem rollback 😳, eu nem consigo imaginar o nível de stress dos Devs.

[@Rodolfomatbar]

Se for no Brazil, a primeira coisa que é criador é cobrança kkkkk Entregar, so daqui a uns anos e super faturado.

[@candinhosilveira2047]

por isso gosto do metodo kiss

[@matheus_MVPMB]

Excalidraw é muito útil e prático Uso toda semana

[@ffabiop3735]

Software hoje tem de ser escrito para ser rapidamente entendido, e para ser jogado fora com facilidade para ter outro no lugar.

[@LassNoches]

essa é a expectativa, a realidade são decisoes erradas do INICIO ate o fim, codigo macarrão para todo lado e correria todos os dias. Ja cheguei a participar te um projeto bem grande de uma empresa grande de varejo que recebeu um "upgrade" de investimentos para expandirmos para outros tipos de disposivivos e as decisões erradas levaram ao projeto novo ja iniciar a mesmo bosta que o legado, mantinhamos duas bases de codigos fazendo a MESMA BOSTA com varios adapters e body parsers ridiculos e tudo isso pq no inicio dos projetos ninguem da chefia e especialistas questionou ou procurou saber a melhor forma de fazer.

[@debuggando]

Hoje caiu um Nó inteiro do Kubernetes em prod, quero ver que IA que vai substituir a correria que tivemos que fazer kkkk

[@TFTGalactus]

Reescrevi uma interface inteiro do 0 para melhorar performance e deixar o design mais moderno, so que nao me repassaram os novos requisitos que iam sendo adicionados na versao anterior, terminei de escrever a nova interface, colocou em prod, e dps volto para anterior por falta desses novos requisitos que foram implementando enquanto eu fazia a reescrita ^^

[@marcellussimoes498]

Aí ter noção dos principios da ITIL4 se torna besteira pra muita gente. Melhor começar de onde você está... sempre!

[@psantos21]

Certeza que o Engenheiro que fez essa proeza era o sênior de 2 anos, em 6 meses ele ja era pleno ganhando 20k na gringa 🤣