Você já se envolveu em uma reescrita grande? [fechadas]


55

Joel Spolsky disse em um de seus famosos posts:

O pior erro estratégico que qualquer empresa de software pode cometer: reescrever o código do zero.

Chad Fowler escreveu:

Você viu os vídeos, as postagens no blog e o hype, e decidiu reimplementar seu produto no Rails (ou Java, .NET, Erlang, etc.).

Cuidado. Esse é um caminho mais longo, mais difícil e mais propenso a falhas do que o esperado.

Você já esteve envolvido em uma reescrita grande?
Estou interessado em sua experiência sobre esse trágico tópico e, em particular, em qualquer grande reescrita que tenha sido concluída com êxito (se houver).


Qual é o seu limite para o BIG ?
rwong

Um projeto que é consolidado por muitos anos; ou seja, não é um projeto que pode ser reescrito em um mês.
systempuntoout

:) Isso pode ser qualquer coisa. O que alguém recém-saído da faculdade sem experiência pode fazer de vários meses a um ano é bem diferente do que alguém com uma década ou mais de experiência adquirida com muito esforço pode fazer.
Berin Loritsch 06/04

O Mozilla fez a transição com sucesso do addons.mozilla.org do CakePHP para o Django. Fala-se em descrever essa grande reescrita ( DjangoCon 2010 Alternando addons.mozilla.org do CakePHP para Django ), mas a versão TL: DR é que eles alternaram uma URL de cada vez.
precisa saber é o seguinte

O contraponto a Joel é o livro seminal de Fred Brook, "Mythical Man Month". Em seu ensaio sobre sistemas-piloto, ele afirma que você jogará fora um sistema , portanto é melhor planejar o evento. Com efeito, haverá pelo menos uma reescrita, provavelmente duas, já que o "maior perigo" aos olhos de Brook está no segundo sistema em que todos os desabrochados anteriores florescem e os recursos são agrupados.
EBarr

Respostas:


62

Eu estive envolvido em algumas reescritas ao longo da minha carreira e todos foram desastres. Eu acho que todos eles falham pelas mesmas razões

  • Grande subestimação do esforço necessário: toda vez que alguém quer reescrever, é porque o sistema antigo está usando tecnologia antiga e difícil de manter. O que eles não consideram é que, devido à sua idade, pode ter de 30 a 40 anos de esforço de desenvolvimento. Pensar que você pode reescrever tudo em 6 meses com uma equipe de 5 é bobagem.
  • Conhecimento perdido: o sistema antigo existe há tanto tempo que faz muitas coisas e está ligado a tudo. Não há documentação atualizada nem ponto único de autoridade que realmente saiba tudo o que o sistema faz. Haverá conhecimentos com usuários específicos em departamentos específicos, e encontrar todos eles é difícil ou impossível.
  • Decisões ruins de gerenciamento: as reescritas em que estive envolvido tinham expectativas semelhantes da administração: o novo sistema deveria ser 'pronto' e o sistema antigo poderia simplesmente ser desativado em uma determinada data, período. Nenhuma outra opção foi aceitável. Eu acho que eles entendem isso porque estão gastando todo esse dinheiro para contratar novas pessoas para esse grande projeto. Na realidade, a melhor estratégia de mitigação de riscos é reescrever as principais funções do sistema antigo, digamos, abordar 50-75% do sistema antigo para um primeiro lançamento e ver como ele funciona! Devido aos itens 1 e 2 acima, isso provavelmente funcionaria muito melhor, pois descobrimos alguns dos recursos que foram perdidos e o que é necessário para realmente desligar o sistema antigo.

22

As reescritas podem ser muito bem-sucedidas se você as definir corretamente. Não sei se estes atendem ao seu limite de projetos "BIG" (TM), mas deixe-me descrever algumas das reescritas mais bem-sucedidas.

Projeto 1

