Refatoração de baixo impacto e limpeza de código de código incorreto enquanto aguarda os requisitos

Eu herdei uma base de código existente para um produto que é repreensivelmente desleixado. O projeto fundamental é lamentavelmente inadequado, o que infelizmente eu posso fazer pouco sem um refator completo (acoplamento ALTO, baixa coesão, duplicação desenfreada de código, nenhuma documentação técnica do projeto, testes de integração em vez de testes de unidade). O produto tem uma história, alta exposição a clientes críticos de "vaca leiteira" com tolerância mínima a riscos, dívida técnica que fará os gregos corarem, base de código e complexidade MUITO grandes e uma abordagem derrotista e cansativa da equipe antes dos erros. mim.

A equipe antiga saltou de navio para outra divisão para que eles tivessem a oportunidade de arruinar outro projeto. É muito raro eu experimentar uma falha técnica de projeto de incompetência em oposição a uma falha de gerenciamento de projeto, mas esse é realmente um desses casos.

No momento, estou sozinho, mas tenho muito tempo, liberdade de decisão e direção futura e a capacidade de formar uma equipe do zero para me ajudar.

Minha pergunta é obter opinião sobre refatoração de baixo impacto em um projeto como esse quando você tiver algum tempo livre durante a fase de coleta de requisitos funcionais. Existem milhares de avisos do compilador, quase todos eles importações não utilizadas, variáveis ​​locais não lidas, ausência de verificação de tipo e transmissões não seguras. A formatação do código é tão ilegível e desleixada que parece que o codificador sofria da doença de Parkinson e não conseguia controlar a quantidade de vezes que a barra de espaço foi pressionada em qualquer linha. Normalmente, outros recursos de banco de dados e arquivos são abertos e nunca são fechados com segurança. Argumentos de método inútil, métodos duplicados que fazem a mesma coisa, etc.

Enquanto aguardo os requisitos para o próximo recurso, tenho limpado coisas de baixo impacto e baixo risco à medida que vou imaginando se estou desperdiçando meu tempo ou fazendo a coisa certa. E se o novo recurso significar extrair código em que passei mais tempo? Vou iniciar uma abordagem ágil e entendo que isso é aceitável e normal para refatorar constantemente durante o desenvolvimento ágil.

Você consegue pensar em algum impacto positivo ou negativo que eu gostaria de adicionar?

Em primeiro lugar, gostaria de salientar que os testes de unidade não substituem os testes de integração. Os dois precisam existir lado a lado. Seja grato por ter testes de integração; caso contrário, uma de suas pequenas refatorações pode muito bem fazer com que uma das vacas de baixa tolerância fique insensata com você.

Eu começaria a trabalhar nos avisos do compilador e nas variáveis ​​e importações não utilizadas. Obtenha uma compilação limpa primeiro. Em seguida, comece a escrever testes de unidade para documentar o comportamento atual e inicie a refatoração real.

Não vejo realmente nenhum impacto negativo. Você obterá um profundo entendimento da base de código, o que ajudará em refatorações maiores. É quase sempre preferível refatorar do que reescrever, pois durante a refatoração você ainda tem um produto em funcionamento, enquanto durante a reescrita você não o faz. E no final, as vendas do produto têm que pagar seu salário.

Quando os requisitos começarem a entrar, eu usaria o que chamo de abordagem de destaque. Faça a coisa ágil usual (priorize, depois corte uma pequena laje para uma iteração e trabalhe com isso) e deixe bastante tempo para melhorias no código. Refatorar onde você está trabalhando de qualquer maneira. Com o tempo, isso abrangerá grandes áreas da base de códigos, sem que você precise se aventurar em áreas nas quais teria dificuldade em justificar ao gerenciamento por que está trabalhando nessa parte do código.

Escrever testes de unidade pode ser um uso mais valioso do seu tempo: fornecerá algumas idéias sobre o funcionamento atual da base de código e, se você decidir começar do que tem, em vez de reescrever tudo do zero, terá uma base sólida para fazer alterações sem correr muito risco. As chances são de que, ao escrever testes de unidade, você também fará alterações na base de código apenas para obter uma forma testável; esses são bons, porque testável por unidade geralmente também significa modular, encapsulado e principalmente independente do estado externo. E, acima de tudo, testes de unidade bem escritos são uma documentação técnica valiosa. Com os testes de unidade, você poderá julgar o que a base de código atual pode ou não fazer, em vez de fazer palpites ou reescrever as coisas por precaução.

Respostas combinadas - meu pensamento seria misturar testes e limpeza - talvez 50/50? Se você trabalha em uma área usando uma abordagem de TDD - configure os testes necessários para saber que os testes de unidade e integração são os desejados e inicie a correção. Siga em frente quando o tempo permitir.

Provavelmente significa que você não fará tanto progresso, mas significa que você terá uma base de código bastante estável em algumas áreas, pelo menos, e terá uma boa base inicial.

Minha reação intestinal foi inicialmente "pode ​​doer realmente limpar código quebrado?" (aka, erros de compilador), mas lembrei-me de momentos em que a correção do problema realmente quebrava a funcionalidade em alguns casos realmente estranhos, porque, em vez de um thread morrer, deixava a memória em lugares ruins - essencialmente, uma falha ruim mascara um erro ainda pior. Pode literalmente ser uma caixa de Pandora de surpresas desagradáveis.

Dado que você está fazendo isso enquanto aguarda mais requisitos, acho que tudo o que puder para diagnosticar o caos aumentará bastante sua sanidade a longo prazo.