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


36

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!


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

2
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.
Jerry Coffin

2
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.
Jerry Coffin

2
Como muitos projetos são privados, seria difícil para um estudo ter um conjunto de amostras realmente bom. Você pode estar limitado a evidências anedóticas.
mike30

11
O problema não está reescrevendo toda a base de código. O problema é querer reescrever a coisa toda de uma vez e depois pressionar um botão e pressionar todas as suas dores de cabeça desapareceram. Na maioria dos casos, você não pode gastar o tempo perdido para seus concorrentes, adicionando novos recursos, deixando os erros apodrecerem e os clientes deixando de cancelar. Por maior que seja um desastre completo de uma base de código, deve ser possível identificar pontos problemáticos e modularizar as peças certas do espaguete à medida que você avança.
precisa

Respostas:


6

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.


8
o código que precisa ser reescrito geralmente é escrito de uma maneira que não pode ser testada (acoplamento rígido, classes que fazem muito, etc.), o que coloca você na posição estranha de precisar refatorar antes de poder realizar o teste de unidade.
27412 Kevin

Sim, é por isso que o comentário sobre o livro: "Trabalhando efetivamente com o código legado" foi muito apropriado. Eu tive que fazer algo como isso no ano passado e adotar uma abordagem mais metódica, como o que é explicado nesse livro, me pouparia muito tempo e deixaria uma trilha de documentação / teste que seria útil. Eu sinto que apenas fazê-lo funcionar foi ótimo, mas não foi suficiente. Os objetos tinham tantas dependências que eu achava que meus testes poderiam ter uma cobertura melhor.

6

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.


3

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.


2
+1 pela necessidade de entender muito sobre o sistema comercial antecipadamente. No entanto, como você sabe, o desafio aqui é o tempo e os recursos (do negócio), bem como os fatores de mudança. Para sistemas de médio e grande porte, às vezes nem sempre é possível entender toda a complexidade inicial.
NoChance

2

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.


1

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.


11
A reescrita pode ser uma falha quando excede o orçamento em massa e é cancelada antes de ser concluída. Dinheiro pelo ralo. A possibilidade dessa eventualidade é a razão pela qual a reescrita é considerada mais arriscada do que a refatoração.
28412 MarkJ

@ MarkJ: Eu pensei que era coberto por "não funciona", mas vou editar para deixar isso mais claro.
jmoreno
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.