A empresa em que trabalhei tinha um sistema de impressão em tira de prateleira usado para gerar as etiquetas que você vê nas prateleiras do varejo a partir de algo chamado planograma . O planograma foi gerado em software padrão do setor e nossas ferramentas leram esse documento para criar as faixas de prateleira usando um modelo para a loja de destino. O software de modelagem estava uma bagunça com máquinas de estado finito aninhadas que abrangem várias classes e 3 DLLs. Quando chegou a hora de implementar a (então) abordagem pendente de patente para fazer peg boards, ficou claro que o código atual não suportava o que queríamos fazer.

Solução: definimos o escopo da reescrita apenas para o mecanismo de modelo. Usamos o design adequado do OO para atender aos requisitos atuais e para atender aos novos requisitos do quadro de pinos. O tempo para reescrever foi de 1 mês. Se reescrevíssemos toda a cadeia de ferramentas, levaria mais de um ano - mas não precisávamos fazer isso.

Projeto 2

Um aplicativo da web criado por nossa equipe desde o início estava começando a superar o design original. Nosso cliente também tinha um conjunto de novos requisitos que tornariam o site muito melhor para nossos usuários, mais compatível com "Web 2.0", se você preferir. Embora pudéssemos colocar nosso design existente em uma estrutura que tínhamos atualmente, a manutenção foi um pesadelo. Conhecíamos o aplicativo intimamente e sabíamos quais partes precisávamos apresentar e quais partes estavam desaparecendo como parte da nova versão.

Solução: nossa equipe levou três meses para concluir - não foi trivial. O produto final foi mais rápido, mais escalável e mais agradável para os usuários finais. Superamos as expectativas de nossos clientes. Dito isso, tivemos que dividir nossa equipe para que as correções mais imediatas e as correções de band-aid fossem feitas no sistema existente enquanto a outra metade trabalhava no novo sistema. Tínhamos testes extensivos implementados e incorporados no início do processo. A razão pela qual isso funcionou tão bem é porque conhecíamos intimamente esse aplicativo e nosso cliente.

Projeto 3

Eu tenho que incluir uma falha aqui. Estávamos apoiando um cliente que precisava de uma ferramenta de gerenciamento de informações para uso em situações de desastre / crise. Herdamos um aplicativo Java Swing que os desenvolvedores originais escreveram sem entender verdadeiramente o Swing. Com isso, quero dizer que eles não seguiram as recomendações da Sun para lidar com o Swing e gerenciar a interface do usuário corretamente, como resultado, você entraria em loops de eventos infinitos e outros problemas estranhos e difíceis de rastrear. Como resultado, estava carregado de bugs, problemas na interface do usuário etc. Essa era uma aplicação muito complicada. Para preservar nossa sanidade, tentamos reescrever o aplicativo Swing mal escrito em um aplicativo Swing bem escrito.

Solução: Concluímos a reescrita em cerca de 4,5 meses, quando estimamos 3 meses. O aplicativo teve um desempenho melhor, tanto na interface do usuário quanto na quantidade de dados que ele poderia manipular. Então o tsunami em 2004 aconteceu. A grande magnitude do número de pessoas que eles precisavam rastrear demonstrou que o Swing era a tecnologia errada para o que eles realmente precisavam. Não conseguimos acompanhar nosso ajuste de desempenho, e eles acabaram abandonando a ferramenta em favor de um aplicativo da Web criado pela equipe da Oracle que tinham em casa. Claro que poderíamos justificar o que fizemos com base no conhecimento que tínhamos na época, mas a reescrita não era agressiva o suficiente e falhamos em informar ao cliente que seus requisitos para o número de pessoas que possivelmente precisariam ser rastreadas também eram baixo.

Conclusão

