Reescrever do zero nÃĢo ÃĐ boa ideia (Rewrite levou empresa a falÊncia)
āļāļąāļ
- āđāļāļĒāđāļāļĢāđāđāļĄāļ·āđāļ 10 āļ.āļĒ. 2024
- ð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...
Comunidade do Discord
discord.gg/5uV96SVF
estÃĄ dando como convite invalido luqueta
NÃĢo tÃĄ pegando Lucas Montano do Canal Lucas Montano!!!
Vamos discutir esse link que nÃĢo esta funcionando na daily de amanhÃĢ.
@@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.
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.
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.
Sim, mt mais ÃĐ quem executa do que como ÃĐ executado...
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
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.
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?
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.
Pofexor Luxa sempre ensinou: Eu ganho, nÃģs empatamos, vocÊs perdem.
O bom e velho:
A culpa ÃĐ minha, entÃĢo ponho em quem eu quiser!
ð
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.
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..
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.
@@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.
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
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...
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.
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.
@@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...
@@gepetovovo2509 A alternativa ÃĐ ficar segurando "a granada sem pino" atÃĐ onde der... Quando nÃĢo der mais o resultado serÃĄ o mesmo... FalÊncia!!!
@@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!!!..
@@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...
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
Tive um agile tambem e me faliu quando fundiu o motor e descobri que ÃĐ um motor argentino que nenhum outro carro usa.
Pow Lucas poderia fazer um vÃdeo maneiro explicando nosso querido XGH na prÃĄtica hein
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.
E ÃĐ por isso que tem banco usando COBOL e ninguÃĐm toca, muito menos troca.
TÃĄ trocando ... Trabalho em banco , mas ÃĐ lento isso. Alguns partes talvez vai demorar bastante.
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.
Banco do Brasil ÃĐ cobol atÃĐ hoje.
Mais fÃĄcil comprar um banco moderninho que jÃĄ tÃĄ com a tech atualizada kkk
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
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
Precisam contratar o Haddad para consultoria. Ele sabe cobrar impostos sem atraso e inventar novos impostos.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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
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.
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.
LÊ se isso faz sentido, Lucas montano do canal lucas montano.
"Toda rewrite ÃĐ uma refactore, mas um refactore nÃĢo ÃĐ uma rewrite."
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
Se Agile faliu a empresa, ela falaria muito mais rÃĄpido com qualquer outra tecnologia de desenvolvimento.
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
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!
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.
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
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.
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
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.
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?
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.
O que leva a uma falencia ÃĐ decisao de diretor que vem top-down... TI nao define negÃģcio.
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.
Metodologias nÃĢo sÃĢo nem nunca serÃĢo bala-de-prata. Isso ÃĐ apenas o setor pÚblico sendo setor pÚblico.
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?
ðð
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
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.
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
JÃĄ trabalhei com safe foi um pesadelo, pior organizaçÃĢo que jÃĄ vi em uns 15 anos de carreira ð
Quem nunca.... ððððð
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.
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
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
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
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.
No Brasil o governo cobra primeiro e sÃģ anos depois entrega o serviço, serviço bem porco...
mas privado tb ÃĐ assim amigo.. ou tu acha q sÃģ tem sistemas redondos ai ??? kkk
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)
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ÃĐ!
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
cara deve ter sido uma decisÃĢo errada grande, com muito otimismo envolvido
"Se vocÊ quer rÃĄpido, vai no xgh!" Montano, Lucas. 2024
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 ^^
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
Ainda nÃĢo entendi a crÃtica à metodologia; para mim, parece uma mÃĄ execuçÃĢo. Isso pode ser motivado por diversos fatores, desde equipes que nÃĢo concordam com a reestruturaçÃĢo e estÃĢo desmotivadas, atÃĐ a falta de profissionalismo na gestÃĢo das tarefas.
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.
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.
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.
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?
à fÃĄcil culpar o refactoring ou metodologia X, quando o problema muitas vezes ÃĐ devs fracos. Obs: vi que chegou a mesma conclusÃĢo
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
08:03 foi a primeira coisa que pensei ao ver o tÃtulo do vÃdeo. kkkkk
Cara, mas em Amsterdam?!?!?! O que vocÊ acha que eles tinham na cabeça quando tiveram essa ideia?!?!?!
Deram um gh delete repo antes de iniciar o novo projeto kkkk
Software hoje tem de ser escrito para ser rapidamente entendido, e para ser jogado fora com facilidade para ter outro no lugar.
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.
Em breve no meu canal tÃĐcnicas de refatoraçÃĢo, com sorte, chegue atÃĐ eles kkkk
lucas esse caso tem cara que o antigo dev pediu conta e jogou o hd no fogo
Scrum ÃĐ dado em algumas faculdades, mÃĐtodos ÃĄgeis, gestÃĢo em ti, etc.
Excalidraw ÃĐ muito Útil e prÃĄtico
Uso toda semana
Aà ter noçÃĢo dos principios da ITIL4 se torna besteira pra muita gente. Melhor começar de onde vocÊ estÃĄ... sempre!
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. ðĪĢ
A Holanda ta te mudando kkkkâĶ Primeiro a franja do Tim-tim, agora o alargador hehehehe. Bom vÃdeo, curti a anÃĄlise.
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
Se for no Brazil, a primeira coisa que ÃĐ criador ÃĐ cobrança kkkkk
Entregar, so daqui a uns anos e super faturado.
Isso ÃĐ falta de conhecimento, experiÊncia e testes automatizados.
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.
Eu adoro mÃĐtodo ÃĄgil. Com esse mÃĐtodo eu todo dia apago cÃģdigo e isso perpetua meu emprego.
reescrever ÃĐ a primeira red flag de que o time nÃĢo ÃĐ bom
AlguÃĐm foi da ÃĐpoca da Unified Modeling Language (UML), que mais tarde se tornou parte da ferramenta Rational Rose? Affff...
Sou junior e vou ingressar em uma reescrita de um sistema inteiro com mais um junior quase pleno, podemos dizer que seremos senior daqui a 2 anos ? kakakaka
Reescrever sistema, gostoso demais!
Que programa ÃĐ esse que o Lucas usa pra desenhar?
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 ðĪĢ