Como atualizar uma grande base de código herdada para atender a padrões de qualidade específicos?


10

Há muitas informações sobre ferramentas e técnicas para melhorar as bases de código herdadas, mas não encontrei nenhum estudo de caso de sucesso no mundo real. A maioria dos conselhos é no nível micro e, embora seja útil, não convence muitas pessoas, devido à falta de evidências que podem ajudar no nível macro.

Estou procurando especificamente por melhorias incrementais que provaram ser um sucesso no mundo real ao atualizar uma grande base de código herdada para atender aos padrões de qualidade atuais, e não uma reescrita completa.

Antes:

  • Grande: maior que 1MLOC
  • Legado: sem testes automatizados
  • Má qualidade: alta complexidade, alto acoplamento, altos defeitos de escape

Depois de

  • Testes automatizados
  • Atualizações / manutenção mais fáceis
  • Alta qualidade: complexidade reduzida, código dissociado, poucos defeitos escapados

Que tipo de etapas incrementais foram comprovadas no mundo real para atualizar uma grande base de código herdada com sucesso para atender aos padrões de qualidade acima, sem passar por uma reescrita total?

Se possível, inclua um exemplo de empresa ou estudo de caso de um grande projeto legado que passou por um processo de melhoria de qualidade "bem-sucedido" na sua resposta para fazer o backup.




7
Todo o setor financeiro? Muito disso é executado no código FORTRAN de 40 anos. Ao contrário do Netscape, eles não podem descartá-lo e reescrevê-lo do zero, por isso vem melhorando gradualmente esse tempo todo.
precisa saber é o seguinte

2
no meu POV, a Netscape dificilmente pode ser usada como um exemplo de sucesso - o projeto encerrou a empresa ..... que na época era uma organização comercial com fins lucrativos. Não consigo imaginar os acionistas abrindo a prateleira superior com espumante naquele dia ...... de fato, existe um white paper bem conhecido ao longo das linhas "O que não fazer" usando o Netscape como o estudo de caso perfeito ...
mattnz

2
Oi @mikelong Editei sua pergunta para tentar reabri-la. Sua pergunta original solicitando uma lista de exemplos, que é considerada "não construtiva" pelos padrões do StackExchange. Sinta-se à vontade para editá- lo ainda mais, para adicionar mais detalhes sobre o que você entende por "alta qualidade" ou para atualizar o texto se eu cometer um erro. :)
Rachel

Respostas:


8

Livros como http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 devem testemunhar o suficiente para o quão grandes e legadas bases de código de baixa qualidade são comuns no setor.

Meu palpite sobre por que você não ouviu ou viu, e, o mais importante, você provavelmente nunca ouvirá falar deles até trabalhar em um deles, é, ninguém parece capaz por várias razões, para sair limpo e dizer que o código deles A base era tudo o que precede, sem enfrentar repercussões não triviais.

Isso poderia explicar a escassez de estudos de que você fala. Se você ler livros suficientes, por exemplo, os Deep C Secrets de Peter van der Linden, lerá cerca de um milhão de bugs de dólares, onde estará faltando a parte sobre o projeto que os possui.

NOTA: Eu queria fazer um comentário, mas era muito longo. Entendo que isso não responde totalmente à pergunta.

EDIT: C ++ 11 & A viabilidade a longo prazo do GCC é questionada - se os desenvolvedores refatorarem o GCC e o tornarem mais funcional como LLVM / clang, ele poderá fornecer um bom exemplo. A discussão observa que a documentação é ruim em alguns lugares, empurrando a barreira de entrada para novos desenvolvedores.


4

Em 3 de fevereiro de 2013, Michael Meeks, um dos desenvolvedores do LibreOffice, fará uma palestra em alguns dias com o título "LibreOffice: limpando e refatorando uma base de código gigante, ou por que reescrevê-la seria ainda pior . " Parece exatamente o que você está pedindo: uma discussão sobre o que eles fizeram para tomar "uma base de código gigantesca e mal compreendida comentada extensivamente em alemão, sem testes de unidade, uma infraestrutura de construção emaranhada e vinte e cinco" anos de dívida técnica não paga "e modernizá-la.

A apresentação pode ser transmitida on-line e (eu acho) as gravações estarão disponíveis em alguma data futura.


11
Sei que está programado para daqui a alguns dias. No entanto, uma vez transmitido, você poderá adicionar um resumo do processo que eles levaram para modernizar sua base de códigos à sua resposta, caso esses links desapareçam?
Rachel

