Executando verificação de segurança...
4

VOCÊ JÁ PENSOU EM REFAZER UM PROJETO DO ZERO ? TALVEZ ESSA NÃO SEJA A MELHOR ABORDAGEM!

Imagine que você tem uma empresa de delivery e os clientes começam a reclamar de que os pedidos estão demorando muito. Ao investigar, você descobre que nas primeiras entregas, o entregador vai bem, mas depois fica cansado porque faz as entregas de bicicleta.

Nessa situação, você consideraria trocar toda a equipe ou faria um esforço para comprar uma moto para o entregador ir mais rápido?

Muitos desenvolvedores por aí acham que quando um sistema grande e antigo começa a dar problemas, a melhor forma de resolver é refazer do zero com tecnologias atuais. (Em alguns casos pode até ser e dar certo)

Mas tenha em mente que refazer todo o projeto pode ser uma tarefa muito trabalhosa e demorada, especialmente se o projeto é grande e complexo. Talvez até bem mais do que você planejou além de não ser uma solução tão econômica.

Em vez disso, você pode identificar as funcionalidades principais e prioridades do projeto, e criar um plano para reorganizar e otimizar o código existente. Isso pode envolver reescrever partes do código (como camadas de adaptadores ou proxy's para lidar com fluxo que já é conhecido pelo cliente mas com um código melhorado), criar novos módulos ou componentes para melhorar a arquitetura geral do projeto, e fazer ajustes para melhorar a performance ou a experiência do usuário.

Pode ser mais difícil, claro. Mas o software se torna mais eficiente, econômico e sustentável.

Carregando publicação patrocinada...
3

Posso discordar e concordar ao mesmo tempo?

Vou discordar porque faz uma afirmação que refazer um projeto do zero é sempre ruim, que falta maturidade em quem decidiu fazer isso. Isso é claramente falso.

É verdadeiro em muitos casos, talvez maioria, e pode até mesmo ser quase todos, até porque eu não tenho dados, e ninguém tem para afirmar qual é a quantidade.

Qualquer afirmação de 100% sem contexto é errada, até porque mesmo que acerte será só porque tinha 50% de chance de estar certa.

Na minha visão de 40 anos fazendo e acompanhando sistemas, completamente do zero, pegando sistema andando e decidindo refazer do zero, ou preferindo só ir dando manutenção, em alguns casos refazendo todo ele mas não do zero, falta maturidade sempre que a opção for 0 ou 100. Só sabendo do caso concreto pode-se tomar uma boa decisão. Falar que deve fazer algo sempre, mesmo que as chances sejam boas de acertar porque a maior parte dos casos acontece isso, é jogar pôquer.

A analogia ajuda a entender a questão, mas não mostra o problema porque são coisas completamente diferentes. Mas também porque não é algo que aconteça de fato, e se acontecer é claro que é para resolver a questão pontual. Ninguém decide refazer do zero todo sistema porque tem um relatório que está saindo com valores errados.

Em caminhões, ônibus, aviões, e outros veículos de frotas tem hora que aposentam o que não compensa mais dar manutenção e pegam um novo que custa absurdamente mais caro. Não posso fazer uma analogia com isso porque o custo de aquisição e manutenção em cada caso é absolutamente previsível, em software não é.

Justamente porque o custo não é previsível é difícil tomar decisão, e é necessário demonstrar com clareza que uma opção é melhor que a outra e que não há tanto risco assim no caso concreto. E a minha experiência mostra que é comum não compensar fazer algo do zero. Mas também há casos que compensam, como uma empresa de transportes faz.

Tem casos que a qualidade do código é ruim demais, e não está trazendo vantagens. Eu já peguei um sistema que tinha uma média de 5 warnings por linha, e algumas linhas eram impossíveis de ter warning, então a média real é maior. Como você vai consertar isso? Era como dar seta e a porta abrir de tanto efeito colateral imprevisível que tinha.

Recentemente eu dei uma consultoria resolveram jogar fora todo o sistema feito em uma linguagem para fazer em outra, e praticamente só por isso. Foi a melhor decisão? Não sei não estou acompanhando, a decisão não foi minha, eu estava mostrando o caminho, mas deu ruído no processo. Eles tinham um sistema com vários problemas também, claro, e agora é possível que tenham um melhor, mas não sei. Pode ter ruídos e fazerem algo tão ruim ou pior que antes.

Não é só questão do quanto está ruim, mas da capacidade das pessoas de fazer a mudança.

Um erro muito comum é reescrever tudo querendo manter compatibilidade com o antigo. Isso é o pior dos dois mundos, você paga o preço de arrumar com o carro andando e de comprar um novo. Para fazer isso tem que se comprometer com um produto completamente novo. O custo de ficar fazendo adaptações é algo, e é imprevisível tanto quanto o de fazer tudo do zero.

Se você não fizer o seu concorrente, que talvez nem exista ainda fará. Um monte de empresa não quis fazer do zero e tinha outro fazendo, e agora sua posição de mercado está ameaçada. Se outro pode fazer, por que não eu?

Decidir qual é a hora de fazer isso, que pode ser nunca, é muito difícil. Mesmo pessoas muito experientes podem errar feio.

Até porque não se tem muita informação sobre isso. As pessoas não fazem os dois e medem qual foi mais barato. Ninguém sabe como foi no passado, e mesmo que souber não quer dizer que o seu caso será assim por uma quantidade enorme de razões.

É mais fácil mensurar o custo de fazer do zero e é sempre alto, muito alto. Mesmo se for feito do jeito certo, o que muitas vezes não é. Pode parecer que ir fazendo mudanças incrementais custa mais barato, mas é até difícil mensurar todos os custos, o prejuízo causado por estar com algo capenga, o que é manutenção normal e o que não é, o quanto é mais caro mexer em algo que não está bom, o custo de ter uma equipe sobrecarregada e até desmotivada com aquilo, além do custo de oportunidade já falado antes.

Em alguns casos pode ser até que sirva para arrumar a casa em processo e metodologias, por ser uma forma de ir reformando a equipe, porque muitas vezes a solução é começar o projeto novo com equipe nova, que tem lá seu problema também, mas só mostra como a decisão é difícil.

Nos lugares que mais dá certo ir fazendo incrementalmente são justamente os que precisam de menos mudanças ou menos traumáticas. A decisão deveria ser muito simples, o problema sempre está no que está caindo aos pedaços.

Conserta isto em vez de pegar um zero, e diga como ficou o resultado:

Fiat 147 todo detonado andando pelas ruas

Se for mais difícil será mais caro, então não pode ir por esse caminho, a questão é que nem sempre dá para saber qual é mais difícil e caro. O que é certo é que se souber o que está fazendo não tem como fazer incrementalmente ser ao mesmo tempo eficiente, econômico e sustentável do que refazer do zero. Errando tudo pode acontecer.

Para obter os mesmos resultados nas duas formas só tem um jeito do incremental ser feito, e é refazer do zero todo o sistema incrementalmente, que é muito mais difícil e caro. O que as pessoas fazem é aceitar resultados piores porque o custo de refazer não compensa. Ou só mexem onde precisa porque o resto está bom o suficiente, e se alguém cogitar refazer tudo do zero em um caso assim pode buscar a camisa de força.

Não entrei na questão de quantos usuários estão pendurados, ou outras questões políticas envolvidas, que torna a questão mais complexa ainda.

De fato muita gnete vai escolher refazer do zero por deslumbramento, sem saber onde está se metendo, por ingenuidade, aí é um problemão.

Eu sei qual fica melhor sempre, quando a qualidade da equipe não está em discussão. Se vale o custo é a resposta de ouro que estamos buscando.

O segredo é saber o quanto o sistema está dando problemas, não pode ser só um pouco, o quanto terá de ganho mudando tudo radicalmente e quanto tempo e custo disso, além de riscos. Quase todas as discussões que eu já vi nem era para pôr na mesa "refazer do zero".

Para finalizar, minha experiência mostra que qualquer situação assim deve ser evitada por inexperientes, porque as decisões serão tomadas com base no que ouviram falar e não no que viveram. Isso não dá certo. Já ficou longo para mostrar mais questões.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Eu votei na postagem original pelo conteúdo geral, o título (texto e tudo caixa alta) quase me fez não votar. E deu algo esquisito, nem sei se o voto que está aí é meu, estou abrindo issue.

1

pior erro estratégico que qualquer empresa de software pode cometer” ao decidir reescrever seu código do zero.

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

Joel fala do caso da Nescape que segundo ele se deu mal ao reescrever do zero.
E ele diz, que uma empresa nunca deve fazer isso!

Não sei se ele esta certo ou errado, mas os argumentos dele e seu conhecimento vasto devem ser levados em conta!

https://www.joelonsoftware.com/2000/11/20/netscape-goes-bonkers/

https://www.joelonsoftware.com/2002/01/23/rub-a-dub-dub/

Não é uma discordancia nem concordancia com argumentos, mas é sempre interessante ver relatos de gente da industria

1

É um contexto. Inclusive que tinha um monte de gente batendo cabeça. Enquanto isso, tinha um monte de gente fazendo concorrentes. Quando você pega detalhes, relatos de todos, até mesmo livro foi escrito sobre o assunto e vê que não tinha como dar certo. Podiam ter feito mudanças incrementais e o resultado seria bem parecido.

O Joel é(ra) muito influente e tornou o caso famoso, e muita gente o usa como "prova" de que é assim, mas é só um caso, que serve de aprendizado, não de prova. Afinal, eu já vi avião cair, nunca mais vou pegar um.

Inclusive há algumas pessoas que contestam bastante o que ele postou aí. Ele serve de exemplo, mas não é canônico. Ele não pode ser usado como "boa prática". Eu até comecei a montar minha palestra "A péssima prática de seguir boas práticas" em parte por causa desse artigo. Porque eu via que as pessoas não entendiam o que é uma anedota e o que é fato comprovado que funciona universalmente, e transforma em boas práticas o que funciona circunstancialmente apenas. Então as pessoas começam adotar sem que aquilo tenha eficácia comprovada em todos os contextos, ou sejam começam tomar água sanitária para tratar Covid. Água sanitária é sensacional, eu sempre tenho aqui em casa. Eu teria usado outra coisa se tivesse pego Covid. O médico já me mandou usá-la para outras coisas.

Não se pode glorificar ou demonizar nada, para cada contexto tem uma indicação. Em saúde eu prefiro ouvir médicos, em decisões complexas sobre software eu sei quem escutar, principalmente quem não escutar.

2

Eu entendi o intuito da afirmação, porém acredito que cada caso é um caso. Só pra contextualizar, eu ainda estou na faculdade de Ciências da Computação então não possuo experiência empírica de mercado. Apesar disso, pelo que conversei com meus professores (principalmente o meu professor de análise e projeto de sistemas) alguns projetos podem sim ser irremediáveis, e tentar consertar pode acabar dando mais trabalho e custo do que iniciar um novo e eu consigo ver isto acontecendo dado a complexidade que é botar um sistema pra funcionar e o tanto de variáveis que isso envolve. Algo que é muito enfatizado em minhas aulas é a importância de um projeto bem feito e detalhado. Os custos de se consertar um erro depois que um software já está em produção é infinitamente superior ao custo de consertar o erro na fase de projeto.

Talvez seja chover no molhado mas acredito que ao invés de tentar consertar um sistema bagunçado ou fazer tudo do zero, seja mais interessante investir na fase de análise e projeto, pois de nada adianta recomeçar um projeto se os mesmos erros podem acabar se repetindo porque não há uma boa base sobre a qual o desenvolvimento possa se debruçar.

Em resumo, ainda acredito que cada caso seja um caso mas acho que maduro mesmo seria projetar e evoluir o software de maneira mais inteligente para que se evitem casos perdidos no futuro.

1
1
1

eu não esperava esse tipo de conteúdo aqui no tabnews. me lembra o medium e dev comunity.

se você escreve um artigo menosprezando a experiência dos outros apenas para favorecer seu ponto de vista atual, você não amadureceu o suficiente.

posso até concordar parcialmente com o argumento, mas o título é típico dos artigos que eu costumo não ler.

1

O titulo foi realmente...
Mas vi o erro e acabei mudando. A minha ideia é simplesmente apresentar um ponto de vista e algo que escuto muitos entre os devs.

seria mais facil refazer todo projeto, em tal arquitetura, em tal tecnologia...

E eles simplemente acreditam que será uma tarefa fácil mesmo sem entender o código e como o software está funcionando.