Às vezes , as reconfigurações são necessárias e podem ser concluídas com êxito se você planejar corretamente. Você pode avançar ainda mais com as regravações direcionadas para partes de um sistema do que com as regravações de toda a venda. Finalmente, o que causa uma falha no projeto não é necessariamente a reescrita. Embora nunca possamos ser clarividentes, podemos apresentar alguns piores cenários. Aprendi a projetar meus sistemas para suportar o dobro do pior cenário possível. No caso do sistema de gerenciamento de crises, isso não foi suficiente - os números reais foram 20 vezes o pior cenário possível. Mas esse não foi o pior cenário possível.

  • Reescrever para reescrever não é seu amigo. Sempre há muita complexidade que você não vê, e você verá que as coisas feias que você vê são ferramentas de treinamento para seu cliente. Sempre mostre seu progresso atual ao seu cliente em intervalos regulares, para que eles possam ajudá-lo a detectar as piores ofensas.
  • As regravações direcionadas são úteis para lidar com as piores ofensas na sua base de código. Não faça uma reescrita inteira se puder limitar o escopo e resolver a maioria dos seus problemas.

12

Eu estive envolvido com várias reescritas que eram do VB6 para o .NET. Em 2 casos, as reescritas ocorreram sem problemas e, na verdade, terminamos antes do previsto. A outra reescrita demorou mais que o esperado, mas foi concluída sem grandes problemas.

Em nosso caso específico, reescrever NÃO foi a pior decisão que nossa empresa poderia tomar. Os resultados finais foram realmente muito mais estáveis ​​que os originais e nos colocaram em um lugar muito melhor.


Eu não chamaria isso de reescrita ... mais como uma atualização ... a menos que você convertesse o código em C # ou algo assim. Você realmente começou do zero com o novo código?
Jay

4
@ Jay - Eles foram todos reescritos, sem conversão. Aproveitamos a oportunidade para redesenhar todos os três aplicativos. Não vejo nenhum valor em uma conversão direta se você não abordar as deficiências do sistema existente. No nosso caso, isso estava começando do zero.
Walter

Quão grandes eles eram? Quantas linhas de código no sistema original, quantas pessoas-mês a reescrita levou?
MarkJ

11

Uma das maiores armadilhas ao reescrever completamente um sistema existente é pensar "Não precisamos especificar o que o novo sistema deve fazer - é muito simples, basta fazer exatamente o que o sistema antigo faz!" .

O problema é que provavelmente ninguém sabe exatamente o que o sistema antigo faz, e você passará inúmeras horas fazendo o seu novo sistema funcionar de acordo com a maneira que diferentes usuários do sistema antigo acham que deve funcionar. Os requisitos originais do sistema antigo também provavelmente não estão disponíveis.


11
Eu posso atestar isso. Não há problema em usar uma cópia de trabalho do sistema antigo como entrada para um documento de requisitos. Mas o cliente deve assinar esse documento, não uma noção vaga do sistema antigo.
Adrian Ratnapala

9

A minha é uma história de "sucesso". Meu projeto envolveu um site primário com 4 sites de satélite gerenciados / gravados de forma independente (subdomínios com aplicativos diferentes). Tínhamos quatro bases de usuários principais (todas em diretórios ativos separados) e nenhuma possuía um sistema de autenticação comum. 3 eram aplicativos bem estabelecidos e em silos, e o 4º satélite era novinho em folha e copiou grande parte de sua base de códigos do site mais estabelecido.

Objetivo: implementar um sistema de identidade para toda a empresa que possa autenticar contas em quatro domínios e gerenciar completamente (com autoatendimento) em um dos domínios. Como o .Net já foi implementado nos satélites, o site asp clássico que serviu como "entrada" precisaria ser reescrito, o gerenciamento de identidade adicionado e todos os sites precisariam de testes de regressão para garantir que nenhum serviço fosse impactado.

Recursos: 3 arquitetos principais - programador, gerenciamento de identidades, gerente de projetos. Aproximadamente 20 desenvolvedores, 10 analistas, 10 testadores.

Tempo para conclusão (início ao fim): 1,5 anos

Lançamento com Sucesso: Quase Falha

Sucesso na longevidade: fantástico

Como eu era o arquiteto de gerenciamento de identidades, projetei os bancos de dados, subsistemas e interfaces lógicas pelas quais todos os satélites interagiam. O arquiteto "programador" era um desenvolvedor líder com amplo conhecimento comercial de todos os satélites e experiência com os aplicativos e seu desenvolvimento até aquele momento.

