Existe um módulo no nosso equipamento de telecomunicações que está escrito em C. Acho que o código neste módulo tem um mau cheiro porque tem vários sintomas:
Quando novos recursos são adicionados a este módulo, alguns recursos originais dão errado. E alguns problemas estranhos foram finalmente orientados para o buffer overflow deste módulo.
É difícil adicionar um novo código ao módulo. Embora os testes de unidade e os testes de integração cubram o novo código, erros e falhas ocultas no código original vêm à tona.
Por meio da revisão de código, descobrimos que a qualidade do código é extremamente ruim. Mas o módulo foi testado por muitas rodadas, os erros ocultos na superfície do código foram encontrados pelos engenheiros de QA. Outros problemas ocultos mais profundos foram difíceis de encontrar. , bem como um vírus no corpo. (fácil de trazer mal-entendido, excluí-lo)
Resumimos o status quo nas seguintes razões:
O código original foi corrompido devido ao monitoramento do processo, na verdade, muitos autotestes são ignorados ou executados parcialmente.
O primeiro programador deste módulo foi a falta de capacidade de programação e o líder da equipe não encontrou o problema e corre o risco a tempo.
Muitas abordagens de melhoria permanecem na fase de planejamento devido à suspeita do líder da equipe.
O projeto chegou a uma nova versão. Alguns líderes de equipe querem mudar essa situação e discutimos o procedimento várias vezes. Todos concordaram em revisar o módulo, mas temos que decidir entre:
Concordo com a reescrita porque já temos algumas experiências de reescrita em nossos sistemas, que foram comprovadas como sendo as melhores escolhas. O gerente de projeto deseja refatorar o módulo devido ao tempo limitado disponível para concluir o projeto detalhado, a codificação, a revisão de código, os testes de unidade e o teste de integração, que são de três meses. Ele acha que as escalas de tempo estão muito apertadas para fazer uma reescrita completa.
Esse código deve ser reescrito ou refatorado?
EDITAR:
Como Joel disse em Coisas que você nunca deve fazer, parte I
The idea that new code is better than old is patently absurd.
Concordo com este ponto de vista. Mas eu tenho alguns enigmas que alguns casos de reescrita em nosso projeto provaram ser uma escolha sábia. Talvez conte com o novo programador que é mais notável do que o programador anterior ou o teste é mais suficiente.
Isso é fácil.
Reescreva-o.
Apenas diga que você está refatorando. Todo mundo está feliz.
Como nenhuma das duas palavras tem uma definição formal, legal e testável, elas podem argumentar a semântica sutil de cada palavra enquanto você reescreve / refaz até que funcione.
Não parece que o módulo tenha sido ruim, mas a adição de "novos recursos" o quebrou. Nesse ponto, pode ser difícil dizer se a qualidade do código era baixa originalmente ou se veio com os recursos.
Ou o módulo é insustentável (uma possibilidade distinta) ou as pessoas encarregadas de atualizá-lo não têm as habilidades certas (sons como este) ou ambos.
Com base em seu uso indevido do termo "falha de página" (falhas de página são normais, isso soa mais como uma violação de acesso), sua idéia de que um estouro de buffer é uma propriedade de um módulo grande de código em vez de um bug uma linha de código específica (e pode haver muitos bugs de estouro de buffer em um módulo), e o fato de que você parece estar usando a palavra "vírus" para se referir a esse estouro de buffer, temo que você seja tanto problema como o código é.
No mínimo, acho que você deve ficar de fora do debate "como melhor resolver" e permitir que programadores mais experientes trabalhem com a abordagem correta, e então ajudá-los a realizá-la.
E, em seguida, gastar algum tempo lendo (blogs seria bom) sobre como escrever código robusto, como evitar sobrecargas de buffer, envolvente de números inteiros, etc. para que você seja mais capaz de lidar com esses problemas no futuro.
The project manager wishes to refactor the module on account of the limited time available required to complete the detailed design, coding, code review, unit tests and integration testing which is three months. He thinks the time scales are too tight to do a full rewrite.
Eu acho que seu gerente de projeto tem um entendimento ruim do que refatorar significa. O que ele está falando é muito melhor corrigir o código. A refatoração não implica de forma alguma ignorar qualquer uma das etapas listadas (codificação, revisão, teste) e, portanto, não há garantia de que será mais rápida a reescrita completa, especialmente se o ponto de partida for um código mal escrito.
Concordo com alguns dos outros respondentes sobre o fato de que refatoração versus reescrita está argumentando sobre sutis diferenças semânticas. O problema é que seu gerente de projeto provavelmente não está pensando em nenhum dos dois.
Refatorar um módulo é reescrevê-lo, sem alterar sua interface. Então, se você perguntar o que seria melhor para você, eu suponho que você pergunte se faz sentido mudar a interface ou não.
Mudar a interface pode ser doloroso e integração. De qualquer forma, se o seu módulo é usado apenas em pouquíssimos lugares, pode ser viável reescrever, porque agora você sabe muito melhor do que antes o que o módulo deve fazer e como ele é realmente usado. Esse conhecimento deve ajudá-lo a projetar uma arquitetura de API e API próximas do ideal, possivelmente eliminando grandes quantidades de complexidades.
Caso contrário, uma refatoração é sua melhor opção. No seu caso, o módulo já deve expor alguma API, para que você possa começar a reescrever os corpos dessas funções, enquanto ainda respeita o que eles atualmente recebem e retornam, e como eles falham. Nesta refatoração, você deve confiar em funções ainda a serem escritas , de uma forma top-down, para quaisquer resultados necessários.
IMHO: reescreva como último recurso.
Defendi e obtive um projeto para reescrever nosso principal produto. Empreendimento enorme. Eu fiz isso somente depois que todas as minhas tentativas de refatoração falharam. O produto tinha código além do smelly, estava repleto de construções que criavam um comportamento indefinido. Não poderia ser trabalhado de forma eficaz.
Se você tiver alguma esperança em refatorar, refatorar. Se não houver nenhum ... não. A menos que o projeto seja mais do que trivial, não deve ser possível reescrever em menos tempo do que o necessário para refatorar.
Other problems hidden deeper were difficult to find, as well as a virus in the body.
Como isso aconteceu ?! Você está usando o controle de versão?
Geralmente eu não sou um defensor de reescrever o código desde o início, já que o código de produção geralmente terá sido modificado ao longo do tempo para lidar com muitas nuances. Dito isso, todo o "vírus" me deixaria mais inclinado a começar do zero, já que eu gostaria de revisá-lo em detalhes microscópicos de qualquer maneira.Isso me fez pensar muito: "Quando novos recursos são adicionados a este módulo, alguns recursos originais dão errado." Eu vi isso acontecer com bastante frequência e, IMHO, a razão está principalmente relacionada ao fato de que o princípio "abrir / fechar" não é seguido.
Basicamente, você não deve adicionar novos recursos modificando código existente, funcional e bem testado. Em vez disso, você deve adicionar novos recursos escrevendo um novo código no qual o código antigo não depende.
Então, se a extensão do seu código quebrar recursos antigos, será que o código não está sendo estendido corretamente?