Como consertar um projeto basicamente sem estrutura?

Trabalho em um projeto de software principalmente solo há mais de 5 anos. Era uma bagunça para começar (eu sou o terceiro ou quarto desenvolvedor a trabalhar nela), e embora seja menos bagunçada agora, ainda está incrivelmente desorganizada. A taxa de progresso em controlá-la é glacial e estou começando a me sentir desanimado com o estado em que está. Como realmente começo a consertá-lo?

Detalhes do projeto: é um programa de vendas escrito quase inteiramente no Visual Basic Classic (VB6) com um back-end do MySQL e um mecanismo de relatório escrito em C #. É um prazer trabalhar com o módulo de relatórios C #, ele foi escrito apenas nos últimos dois anos e antes que todos os relatórios fossem feitos no Crystal Reports 9 (sim, ainda temos alguns relatórios que dependem dele).

O programa em si, no entanto, é um desastre completo. Não há um total de 90k LOC e cerca de 10k linhas de comentários (a maioria não é documentação, mas o código antigo que foi comentado). 158 arquivos de formulário e 80 arquivos de módulo. Não tenho idéia de quantas delas são realmente usadas, porque alguns recursos do programa são simplesmente obsoletos e (algumas vezes) são anotados como tal sem que o código associado seja removido do programa. Eu acho que apenas 50% do código está em uso produtivo real.

Eu tenho medo de tocar muito no código só porque não tenho certeza se estou quebrando algo em que um cliente obscuro se baseia, isso aconteceu em mais ocasiões do que eu posso contar. É como se houvesse minas terrestres espalhadas por todo o código.

Não há realmente nenhuma estrutura para o projeto. Não é orientado a objetos, exceto nos poucos lugares em que tive a paciência de reformar até agora. Se você precisar obter dados em um formulário, instancia um objeto de banco de dados, declara sua consulta ali mesmo na função, executa-a e faz o que quiser com o conjunto de dados.

Quando comecei a trabalhar no projeto, não havia controle de origem em uso. Tentei incentivar as outras pessoas em que estava trabalhando a usá-lo, mas eu era o cara novo e minhas tentativas de convencer as pessoas a usarem o subversion quase que falharam. O desenvolvedor líder da empresa finalmente pegou um bug mercurial nos últimos dois anos e garantiu que todos os desenvolvedores usem o controle de origem em todos os projetos agora, então pelo menos isso é um progresso.

Acho que se eu pudesse trabalhar na reforma do projeto em tempo integral, seria capaz de fazer um progresso decente e talvez até ter uma estimativa de quanto tempo levaria para eu reformar completamente o projeto, mas ele está em uso ativo e estou constantemente sendo solicitado a apagar incêndios, corrigir bugs, adicionar recursos etc. etc.

Então, como começo a consertar esse projeto? Tente usar a ferramenta VB6 com outro idioma? Tentar e reescrever o programa no meu tempo livre? Ou isso é completamente inútil?

Atualizar

Após esse post, voltei ao projeto com zelo renovado, mas voltei à desesperança alguns meses depois de ver uma taxa de progresso tão lenta. Repeti esse ciclo mais duas ou três vezes ao longo do próximo ano.

Desde então, mudei para um trabalho diferente. Embora depois de tantos anos de vb6, e apenas experiência periférica com outras tecnologias, a pesquisa tenha sido difícil e eu tenha enfrentado muitas rejeições ao longo do caminho (cerca de uma dúzia de entrevistas ao longo de um ano). Meu conselho para outras pessoas nessa situação é considerar deixar apenas esse fator. Considere o dano que você pode causar à sua carreira permanecendo em uma posição sem saída como essa.

Agora que está no controle de origem, você pode se livrar do código comentado.

Comecei aqui em uma situação semelhante (aplicativo 80KLOC VB6 sem controle de origem, sem estrutura real, quase tudo feito em manipuladores de eventos).

Em cerca de 2 anos, obtive mais da metade da conversão para C # (geralmente quando novos recursos significativos são necessários). Todo o novo código C # tem cobertura de teste de unidade. Definitivamente, leva muito mais tempo para converter em C #. Se você não estiver adicionando novos módulos significativos, eu não seguiria esse caminho.

Uma coisa que fiz foi criar uma camada rudimentar de acesso a dados que se gerou automaticamente a partir do banco de dados. Isso causou pelo menos problemas em que o nome de uma coluna de tabela foi alterado e não encontrei todos os locais no código. Além disso, lentamente movi a lógica de negócios para módulos, fora dos formuladores de manipuladores de eventos.

Eu, no entanto, tinha a vantagem de que o aplicativo era apenas interno. Como eu tinha apenas um site para implantar, eu poderia correr alguns riscos maiores do que você. Se eu cometi um erro, normalmente não era grande coisa corrigi-lo. Parece que você não tem esse luxo.

Realmente acho que sua melhor aposta é seguir a seguinte abordagem:

1. Aprenda cada detalhe com detalhes excruciantes. Isso torna menos provável que você quebre algo inadvertidamente.
2. Refatorar impiedosamente para melhorar a separação e a estrutura, mas não tente adotar uma nova metodologia como a programação orientada a objetos, pois o VB6 é uma droga.
3. Trate-o como uma experiência de aprendizado. Como você saberia que uma maneira diferente é melhor se você nunca viu a maneira inferior?
4. Não se preocupe em reescrever em um novo idioma / estrutura / plataforma, a menos que você tenha um módulo importante para escrever. Mesmo assim, considere cuidadosamente.