Depois de vários meses reunindo requisitos com 50 pessoas diferentes de vários departamentos de nossa empresa, conseguimos resolver a arquitetura lógica e começamos a inserir código. Devido à natureza da mudança, tivemos que reescrever nosso próprio site e todas as funcionalidades que ele continha no .Net. Em alguns casos, era apenas uma questão de refatoração. Em muitos casos, envolveu uma reescrita completa dos processos que o cercavam. Em 2 casos, simplesmente abandonamos o recurso original por não ser importante. Perdemos dois prazos no processo (mas acabamos atingindo o prazo original que eu havia proposto - mal). No dia do lançamento, nada funcionou. Lançamos no sábado, então o impacto foi bastante mínimo, mas passei o dia inteiro vasculhando logs, reescrevendo peças e avaliando as cargas do servidor. Mais testes podem ter ajudado.

No final do primeiro dia, todos os sites estavam em funcionamento e tudo estava funcionando (eu diria que foi um sucesso nominal). Ao longo dos últimos 2,5 anos, tudo foi um grande sucesso. Ter todos os nossos sites em uma arquitetura comum, com uma base de estrutura comum, facilitou muito o trabalho de desenvolvimento e desenvolvimento entre desenvolvedores. Os recursos que escrevi em nosso site há 2,5 anos (durante a reescrita) foram vistos / adotados por alguns dos silos de satélite.

Aumentamos o registro, o rastreamento do usuário, o tempo de atividade, um aplicativo singular responsável pela autenticação / autorização / identificação. Os silos de satélite podem se concentrar inteiramente em seus aplicativos e confiar que existem problemas de autenticação / autorização com o aplicativo de gerenciamento de identidades.

Nosso projeto foi de muita frustração, mágoa e desastres. No final, valeu a pena e depois alguns. Estou 100% de acordo com a avaliação de Joel Spolsky das reescritas como regra geral, mas sempre há exceções. Se você está pensando em reescrever, basta garantir que seja absolutamente o que você precisa. Se for, esteja preparado para todas as dores que o acompanham.


5

Estou envolvido em uma enorme reescrita de código agora ... o único problema é que sou o único trabalhando nisso! Os custos de manutenção de nosso software atual são escandalosos, possuem muitos bugs e temos 1 funcionário da FT mantendo-o, então decidimos criar o nosso.

É muito mais lento do que eu esperava, mas, no final das contas, acho que será muito melhor, porque teremos nossa própria base de código, para que quaisquer alterações que eles desejem no futuro possam ser facilmente implementadas (o software precisa mudar frequentemente para acompanhar hora atual). Também estamos fazendo algumas mudanças importantes no design enquanto o reescrevemos.


Estou no mesmo barco do meu cliente atual - exceto que estou usando o chapéu "relógio completo". Manter o aplicativo Access existente enquanto conclui a reescrita da "nova" substituição do .NET que substitui os desenvolvedores anteriores. Não é fácil / constante e problemas imprevistos constantes levam muito mais tempo do que todo mundo espera.
BenAlabaster 22/09

3
quando terminar, atualize sua resposta com "Eu esperava que fosse assim, mas foi assim" para ajudar outras pessoas a fazer estimativas mais realistas.

11
@ Thor Claro, mas você pode estar esperando um pouco. Há muito mais no aplicativo do que eu esperava (segurança, conformidade etc.) e tentar criar algo BEM em vez de apenas criar algo está demorando mais do que eu pensava.
Rachel

Parece que você já tem horrorstories adicional de compartilhar :)

11
@ MarkJ Infelizmente, o projeto foi cancelado depois de um ano ou mais porque a empresa não queria gastar dinheiro e recursos para continuar construindo. Acho que eles pensaram que estávamos brincando quando dissemos que levaria cerca de 5 anos com um programador trabalhando em período parcial ... Fiquei muito decepcionado, mas aprendi muito e acho que isso me tornou um programador melhor em geral .
28412 Rachel

3

Participei de uma reescrita completa no meu trabalho anterior. E ficamos muito felizes por ter feito isso. Digamos que, às vezes, a base de código é tão podre que é melhor começar de novo.

