Existem estudos de caso reais sobre reescritas de taxas de sucesso / falha de software?

Vi várias postagens sobre a reescrita de aplicativos serem ruins, as experiências das pessoas sobre isso aqui nos programadores e um artigo que Joel Spolsky preparou sobre o assunto, mas nenhuma evidência concreta ou estudos de caso. Além dos dois exemplos que Joel deu e de alguns outros posts aqui, o que você faz com uma base de código incorreta e como decide o que fazer com base em estudos reais?

Para o caso em questão, há dois clientes que conheço que ambos possuem código legado antigo. Eles continuam mancando, porque, como um deles descobriu, a reescrita foi um desastre, era caro e não funcionou muito para melhorar muito o código. Esse cliente tem uma lógica de negócios muito complicada, como os reescritores descobriram rapidamente.

Nos dois casos, esses são aplicativos de missão crítica que geram muita receita para a empresa. Aquele que tentou a reescrita sentiu que eles atingiriam uma parede de tijolos se o software legado não fosse atualizado em algum momento no futuro. Para mim, esse tipo de risco merece pesquisa e análise para garantir um caminho bem-sucedido.

Houve estudos de caso reais que investigaram isso? Eu não gostaria de tentar uma grande reescrita sem conhecer as melhores práticas, armadilhas e sucessos com base em estudos reais.

Consequências: ok, depois de mais pesquisas, encontrei três artigos interessantes sobre estudos de caso:

1. Reescreva ou Reutilize . Eles fizeram um estudo em um aplicativo Cobol que foi convertido em Java.
2. O outro foi sobre reutilização de software: experiências e percepções de desenvolvedores .
3. Reutilizar ou reescrever Outro estudo sobre custos de manutenção versus reescrita.

Recentemente, encontrei outro artigo sobre o assunto: The Great Rewrite . Lá, o autor parece abordar alguns dos principais problemas. Junto com isso, havia a idéia de criar protótipos usando a nova pilha de tecnologia proposta e medindo a rapidez com que os desenvolvedores a capturavam. Isso tudo foi um prelúdio para uma reescrita, o que eu achei uma ótima idéia!

Não posso me responsabilizar por esses ótimos comentários, mas eles nunca foram respondidos pelo autor original, por isso estou marcando o wiki da comunidade.

Não conheço estudos de caso, mas acho que a resposta padrão para uma abordagem é provavelmente "adicionar testes de unidade e refatorar".

Parece-me possivelmente a abordagem de menor risco disponível. É claro que não conheço detalhes suficientes para ter certeza de que é a abordagem correta, mas, com base no que sei até agora, não conheço muita coisa que provavelmente seja muito melhor.

Se eles fizerem testes de unidade (apropriadamente - capturando verdadeiramente todos os requisitos), é difícil encontrar uma maneira de refatorar resultar em um verdadeiro desastre. O pior que pode acontecer é que você não faça tanto progresso tão rápido quanto gostaria. Ao mesmo tempo, se a base de código estiver tão ruim quanto a pergunta indica, é muito provável que seja necessário um esforço sério para permitir o progresso, independentemente da rota adotada.

Eu suporia que os projetos de reescrita não são significativamente diferentes nas taxas de falhas dos projetos em geral e se refeririam ao último relatório do CHAOS para obter melhores informações.

Passei um tempinho em Trabalhando efetivamente com o Legacy Code, de Michael Feathers , e descobri que ele oferecia algumas boas idéias sobre a prática do mundo real de manter o código legado, incluindo testes de escrita (mesmo quando você não sabe para que serve o código) e de refatoração / reescrita do curso. É um pouco datado, mas altamente classificado na Amazon.

Falando por experiência e vivendo em uma empresa que mal concebeu a arquitetura corporativa desde o início, posso dizer honestamente que o maior problema é desenvolver um entendimento abrangente.

