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

✅ Torne-se membro para obter aulas técnicas exclusivas comigo:

Fontes:

✅ 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:

✅ 𝗢𝗦 𝗠𝗘𝗟𝗛𝗢𝗥𝗘𝗦 𝗩𝗜𝗗𝗘𝗢𝗦 𝗗𝗢 𝗖𝗔𝗡𝗔𝗟

▸ 3,700,000 requests do MrBeast na API do X (eu tentei e não foi barato)

▸ Programação realmente é muito difícil?

▸ DEV Precificando Projeto tipo Netflix (bem simples)

▸ OpenAI choca o mundo +1 (mas Sora não é sobre gerar videos)

▸ IA que utilizo & a mentira da Gemini (Nova IA do Google)

[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 😂😂😂

[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?

[Adams]

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

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

[fernandoferreiradentalpres]

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.

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

[edmilson]

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.

[Justy-SE]

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

[trcvince]

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

[MichelAraujo]

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.

[franklinsantos]

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

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

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

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

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

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

[carreiraglobal]

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.