Era um aplicativo interno - o principal aplicativo de negócios, de fato.

Mantivemos o sistema antigo quando escrevemos a versão 2. Se bem me lembro, levamos cerca de um ano (dois programadores e depois um terceiro). Porém, não precisamos tocar no banco de dados, pelo menos a migração de dados não foi um problema.


Gostaria de compartilhar por que a versão antiga era ruim demais para remediar? Você mudou de plataforma?

11
Alteramos os bancos de dados (SQL Anywhere 6 para MS SQL Server 7), mas o principal fator foi que o aplicativo foi gravado quase inteiramente usando a pior maneira de escrever Delphi: toda a lógica do modelo e do controlador nas visualizações, triplo de 500 linhas. loops aninhados, etc etc. Era uma bagunça, não podíamos ver como começar a desmotivar e estávamos alterando os bancos de dados de qualquer maneira.
precisa saber é o seguinte

3

Tudo depende. No meu caso, segui o conselho de Joel Spolsky e estava errado . Era sobre um site de seguros. O site foi horrível e aqui está o que eu fiz, então o que eu deveria ter feito:

estratégia: supervisionei um grupo de 4 alunos para:

  • Estudante # 1 - reescreveu o acesso / consultas ao banco de dados para torná-los seguros
  • Estudante # 2 - moveu todo o CSS "para cima"
  • Estudante # 3 - tornou todas as páginas compatíveis com o w3c
  • Estudante # 4 - resolveu todos os erros pendentes
  • Eu: removi todos os avisos php e coisas ruins (código duplicado e assim por diante)

Demorou 2 meses. Em seguida, redesenhamos o site. Então nós fizemos isso em vários idiomas. No geral, tivemos que manter grande parte do código de baixa qualidade e a estrutura do banco de dados permaneceu a mesma. Então, eu ainda estou trabalhando em coisas ruins por um ano e isso nunca será concluído até que decidamos uma reescrita completa, o que nunca acontecerá realmente.

Boa estratégia:

  • Estude todo o site, faça um bom "documento de requisitos do produto".
  • Redesenhe corretamente o banco de dados
  • Comece do zero com minha própria estrutura (que já funciona)
  • Redesenhado o site.
  • Faça vários idiomas.

Tempo que levaria: dois meses ( talvez menos ).

  • Bom código.
  • Boa manutenção.
  • Produtividade.
  • Nenhuma resposta como "não podemos fazer isso, o site não pode lidar com esses produtos".

Então, minhas últimas palavras: tudo depende da complexidade das coisas que você precisa reescrever .

Não hesite em corrigir meu post para torná-lo adequado, por favor, muito obrigado

Olivier Pons


Se o projeto levasse 2 meses, eu não consideraria uma reescrita "GRANDE". Especialmente com uma equipe de apenas 5 pessoas.
Joel Etherton

Você está certo em um sentido. Eu apenas pensei que "GRANDE" estava mais perto de reescrever "COMPLETO" do que "> 2-4 pessoas trabalhando nele". Você acha que meu post é inútil? Se assim for, eu vou removê-lo. Obrigado.
perfil completo de Olivier Pons

Não, eu não acho que seja inútil. Você levanta vários pontos decentes. Eu só queria fazer o meu comentário porque os problemas experimentados em pequena escala são muito diferentes dos problemas vistos em uma escala muito grande. Na minha resposta, considero a reescrita da escala média.
Joel Etherton

@ Joel: ok, eu li sua resposta, este não é o mesmo "problema". Mais uma vez, tudo depende do caso. A propósito, eu traduzi há alguns anos o artigo completo de Joel em francês (no meu blog pessoal);)
Olivier Pons

2
@OlivierPons não tenho certeza que comparar o que você realmente fez contra o que você acha que poderia ter feito é uma comparação justa ...
vaughandroid

2

Uma empresa em que trabalhei iniciou um grande refator da base de código.

Metade da equipe estava preparada para trabalhar no refator e a outra metade continuando a manter e melhorar o produto existente.