Lembre-se, o objetivo do programa é ser um produto que faça a sua empresa ganhar dinheiro. Não precisa ser uma obra de arte impecável (e sou perfeccionista, é realmente difícil admitir isso). Às vezes é melhor abraçar o pragmatismo.

Supostamente há muitos programadores COBOL por aí mantendo grandes quantidades de código legado. Duvido que todos estejam loucamente trabalhando para reescrevê-lo em algum novo idioma. :)

O que você precisa fazer é refatorar. A refatoração é quase impossível em uma situação sem teste de unidade que lhe dá a confiança de que você não quebrou nada. Portanto, comece com a criação de testes de unidade. Documente o comportamento do código - mas não (apenas) no papel, mas em mais código - os testes de unidade. Depois de realizar os testes, você poderá começar a reestruturar o código.

Uma regra de " Debugging " de David Agan vem à mente: pare de pensar e olhar. Você tem à sua disposição uma máquina capaz de processar grandes quantidades de texto. Use-o para descobrir exatamente qual código não está mais em uso e remova-o sem piedade. Se você cometer um erro, é para isso que serve o controle de origem.

Essa é a parte mais fácil. O que você precisa pensar a seguir é como você come um elefante? Uma mordida de cada vez. Pegue a " Refatoração " de Martin Fowler e leve-a função por função, arquivo por arquivo. Não descarte completamente algo e reescreva-o a partir do que você acha que são os requisitos. Trabalhe como um alpinista, nunca removendo sua segurança anterior até a próxima.

Já tinha metáforas suficientes? O ponto é que, se você o levar devagar e com firmeza, com muitas melhorias tão simples quanto renomear ou dividir uma função, você poderá melhorar as partes ruins do código sem destruir as partes boas que foram criadas através de anos de depuração e solicitações de recursos . Você deseja que o código permaneça expedido o tempo todo. Se for possível fazer isso enquanto estiver migrando para um idioma mais moderno, faça isso.

Eu odeio dizer isso, mas eu iria com "completamente sem esperança", além de continuar fazendo um ciclo interminável de correção / aprimoramento e espero que nada quebre. Já vi muitos projetos VB6 como o que você descreve e tenta refatorar / reescrever / refazê-los em C # / .NET falharem terrivelmente, geralmente com as pessoas encarregadas da tentativa de ser demitida.

O fato é que uma reescrita completa do zero será necessária mais cedo ou mais tarde. As versões VB6 e Windows que suportam bem estão em declínio. Encontrar desenvolvedores que conhecem as peculiaridades do VB6 e que estão dispostos a trabalhar em programas como esse está se tornando mais raro. Os limites internos do VB6 serão atingidos em programas enormes como esse, causando erros estranhos.

Se houver um bom consenso e comprometimento para um total, criar, redesenhar e reescrever neste momento, comece a trabalhar nele e delegue a manutenção contínua a outra pessoa (contratados, programadores juniores, o que for melhor para você). Se as pessoas ainda não estão convencidas o suficiente para começar isso, espere a dor se tornar grande o suficiente ou vá para pastos mais verdes.

Algumas boas respostas aqui já, gostaria de acrescentar uma coisa. Em vez de tentar reescrever tudo, talvez você tenha a chance de portar pelo menos alguns desses módulos principalmente 1: 1 para o VB.NET (é claro, você deve ter muito cuidado ao fazer isso)? De acordo com minha experiência, essa transferência pode ser feita com cerca de 5 a 10 vezes menos esforço do que tentar reconstruir todas as funcionalidades existentes do zero. E depois de ter portado-lo, então você pode começar a refatorar - com todas essas ferramentas disponíveis no mundo .NET, como boas ferramentas de teste de unidade, ferramentas de refatoração automática, OOP real, etc.

Eu estava em uma situação semelhante, na qual tivemos que migrar um antigo programa C ++ de 16 bits (150k LOC) para o mundo de 32 bits, onde a estrutura da GUI original em uso não estava mais disponível. Demorou algum tempo para entender que a reescrita não era realista, mas depois que decidimos portar essa coisa para o mundo .NET, usando C ++, C ++ / CLI e C #, precisávamos de apenas 9 meses para que isso acontecesse (com cerca de 1 desenvolvedor trabalhando em tempo integral nesse projeto). E não tínhamos testes de unidade disponíveis para a parte da GUI, fizemos todos esses testes manualmente.

Embora ponha muita ênfase no teste de unidade de seu aplicativo, o que, apesar de muito importante, é algo bastante difícil de fazer no VB6, Steven McConnell escreveu um excelente livro sobre como lidar com esse projeto.

Dê uma olhada nisto:

Steven C. MCCONNELL: Trabalhando efetivamente com o Legacy Code, segunda edição. Microsoft Press, junho de 2004.

Basicamente, seu objetivo é ir devagar, um pouco de cada vez. Ele também recomenda começar usando técnicas de refatoração que dificilmente quebram algo, às vezes piorando um pouco a curto prazo, e começar a usar técnicas mais avançadas, pois o código está ficando mais limpo e tem testes de unidade para apoiá-lo.