Iniciando uma arquitetura coerente em um aplicativo herdado

Eu sou responsável por um grande site baseado em Asp.Net. Atualmente, é um site (não aplicativo da web), alguns serviços do Windows e várias bibliotecas de classes.

A camada de dados usa uma mistura de LLBLGEN e Linq To LLBGen, além de várias instâncias de SQL embutido herdado que não foram refatoradas.

Existem algumas implementações do tipo gerente, mas em muitos casos o aplicativo exibe o antipadrão da UI inteligente (ou seja, muita lógica de negócios no código por trás das classes)

O site tem tráfego razoavelmente alto e o desempenho é bom, mas estamos aumentando nossa capacidade de desenvolvimento para uma equipe de cerca de 10 pessoas e, cada vez mais, fica claro que precisamos de um design em camadas abrangente sobre o middleware existente.

Minha pergunta é por onde começar? Temos 10 anos de código (alguns deles ainda realmente migraram coisas do ASP Classic), muitas abordagens e estilos diferentes.

Refatorar toda a base de código não é realista e, provavelmente, não é desejável

Sei que não é uma situação nova, existem idéias ou conceitos úteis sobre como abordar esse problema?

Também tenho trabalhado em situações semelhantes e posso lhe dar os seguintes conselhos.

1. Você precisa reduzir a dívida técnica . Agora. Por quê? Porque a dívida técnica é como dívida financeira. Você pagará juros sobre ele.
2. Como a refatoração de toda a base de código não é viável, pergunte-se: o que está impedindo? É simplesmente muito trabalho? Por quê?
3. Crie um plano para reduzir a dívida técnica a tempo. Por exemplo, configurando regras como " todo pedaço de código tocado pela equipe deve ser corrigido / refatorado para o novo padrão ". Normalmente: os testes de unidade devem ser escritos, o código deve ser movido nas camadas corretas, etc. Isso permite que você conserte muito código sem recorrer a projetos de "refatoração" ridiculamente caros e de baixo valor.
4. Enrole a porcaria. A dissociação é a chave para refatoração e boa arquitetura. Se você puder particionar a base de código de alguma forma, talvez possa refatorar bits menores.
5. Não aumente ainda mais a dívida de tecnologia. Não aumente ainda mais a dívida de tecnologia. Não aumente ainda mais a dívida de tecnologia. Não...

Você está certo que a refatoração de toda a base de código não é desejável. A refatoração é algo que você faz antes do novo desenvolvimento para tornar esse desenvolvimento mais suave. Se você não planeja modificar todo o código da sua base de código, a refatoração será um uso ineficiente do tempo.

Alguns conselhos além do que Sklivvz diz:

1. Separe o código em seções modificadas com frequência e com pouca frequência. Somente as seções frequentemente modificadas precisam ser totalmente integradas à nova arquitetura. Integre o código modificado com pouca frequência à nova arquitetura usando o mínimo de alterações possível (ou nenhuma alteração, se você conseguir se safar). Resista à tentação da reescrita completa, vai custar mais do que você ganha com isso. Avalie que o código existente funciona, mesmo que seja feio.

2. Descubra qual é o seu objetivo de refatoração. Deseja facilitar a inserção de conteúdo no site? Você tem muitos bugs e deseja melhorar a qualidade percebida pelo usuário? Deseja reduzir o tempo de desenvolvimento de recursos? Ou você quer principalmente um UX melhor? Sua arquitetura deve facilitar a refatoração do código para atender às metas definidas. Nunca esqueça que o principal beneficiário da sua refatoração deve ser seu usuário / cliente / empresa. O código mais limpo não é um objetivo em si, é um método para um fim, e o fim envolve um usuário.

3. Tente encontrar o maior número possível de arquiteturas de referência e não tenha medo de copiá-las. Não reinvente a roda. Se alguém tiver uma arquitetura que funcione bem para sites como o seu, aprenda com eles.

4. Pense no lado de gerenciamento de pessoas. Nos meus próprios projetos de migração, a parte mais difícil foi fazer as pessoas aprenderem os novos caminhos e seguirem-nos. Você precisará de implementações de referência e uma maneira de ensinar a arquitetura a todos da equipe (antigos e novos). Para reduzir a resistência à mudança, peça a opinião de todos da equipe antes de tomar decisões. Certifique-se de que o novo design realmente melhore as coisas da perspectiva pessoal dos desenvolvedores e não seja um salto tão grande que eles se sintam fora de profundidade.

A coisa MAIS importante que vi ao tentar lidar com uma antiga base de código é NÃO continuar mudando o que você está filmando. Ou seja, descubra a arquitetura desejada e, em seguida, FIQUE COM ESSE PLANO! Um dos grandes problemas que minha última posição teve foi que a base de código tinha várias idéias diferentes de como deveria ser ao longo do tempo. Cada vez que uma nova idéia era tentada, parte do código era convertido, outros não, e então outra pessoa tinha uma ideia 'melhor'. Tornou-se cada vez mais incoerente ao longo do tempo e acabou sendo descartado.

Existe um livro / pdf gratuito realmente bom sobre o software legado de reengenharia: http://scg.unibe.ch/download/oorp/

Diz OO no título, mas a maioria das idéias se aplica a qualquer software. Ele discute por onde começar, como lidar com diferentes partes de um sistema durante a reestruturação e muito mais desses tópicos.

Se não possui uma arquitetura coerente, é porque o gerenciamento não entende / se preocupa com o problema. Apenas codifique. Você deve introduzir uma nova arquitetura boa ao escrever um novo código.

Você deve re-arquitetar as coisas apenas se elas começarem a ter erros realmente sérios, você precisará estendê-las e simplesmente não poderá, ou apenas não atenderá aos requisitos.

Estou basicamente dizendo que só se preocupam com problemas com os quais seus gerentes realmente se importam, não com os quais eles se importariam se tivessem seu conhecimento.

Se você pode vender a re-arquitetura ao gerenciamento, comece com o teste. Se eles não querem investir em testes, seus esforços só lhe causam problemas.