Como você pode imaginar, o refator nunca chegou a um ponto em que tudo funcionava - era apenas um processo contínuo e constante que realmente não tinha nada para mostrar por si mesmo.

A idéia era que a base de código refatorada seria melhor para trabalhar e poderíamos simplesmente "entrar" nos novos recursos que a equipe havia adicionado ao produto existente após a conclusão e "recuperar o atraso".

Mas acabou sendo a queda da empresa.


2

Estive em uma grande reescrita nos últimos 3 anos. Original, estimamos que o projeto demore 2 anos. A idéia básica era substituir o hardware, usar um sistema operacional existente, reescrever a lógica de negócios (de c para CPP), criar um novo cartão IO e escrever uma nova interface do usuário.

Ao longo do caminho, tomamos algumas decisões terríveis. Não tínhamos experiência real em CPP e nenhum mentor para ensiná-lo bem. Tentamos construir uma estrutura de interface do usuário com base no win32. O hardware era barato e o BSP apresentava bugs. O software era super flexível, mas difícil de manter. No ano passado, lançamos a interface do usuário cultivada em casa e desenvolvemos uma interface no .net. Também reescrevemos completamente nosso mecanismo de persistência e protocolo de comunicação de dados.

Foi preciso muito esforço extra, mas agora o projeto está quase concluído e as primeiras unidades são testadas em campo. O projeto tinha muito risco de sofrer qualquer alteração no sucesso. Havia algumas coisas positivas sobre o projeto, começamos a usar o SVN (em vez do VSS), levamos um tempo para escrever testes de unidade e implementamos uma compilação noturna. Também começamos a usar o scrum para ter um processo melhor.

Em retrospecto, acho que a reescrita da lógica de negócios não era necessária; só deveríamos ter re-fatorado as partes mais feias. E para escrever uma interface do usuário do zero, não faça isso, a menos que seja o seu negócio principal.


1

Na verdade, estou iniciando uma grande refatoração. Provavelmente, os 4MLocs devem reduzir para 800KLocs ou menos. Este projeto possui muitos recursos de copiar e colar, interpretar mal os idiomas, muitos e muitos comentários inúteis repetitivos, decisões erradas, hackers temporários e mais hackers permanentes (incluindo soluções alternativas), total falta de conhecimento sobre os princípios básicos de Ciência da Computação ou Engenharia de Software. Provavelmente, a equipe de manutenção de 32 programadores ruins será substituída por 2 bons após a refatoração.


Estou curioso para ouvir um acompanhamento do que aconteceu nisso. Conseguiu? O que você aprendeu ao longo do caminho? Ou onde estão as coisas agora, se estão inacabadas?
Kimball Robinson

1

Eu escrevi um mecanismo de blog em 3 semanas. Eu o reescrevi em 8 horas.

Planejar com antecedência é a chave para uma reescrita bem-sucedida. Conhecer o sistema por dentro e por fora também é um benefício.


4
Você consideraria um projeto de 3 semanas um projeto grande?
precisa

@ John: Não, eu não diria que é grande , no entanto, estou apontando a diferença de tempo entre escrever algo e adicionar peças rapidamente, em vez de reescrever com um plano sólido. Reescrevi um sistema de gerenciamento inteiro em três semanas que originalmente levaram cerca de 8 meses para serem montados. Novamente, é necessário um plano e direção sólidos.
Josh K

Ter uma versão existente (com ou sem código fonte, mas com a qual você pode mexer livremente) definitivamente ajuda no esforço de reescrever. Mais é melhor.
rwong

Para ser mais preciso, você implementou um mecanismo de blog de protótipo em 3 semanas.

@ Thorb: Claro, acho que isso pode ser dito.
21711 Josh K

1

Há pouco mais de uma década, trabalhei para uma empresa que decidiu fazer um "redesenho" de seu produto principal envelhecido. Desde então, mencionar a palavra "redesenho" é uma ofensa punível. Demorou muito mais que o esperado, obviamente custou mais, e o novo produto era muito mais parecido com o antigo do que o planejado inicialmente.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.