Essa ideia de que um sistema pode ser dividido em pedaços e entendido individualmente é falha. Em algum momento, um único indivíduo ou vários indivíduos tiveram que ser capazes de conceber todo o problema em sua totalidade. Se esse problema é uma série de problemas de negócios e as tecnologias que os causam; pode levar uma pessoa na empresa vários anos para entender todos os sistemas a um nível em que é possível substituí-los sem um desastre ou um requisito perdido. Esse certamente foi o caso da minha empresa quando assumi o cargo de diretor de tecnologia. Se não fosse o fato de eu ser um codificador, não seria capaz de entender lentamente todos os detalhes da arquitetura e integração de tecnologia mal organizada, fortemente acoplada e fortemente ligada. Se pequenos detalhes ocultos e não documentados, como"We put the eBay order number in the "SYSOENT.PO_NUMBER" field in the ERP system because that's what Wendell the VB coder from Florida decided to do" são negligenciados, os resultados podem ser desastrosos, e a única maneira de saber isso é descobrir tudo lentamente.

Se alguém for solicitado a substituir o motor em uma aeronave durante o vôo ou enfrentar uma morte certa - dada a quantidade adequada de ferramentas e recursos que o indivíduo precisaria saber como substituir os sensores, o sistema hidráulico, como redirecionar o fluxo de combustível , manipule sistemas que nunca foram projetados para serem alterados ou manipulados externamente ou a partir do cockpit. Geralmente, é assim que é a perspectiva de reescrever um aplicativo de negócios. O aplicativo geralmente é incluído nos negócios entre muitas outras tecnologias diferentes.

Acho que meu ponto principal é que o sistema deve ser entendido em quase toda a sua complexidade e, em algum momento, deve ser entendido em sua integridade para que o novo sistema seja adequadamente "projetado" e não apenas "feito".

Os cookies são feitos, o software (deve ser) projetado.

Existem muitos exemplos de empresas que morreram de reescrita, como a Netscape . Também existem empresas que sobreviveram a uma reescrita sem grandes problemas, como o twitter .

Não há estudos de caso quantificados, porque não é viável ter um experimento de controle em que você analisa o sucesso comercial de não reescrever versus o sucesso comercial de reescrever. Cada aplicação é diferente.

Existem alguns casos óbvios em que uma reescrita faz sentido e muitos casos em que não. Eu preparei uma pequena receita para descobrir se uma reescrita faria sentido no seu caso.

Eu acho que reescrever faz mais sentido hoje em dia porque estamos codificando rapidamente sobre os ombros de estruturas invasivas cada vez melhores, como Rails, Grails, AngularJS. Se você deseja mover de js simples para Angular, uma reescrita é tudo o que você pode fazer. Ainda pode fazer muito sentido. Se você estiver substituindo uma implementação diy por outra (como todos os exemplos no artigo de Joel Spolsky ), provavelmente está louco.

Você não encontrará muitos estudos de caso não tendenciosos que não sejam relatórios de ação - a maioria das pessoas não pagará para realizar o mesmo trabalho pelo menos duas vezes (uma vez como reescrita, uma vez como atualização, melhor caso seria várias reescritas / atualizações por equipes diferentes).

O estudo de caso que você encontrou parece ter sido produzido pela Fujitsu e, sem surpresa, o resultado foi que era melhor usar as ferramentas da Fujitsu.

Do ponto de vista organizacional, uma reescrita é claramente uma falha quando o aplicativo reescrito não funciona ou o projeto é cancelado antes de terminar - caso contrário, é impossível saber se o atraso na liberação da versão reescrita foi o causa de qualquer perda que você sofreu ou meramente coincidência. Se cancelado antes de terminar, geralmente é considerado um total desperdício de tempo e recursos. Uma atualização pode potencialmente ter o mesmo problema, mas é improvável que seja incremental na mesma escala (você obtém algo pelo seu dinheiro).

O melhor caso da perspectiva da programação é fazer as duas coisas - atualizações incrementais durante a reescrita, apoiando e inspirando umas às outras. A menos que você tenha equipes diferentes, isso naturalmente levará mais tempo.

Observe que isso fornece uma orientação aproximada para quando você deve considerar uma reescrita total - o projeto é pequeno o suficiente para que você possa fazê-lo facilmente ou a organização é grande o suficiente para suportar as duas coisas, contando o esforço ou o custo de aprendizado que vale a pena. Observe também que, se a reescrita nunca alcançar a reformulação, isso pode significar várias coisas, mas tudo o mais é igual, provavelmente significa que uma reescrita foi desnecessária.