Trazendo Nova Arquitetura Durante a Manutenção em Sistemas Legados

5

Recebi a tarefa de adicionar alguns novos recursos a um projeto herdado da ASP.NET MVC2. A base de código é um desastre e eu quero escrever esses novos recursos com algum pensamento por trás da implementação e não apenas jogar esses novos recursos na bagunça. Eu gostaria de introduzir coisas como injeção de dependência e o padrão do orquestrador; apenas para o código que vou escrever. Eu não tenho tempo suficiente para tentar refatorar todo o sistema.

Não há problema em não ser consistente com o restante da base de código e adicionar novos recursos seguindo princípios de design diferentes? Não devo introduzir novos padrões e apenas implementar os recursos?

Eu sinto que pode ser confuso para a próxima pessoa ver partes do sistema usando um design que outras partes não estão seguindo.

    
por Mike L. 12.06.2012 / 20:02
fonte

3 respostas

5

Eu estive em uma situação semelhante e é uma decisão difícil. Como você apontou, seria bom começar a limpar o código e (de preferência) poder limpar tudo ao longo do tempo. Por outro lado, seria bastante irritante para os futuros desenvolvedores verem essas marcas doloridas no código, independentemente de quão bom o código foi escrito.

Na situação em que eu estava, tentei muitas coisas diferentes. O código era, e ainda é, horrível . Algumas das mudanças que experimentei foram drásticas e outras menos. Mas sempre que tentei refatorar o código, descobri que isso apenas tornaria o código mais complicado e difícil de entender.

Por fim, tentei encontrar padrões que existiam no espaguete. Depois que eu identifiquei alguns, comecei a formalizá-lo. Isso exigiu muito poucas mudanças, porque eu estava adicionando principalmente interfaces e identificando áreas da base de código que poderiam ser feitas um pouco mais genéricas com mudanças drásticas. Isso acabou funcionando muito bem. Agora a bagunça parecia como se tivesse uma estrutura, e isso por si só tornou mais fácil raciocinar sobre isso.

Se você puder fazer isso em uma área chave (provavelmente relacionada às solicitações de recursos) e ramificá-los para áreas similares da base de código, você deixará o código um pouco melhor do que você achou, mas sem transformando a floresta em um shopping center.

Além disso, confira O código fede! O que eu faço? no Blog da comunidade de programadores .

    
por 12.06.2012 / 20:16
fonte
2

Acho melhor que pelo menos parte do sistema seja escrita "corretamente", em vez de todo o sistema ser consistente, mas difícil de usar.

Eu faria anotações de que o código inalterado deveria ser alterado em algum momento (espero que em breve), e continue a refatorar as coisas conforme você avança.

É muito improvável que você refatorasse todo o sistema de uma só vez, então tudo bem se houver momentos temporários de inconsistência, contanto que você esteja indo em direção a uma base de código mais limpa.

    
por 12.06.2012 / 20:16
fonte
1

Eu aconselho não deixar o status quo ditar o futuro, em geral. Enquanto há algo a ser dito para a continuidade, há muito pouco a ser dito para continuar a sugar (perdoem a expressão). Qualquer pequena vantagem em termos de legibilidade / compreensibilidade, ao não introduzir novos padrões de desenvolvimento, provavelmente será compensada pela própria natureza da confusão.

Se há muitas outras pessoas trabalhando no projeto, e elas trabalharam e contribuíram para a bagunça, então eu acho que elas precisam ver como é a "não bagunça". Se você nunca introduzir "não bagunça", ninguém terá outro exemplo a seguir além da bagunça. Um bom design tem que começar em algum lugar, e se você está claro em seu propósito e é bom em explicar a filosofia, outras partes do código começarão a se alinhar com seu esforço.

    
por 12.06.2012 / 20:18
fonte