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

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

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.

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.

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.

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.

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.

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.

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.

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:

Má 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

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.

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.

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.

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.

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.