Olá, Habr! No Luxoft TechFest realizado em 28 de janeiro, Mikhail Zankovich, líder da equipe sênior da Luxoft , falou sobre aplicativos com hereditariedade severa. Hoje ele compartilha pensamentos adicionais implicados no conteúdo deste relatório, que causou uma discussão bastante acalorada durante o encontro.
Que emoções e associações a frase "Temos um projeto legado" evoca em você? Na maioria das vezes - falta de estrutura, caos, toneladas de códigos não documentados, horror, anarquia arquitetônica, nojo, um mar de muletas, você tem que correr! Minhas emoções: “Oh! Finalmente, algo interessante. Vamos fazer funcionar! " Suspeito que seja uma reação muito incomum.
Neste artigo, tentarei revelar uma ideologia diferente de trabalho com legado. Vamos designá-lo como "restauração de software". Não pretendo mudar sua atitude em relação ao Legacy, mas se você conseguir pelo menos semear um grão de dúvida de que o Legacy pode ser interessante, ficarei feliz.
Legado típico
O que é legado? Na minha experiência, você pode criar a seguinte lista de verificação para conformidade de produtos legados:
- .
.. , , .
- .
, black-box. . . - .
, . - .
. / ..
Tudo isso leva ao fato de que se torna cada vez mais difícil manter tal projeto a cada lançamento, assim como trabalhar em novas funcionalidades / novos requisitos. Qualquer mudança se transforma em engenharia reversa com teste de regressão obrigatório, etc. Como resultado, o projeto se torna caro para manter e é “congelado” em sua forma atual com a minimização de quaisquer alterações.
Mas por que aparecem produtos legados?
Raramente uma equipe cria de forma consciente e proposital um produto de baixa qualidade. Na maioria das vezes, isso é o resultado de oportunidades limitadas pela situação atual do projeto.
Não há requisitos claros - não há possibilidade de um design equilibrado da funcionalidade do aplicativo.
Requisitos em constante mudança, formulação pouco clara, prazos de implementação apertados, dívida técnica em constante crescimento são sinais claros de processos de desenvolvimento ágil em uma equipe que não foi capaz de se adaptar totalmente a essas abordagens “ágeis”. E de "flexível" apenas "solicitações de mudança rápida da empresa" de trabalho.
Isso geralmente leva a uma maior rotação dentro da equipe, o que, por sua vez, não tem um efeito positivo na qualidade. Imagine um novo especialista entrar para a equipe, por dois ou três meses ele só se aprofunda no processo, depois por um mês e meio ou dois meses ele implementa algum tipo de funcionalidade e se prepara para sair do projeto. Ele não está interessado em um produto de qualidade, documentação completa de sua parte, transferência de conhecimento para colegas, etc. A experiência é confusa.
Em algum momento, uma decisão fatal é tomada: é mais fácil substituir / desligar do que acompanhar. E o projeto entra na fase de “baixa manutenção”, quando é apoiado em uma base de sobras, tentando minimizar mudanças, criar “muletas” adicionais que implementam novas solicitações de forma rápida, mas deficiente. Por que alta qualidade? O produto vai mudar. Neste modo, o produto pode sobreviver por muitos anos, ficando coberto de "muletas" e se tornando mais monstruoso.
Resumindo todos os itens acima, as seguintes razões principais para o surgimento de produtos legados podem ser identificadas:
- prazos apertados para a implementação da funcionalidade;
- falta de requisitos claros / requisitos que mudam intensamente;
- aumento da rotação dentro da equipe;
- planejamento impróprio do ciclo de vida.
Acrescentamos aqui o nível de desenvolvimento profissional dos especialistas neste momento. Abra seu projeto há cinco ou dez anos. Tenho certeza de que você pode encontrar facilmente elementos que implementaria de forma diferente agora.
Então, tomamos como um axioma: "o código não é criado inerentemente ruim". Isso significa que qualquer produto teve algum tipo de ideia. E se o código entrou em produção, ele funcionou e atendeu às necessidades da empresa naquele momento.
Abordagem de escolta
As tarefas por parte dos clientes são bastante simples: manter o legado em bom estado de funcionamento sem interromper os processos de negócios atuais (alguns dos quais geralmente desconhecidos por ninguém), ao desenvolver a funcionalidade de acordo com os novos requisitos de acordo com o orçamento, que é provavelmente limitado.
A abordagem típica de uma equipe que embarca em um projeto é continuar lentamente, mas certamente, piorando as coisas. Não toque muito, mude apenas o que for solicitado e somente quando for solicitado. Se o módulo funciona, mas requer modificação da lógica - deixe e não mexa - é melhor criar outro, mas com a lógica necessária. O caos cresce, o aplicativo fica mais complicado.
A abordagem do restaurador
A abordagem de um restaurador de software é descobrir que tipo de mecanismo está à sua frente. Qual foi a ideia principal por trás de seus criadores. Tente eliminar tudo o que for desnecessário e guarde o melhor. Se você alterar a estrutura existente, ela é extremamente cuidadosa e atenta aos detalhes. Nem um único detalhe que afeta o sistema deve ser escondido da vista do restaurador. As alterações introduzidas são primeiro trabalhadas de acordo com a lógica de manutenção e, em seguida, é feita uma análise para determinar a possibilidade de implementar uma solução completa.
Este é um trabalho difícil e demorado. Nem todo desenvolvedor está disposto e, mais importante, realmente capaz de fazer a restauração. Os requisitos para o nível do restaurador são uma ordem de magnitude maior do que para um desenvolvedor comum. Sem experiência em projetos reais, sem entender como os sistemas podem se desenvolver, sem colisão não só com as melhores abordagens na prática, mas também com implementações claramente malsucedidas, não há sentido em restaurar.
Em vez do primeiro impulso típico “Sim, são muletas! Tudo precisa ser reescrito aqui! " - um verdadeiro restaurador fará a pergunta “Por que foi feito desta forma? Como exatamente foi planejado usá-lo? " E só depois de se certificar de que não havia pré-requisitos óbvios para a criação de tal código, o restaurador pode exclamar: “Sim, são muletas! Tudo precisa ser reescrito aqui! ”, E com uma sensação de dever cumprido, ele pode realmente interromper crescimentos desnecessários na estrutura ossificada do software, tornando o objeto de restauração melhor e de maior qualidade.
Mas isso raramente acontece, embora dê um prazer indescritível ao restaurador. Na maioria das vezes, você precisa desembaraçar o emaranhado de dependências entre os diferentes módulos. Não é incomum que os fios se estendam muito além da área de responsabilidade do componente que está sendo desmontado (e às vezes do sistema). E todas essas complexidades de relacionamentos de módulo devem ser levadas em consideração durante a restauração.
Assim, o restaurador de software trabalha na interseção de desenvolvimento, arquitetura, análise de negócios, testes e medicina. E é difícil dizer quais habilidades das áreas designadas são as de maior prioridade. Deve haver um certo equilíbrio entre eles, temperado com um desejo honesto de se engajar na restauração. O que a medicina tem a ver com isso? Portanto, o princípio básico do restaurador é “primum non nocere” - em primeiro lugar, não causar danos.
Na verdade, essa abordagem será considerada mais adiante em exemplos específicos, gradualmente desmontando e restaurando o legado típico herdado dos proprietários técnicos anteriores dos sistemas. E com exemplos específicos, vamos ver por que todas as habilidades acima são importantes.
Restauração de data warehouse
O que o sistema armazena?
Ao pousar em um novo projeto, o restaurador prestará atenção aos objetos processados pelo sistema. Para mergulhar totalmente nos fluxos de negócios e código-fonte, especialmente na ausência de documentação normal, isso levará pelo menos vários meses.
Uma das primeiras tarefas de um restaurador é avaliar a eficácia da abóbada. Você pode melhorar algo sem confiar na compreensão dos processos de negócios? Um ponto problemático típico de qualquer data warehouse está principalmente relacionado ao volume desses mesmos dados. Quanto maior o volume, maior o custo de propriedade do sistema.
O segundo ponto problemático é o crescimento desse mesmo volume, o que afeta negativamente o desempenho do sistema em primeiro lugar. Provavelmente, já existem algumas práticas para reter informações no sistema, mas quão eficazes são?
Todas as práticas consideradas aqui são mais aplicáveis ao RDBMS clássico, mas a abordagem não é muito diferente para soluções sem sql.
Uma das principais táticas do restaurador nessa direção é a criação de monitoramento de objetos de armazenamento de informações. No caso do DBMS clássico, monitoramento de tabelas.
É necessária uma estrutura que permitirá que os metadados do sistema coletem dados periodicamente em dois parâmetros triviais - a quantidade de dados e o número de elementos em cada tabela. A frequência terá que ser selecionada manualmente (mais sobre isso abaixo), com base nas características do sistema. Um período de inicialização típico de 24 horas é suficiente para a análise básica.
Analisando dados
O que fazer com os dados? O que procurar? O primeiro momento é identificar os “objetos mais pesados”. Na prática, a regra 20/80 padrão funciona - não mais que 20% dos objetos usarão mais de 80% do espaço. Isso permite estreitar significativamente a área de análise no primeiro estágio.
Quanto mais longas e mais detalhadas essas estatísticas são acumuladas, mais claramente o comportamento do sistema é refletido. A experiência mostra que o período recomendado é de pelo menos duas semanas. A ideia principal é "enganchar" dias / períodos não úteis nos quais os mecanismos de limpeza e arquivamento de informações são mais frequentemente implementados.
Então, a estrutura está escrita e o restaurador espera pelos resultados por duas semanas? Claro que não. Não luta contra a ideologia do restaurador. Com o primeiro bloco de dados em mãos, você pode fazer algumas análises básicas. A saber - para ver a proporção do espaço ocupado para o número de objetos armazenados (linhas). Quanto maior for esse valor, mais provável é que os campos BLOB sejam armazenados aqui. E apenas essas tabelas e campos se tornam o objeto de pesquisa e análise para o restaurador.
Perguntas principais: Com que frequência os processos de negócios realmente acessam esses objetos? O proprietário do sistema, a equipe existente, pode lançar alguma luz sobre esses pontos. E, de repente (e na prática com muita frequência), esses campos armazenam informações que não são importantes para o negócio: despejos de objetos / mensagens para análise pela equipe de desenvolvimento, comentários do usuário exibidos apenas durante a criação de um pedido, etc.
A próxima etapa: se os dados não são usados com frequência ou não têm um valor comercial claro, por que não movê-los para o arquivo? Ao mesmo tempo, uma abordagem cardinal com a divisão de uma mesa monolítica em partes, movendo os blobs para um meio mais barato / mais lento, mas ao mesmo tempo preservando a interface original da mesa (o ponto principal é que não há informações confiáveis sobre todos processos que acessam essas informações, o que significa que as alterações não devem prejudicá-los) - pode ser um problema técnico bastante interessante e complexo.
Uma tarefa menos interessante, mas igualmente útil, é usar o sistema de armazenamento de dados embutido para arquivar os valores de certos campos. Por exemplo, Sybase ASE tem o recurso ASE_Compression, Mongo DB permite definir opções de compactação para coleções, etc. Quase qualquer sistema de armazenamento de dados tem a opção de compressão de dados adicional “por baixo do capô”. A funcionalidade funcionará de forma transparente para sistemas externos e não exigirá mudanças drásticas. Na prática (especialmente em sistemas legados), essas opções de compactação de dados não são usadas por padrão.
É claro que, ao aplicar a compressão, o restaurador deve primeiro avaliar o impacto da abordagem no desempenho e, para isso, os principais indicadores de desempenho do sistema devem ser trabalhados ou, em casos extremos, elementos de teste de regressão devem estar presentes.
Em geral, há algo a fazer por algumas semanas enquanto estatísticas completas sobre os objetos são coletadas.
Grandes estatísticas: o que procurar
Tendo recebido estatísticas durante um longo período de tempo, o restaurador tenta descobrir o que está acontecendo com a dinâmica do espaço utilizado. Todos os valores para uma tabela / objeto são normalizados para o original. Isso tornará possível estimar com precisão o aumento relativo nos dados e identificar os objetos que mudam mais intensamente.
O perfil gerado provavelmente corresponderá a um dos seguintes tipos:
Perfil 1 - valor constante. Provavelmente, esses diretórios são estáticos e não é tão interessante trabalhar com eles. A abordagem de arquivamento descrita acima pode ser aplicada com base na intensidade de uso do diretório.
Pequenas flutuações de volume - perfil 2- eles podem falar sobre um livro de referência e uma mesa operacional, em que a leitura / gravação de dados é intensiva. Esses são os objetos mais difíceis do ponto de vista do restaurador, porque é necessário analisar seu comportamento o mais detalhadamente possível. É para esses objetos que faz sentido aumentar a frequência da coleta de informações: não uma vez por dia, mas uma vez por hora, uma vez por minuto. O objetivo principal é rastrear a mudança de perfil com mais detalhes e entender as dependências de comportamento.
Os perfis 3 e 4 são de maior interesse. Perfil 3(“Saw”) afirma claramente que esta tabela é limpa periodicamente. Mas a tendência de crescimento - cada vez após a limpeza, o volume final é um pouco maior do que antes - fala da ineficiência dos mecanismos de limpeza existentes. Essa. durante um certo período de tempo, mais dados aparecem no sistema do que são excluídos no final do período. Este pode ser um processo de negócios completamente normal, um aumento clássico na carga do sistema.
Mas, para o restaurador, isso é, antes de mais nada, um sinal: há condições para excluir informações? Com base na prática, muito provavelmente algumas entidades, devido às condições complexas de retenção de dados no sistema, indevidamente permanecem para sempre no armazenamento. O objetivo do restaurador é identificar essas entidades e também incluí-las em atividades periódicas.
Se o perfil 3 degenera em crescimento constante, este é o primeiro candidato a um gargalo no sistema. Em primeiro lugar, não há indicadores explícitos para o processo de arquivamento e, em segundo lugar, a degradação do desempenho é esperada com o crescimento dos dados.
Perfil 4- um exemplo típico de uma tabela de arquivo com preenchimento periódico de dados. Observe que o crescimento da tabela ocorre apenas em determinados dias. É bem possível que as correlações com as tabelas do terceiro perfil sejam perceptíveis. Para tabelas de arquivo, também é importante entender o princípio de seu uso - há uma chamada para eles dos usuários? Ou é uma história para analisar? Ou são dados para sistemas de relatórios? Dependendo das respostas a essas perguntas, é bem possível que seja tomada a decisão de separar as tabelas de arquivo em um circuito separado, uma base separada, uma seção separada. Assim, liberando espaço operacional.
Como isto funciona na pratica?
Em um dos projetos, um exercício semelhante foi feito no primeiro mês e meio após a adesão ao projeto. Os objetos do perfil nº 3 eram o alvo e foram encontrados. Aplicar as práticas descritas (melhorar as condições de limpeza), excluir dados que não foram usados no sistema, etc. permitiu reduzir o volume do espaço ocupado em mais de 25%, bem como impedir o crescimento intensivo do armazenamento.
Como resultado, pudemos fazer as primeiras alterações técnicas no projeto e enviar planos para melhorar a funcionalidade. O cliente ficou satisfeito com o resultado da equipe, que passou de 3 para 9 desenvolvedores. Ao longo do ano continuamos as investigações, os pontos de melhoria na funcionalidade foram utilizados para apoiar o sistema e suas características.
Dois analistas foram adicionados a nós, de modo que a equipe começou a se envolver em seu próprio desenvolvimento - não no suporte, mas na implementação de novas funcionalidades de negócios. Agora estamos desenvolvendo um novo sistema.
Para que serve tudo isso?
Se você leu até aqui, provavelmente está procurando uma resposta para a pergunta: "Por que tudo isso?" Em primeiro lugar, a restauração é um processo separado, não como desenvolvimento, não como suporte, mas combinando-os.
Esta é uma unidade separada para um especialista técnico - para mergulhar na lógica da pessoa que criou este produto, para entender seu significado, para limpar o produto de coisas desnecessárias e torná-lo ainda melhor do que era. O aplicativo parece uma missão, com muitos mistérios e reviravoltas desconhecidas.
Não, você não está criando do zero, está restaurando um produto existente, mas talvez destruído pelo tempo. Entre outras coisas, o restaurador tem uma oportunidade única de bombear em qualquer uma das seis direções (veja a imagem acima), enquanto tem um produto real à mão como base de teste. Um senso de autocontrole também é estimulado - não para cair no perfeccionismo técnico, mas para pensar e fazer apenas as mudanças que são necessárias para o sistema em termos de melhoria de processos.
Tudo isso torna o trabalho com sistemas legados excitante e incomum. Mas a escolha final para restaurar ou manter é sua.
O relatório de Mikhail Zankovich no Luxoft TechFest pode ser visto aqui .
O autor do artigo é Mikhail ZankovichMikhail Zankovich