@ Rachel - Se eu conseguir assistir a transmissão, definitivamente farei isso. Obrigado.
Josh Kelley

4

Na verdade, passei por uma refatoração bastante significativa três vezes na minha carreira. O código tende a deteriorar-se, portanto, se sua base de códigos tiver tempo suficiente, um grande refator é praticamente inevitável. Todos os meus exemplos foram baseados em códigos privados, o que pode explicar por que exemplos públicos são difíceis de encontrar.

A primeira vez foi um aplicativo que, acredite ou não, tinha uma arquitetura fundamental que o fazia funcionar apenas com impressoras matriciais. Quando minha empresa não conseguiu mais encontrar um fornecedor para fornecer as fitas, eles me designaram para fazê-lo funcionar com uma impressora a laser.

A segunda vez foi uma migração de várias centenas de scripts de teste automatizados de C para Java, em parte porque precisávamos de melhor capacidade entre plataformas e em parte porque estava ficando difícil contratar novos desenvolvedores em C.

Na terceira vez, ainda estou no meio, que está modularizando uma enorme aplicação monolítica para permitir testes de unidade, reduzindo o acoplamento, e para fins de plataforma cruzada.

Eu comparo o esforço de escalar uma montanha. Você tem esse grande objetivo pela frente, mas não o atinge no nível macro. Você o segura um punho de cada vez, sempre com uma posição de segurança próxima, nunca desconectando a segurança anterior até que a próxima esteja em vigor. Você começa apenas fazendo pequenas melhorias incrementais, e depois de um tempo você se vira e de repente há essa bela vista.

Digamos que você tenha 60.000 arquivos de código altamente acoplado, por exemplo. Você quer começar a colocá-lo em teste de unidade, mas as dependências tornam isso impossível. Como você corrige isso? Você desacopla um arquivo. Você adiciona testes automatizados. Você volta ao solo estável antes de seguir em frente. Repita 59.999 vezes.

Se isso parece simples, é porque é simples. Não é fácil, mas é simples. É difícil perceber qualquer progresso no início. Faltamos dois anos para o que parecia um refatorado impossível e provavelmente ainda temos anos pela frente até terminarmos, mas, olhando para trás, de repente percebemos o quão melhor o código já ficou, e conseguimos continuar oferecendo novas funcionalidades para nossos clientes nesse meio tempo.

As outras duas vezes funcionaram da mesma maneira. Você encontra a menor etapa segura que pode executar, e sempre a mantém em um estado de funcionamento. Você só se preocupa com o cenário geral para ter certeza de que está indo na direção certa. Todas as suas ações são pequenas, constantes e incrementais.


1

Por experiência pessoal trabalhando em uma base de códigos de vários milhões de linhas, encontrei algumas estratégias que parecem funcionar.

Veja todos os erros (mesmo os fechados) e tente dividi-los em categorias. Especificamente, para tentar decompô-los pelo componente ao qual eles pertencem. Se eles pertencem a mais de um componente, observe que eles pertencem. Depois de fazer isso, observe qual balde é o maior e use-o para determinar por onde começar. Além disso, você pode examinar o histórico de revisões dos arquivos para determinar o que mais muda e usá-lo como um guia de onde começar. Basicamente, o que você está tentando fazer é encontrar o que está mais quebrado, consertar isso e repetir. Além disso, descobri que tentar consertar tudo ao mesmo tempo nunca funciona, apenas causa mais problemas.

Se você achar que existem muitas coisas que pertencem a vários componentes, isso indica problemas no "sistema" e pode apontar para um código que está muito acoplado ou uma API que precisa ser atualizada.

Outra área em que passei muito tempo está testando a base de código existente. Existem várias estratégias aqui e todas têm mérito, mas ninguém é uma solução completa para o problema.

  • O teste de unidade pode funcionar, mas muitas vezes você se limita ao que pode ser testado devido a um código fortemente acoplado. No entanto, faça-o onde puder.
  • Testes externos são outra avenida. Suponho que você provavelmente já tenha isso e, se não, eu gastaria algum tempo criando-o. Além disso, algo que funcionou para mim é adicionar a capacidade de injetar aleatoriamente falhas / eventos no sistema. Além disso, tente injetar várias coisas ao mesmo tempo para tentar fazer com que ela falhe de novas maneiras.
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.