Reescrever ou reparar?

Question

Tenho certeza de que todos vocês já passaram por isso, vocês assumem um projeto onde há uma base de código antiga e frágil que mal serve para o propósito e você tem que tomar a decisão de reescrevê-lo do zero ou reparar o que já existe.

A sabedoria convencional tende a sugerir que você nunca deve tentar reescrever do zero, pois o risco de fracasso é muito alto.Então, o que você fez quando se deparou com esse problema, como tomou a decisão e como tudo aconteceu?

Answer 1

Realmente depende de quão ruim é.

Se for um sistema pequeno e você o compreender totalmente, reescrever não é uma loucura.

Por outro lado, se for um monstro legado gigante com dez milhões de linhas de código misterioso não documentado, então você realmente terá dificuldades para reescrever completamente.

Pontos a considerar:

• Se parecer bom para o usuário, eles não se importam com que tipo de bagunça de espaguete é para você.Por outro lado, se é ruim para eles também, é mais fácil conseguir concordância (e paciência).
• Se você reescrever, tente fazê -lo uma parte de cada vez.Uma base de código bagunçada e desorganizada pode dificultar isso (ou seja, substituir apenas uma parte, é necessário uma reescrita de grandes icebergs de código de dependência), mas, se possível, isso facilita muito a reescrita gradualmente e obter feedback dos usuários ao longo do caminho .

Eu realmente hesitaria em assumir um projeto gigante de reescrita para um sistema grande sem poder lançar a nova edição uma parte de cada vez.

Answer 2

Basta limpar um pouco o código toda vez que trabalhar com ele.Se ainda não houver, configure uma estrutura de teste de unidade.Todo novo código deve ter testes escritos.Qualquer código antigo que você corrigir como resultado de bugs, tente inserir testes também.

À medida que a limpeza avança, você poderá varrer cada vez mais códigos desagradáveis ​​para caixas encapsuladas.Então você pode eliminá-los um por um no futuro.

Uma ferramenta como javadoc ou doxygen, se ainda não estiver em uso, também pode ajudar a melhorar a documentação e a compreensibilidade do código.

Os argumentos contra uma reescrita completa são bastante fortes.Aquelas toneladas de “pequenos bugs” e comportamentos que foram codificados ao longo do período do projeto original voltarão novamente.

Answer 3

Veja o ensaio de Joel Spolsky Coisas que você nunca deve fazer.Em resumo, ao reescrever você perde todas as lições que aprendeu para fazer seu código atual funcionar da maneira que precisa.

Veja também: Grande bola de lama

Answer 4

É raro que uma reescrita de algo complexo tenha sucesso.É tentador, mas é uma estratégia de baixa porcentagem.

Obtenha o código legado em testes de unidade e refatore-o e/ou substitua completamente pequenas porções dele de forma incremental quando for oportuno.

Answer 5

Refatore, a menos que seja realmente muito ruim.

Joel tem muito a dizer sobre isso...

No mínimo, reescreva o código com o código antigo à sua frente e não comece do zero.O código antigo pode ser terrível, mas é assim por uma razão e se você ignorá-lo acabará vendo os mesmos bugs que provavelmente foram corrigidos anos atrás no código antigo.

Answer 6

Um dos motivos para reescrever em um de meus empregos anteriores foi a incapacidade de encontrar desenvolvedores com experiência suficiente para trabalhar na base de código original.

A decisão foi tomada para primeiro limpar a estrutura do banco de dados subjacente e, em seguida, reescrever algo que tornasse mais fácil encontrar funcionários e/ou contratados em tempo integral.

Ainda não ouvi como funcionou :)

Acho que as pessoas tendem a reescrever porque parece mais divertido superficialmente.

Podemos reconstruir do zero!

Nós faremos isso direito desta vez!

etc.

Answer 7

Há um novo livro saindo, Desenvolvimento de aplicativos brownfield em .NET por Baley e Belcham.O primeiro capítulo é gratuito e fala sobre essas questões de uma perspectiva predominantemente independente de plataforma.

Answer 8

Repare ou, mais importante, refatore.Ambos porque Joel disse isso e também porque, se for o seu código, você provavelmente aprendeu muito mais coisas desde a última vez que tocou nesse código.Se você o escreveu no .NET 1.1, poderá atualizá-lo para o 3.5 SP1.Você pode entrar e limpar todo o código antigo comentado.Você é 100 vezes melhor como desenvolvedor agora do que quando escreveu este código pela primeira vez.

Acho que a única exceção é quando o código usa tecnologias realmente antiquadas - nesse caso, seria melhor escrever uma nova versão.Se você estiver olhando para algum aplicativo VB6 com 10.000 linhas de código com um backend de banco de dados Access obviamente configurado por alguém que não sabia muito sobre como os bancos de dados funcionam (que poderia muito bem ser você há oito anos), então você provavelmente pode puxar uma solução mais rápida baseada em C#/SQL em uma fração do tempo e do código.

Answer 9

Não é tão preto e branco...realmente depende de muitos fatores (o mais importante é "o que a pessoa que paga quer que você faça")

Onde trabalho reescrevemos um framework de desenvolvimento e, por outro lado, continuamos modificando alguns sistemas antigos que não podem ser migrados (devido à tecnologia do cliente e às restrições de tempo).Neste caso, tentamos manter o estilo de codificação e às vezes é necessário implementar muitas soluções alternativas devido à forma como foi construído

Answer 10

Dependendo da sua situação, você poder tem outra opção:código de terceiros na licença.

Consultei algumas empresas onde essa seria a escolha sensata, embora aparentemente "jogar fora IP" possa ser uma grande barreira para o gerenciamento.Na minha empresa atual, consideramos seriamente a opção viável de usar código de terceiros para substituir nossa estrutura principal, mas essa ideia acabou sendo rejeitada mais por motivos comerciais do que técnicos.

Para responder diretamente à sua pergunta, finalmente optamos por reescrever a estrutura legada – uma decisão que não tomamos levianamente!14 meses depois, não nos arrependemos de forma alguma desta escolha.Considerando apenas o tempo gasto na correção de bugs, nossa nova estrutura quase se pagou.Do lado negativo, ainda não está completo em termos de recursos, então estamos na posição nada invejável de manter duas estruturas separadas em paralelo até que possamos portar o último de nossos aplicativos "front-end".

Answer 11

Eu recomendo fortemente a leitura de "Working Effectively with Legacy Code", de Michael Feathers.É um conselho de treinamento sobre como refatorar seu código para que ele seja testável em unidade.