⚙️ 🤭 🉑 Como ler e corrigir 100.000 linhas de código por semana 🙇🏽 💅🏾 📜

No começo, é sempre difícil descobrir o projeto grande e antigo. A avaliação da arquitetura é uma das atividades do arquiteto. Geralmente, você precisa trabalhar com projetos grandes e antigos, e os resultados devem ser fornecidos em uma semana.

Como avaliar um projeto com um tamanho de 100k ou mais linhas de código por semana, enquanto fornece resultados realmente úteis para o cliente.

A maioria dos arquitetos e esses leads passou por avaliações semelhantes de projetos. Pode parecer um processo semi-formal ou um serviço separado, como é feito em nossa empresa, de qualquer maneira a maioria de vocês já lidou com isso.

O inglês original para seus amigos que não falam russo está aqui: Avaliação da arquitetura em uma semana .

A abordagem em nossa empresa

Vou lhe dizer como funciona em nossa empresa e como ajo nessas situações, mas você pode alterar facilmente essa abordagem de acordo com as necessidades do seu projeto e empresa.

Existem dois tipos de avaliação de arquitetura.

Interno - geralmente fazemos isso para projetos dentro da empresa. Qualquer projeto pode solicitar uma avaliação da arquitetura por vários motivos:

A equipe acha que seu projeto é perfeito e isso é suspeito. Tivemos esses casos e, em geral, nesses projetos, tudo está longe de ser perfeito.
A equipe quer testar seu projeto e suas decisões.
A equipe sabe que tudo está ruim. Eles podem até listar os principais problemas e causas, mas desejam uma lista completa de problemas e recomendações para melhorar o projeto.

Externo é um processo mais formal do que avaliação interna. Um cliente sempre vem apenas em um caso em que tudo está ruim - muito ruim. Geralmente, o cliente entende que existem problemas globais, mas não pode determinar corretamente as causas e decompô-las em componentes.

Avaliar a arquitetura para um cliente externo é um caso mais complexo. O processo deve ser mais formal. Os projetos são sempre grandes e antigos. Eles têm muitos problemas, bugs e códigos tortos. Um relatório sobre o trabalho realizado deve estar pronto dentro de algumas semanas, no máximo, onde deve haver os principais problemas e recomendações para melhoria. Portanto, se lidarmos com a avaliação externa do projeto, então interna será um absurdo. Considere o caso mais difícil.

Avaliação da arquitetura de um projeto corporativo

Um projeto típico de avaliação é um projeto corporativo grande e antigo com muitos problemas. Um cliente vem até nós e pede para consertar seu projeto. É como um iceberg, o cliente vê apenas a ponta dos seus problemas e não sabe o que está embaixo d'água (na parte de trás do código).

Problemas que o cliente pode reclamar e saber sobre eles:

Problemas de desempenho
Problemas de usabilidade
Implantação longa
Falta de unidade e outros testes

Problemas dos quais o cliente provavelmente não está ciente, mas eles podem estar presentes no projeto:

Problemas de segurança
Problemas de design
Arquitetura incorreta
Erros Algorítmicos
Tecnologia inadequada
Dívida técnica
Processo de desenvolvimento inválido

Processo formal de avaliação de arquitetura

Esse é um processo formal ao qual aderimos na empresa, mas você pode ajustá-lo por conta própria, dependendo da empresa e do projeto.

Pedido do cliente

O cliente pede para avaliar a arquitetura do projeto atual. A pessoa responsável de nossa parte coleta informações básicas sobre o projeto e seleciona os especialistas necessários. Dependendo do projeto, esses podem ser especialistas diferentes.

O arquiteto de soluções é a principal pessoa responsável pela avaliação e coordenação (e geralmente a única).
Os especialistas específicos da pilha - .Net, Java, Python e outros especialistas técnicos, dependendo do projeto e das tecnologias dos
especialistas em nuvem - podem ser arquitetos de nuvem do Azure, GCP ou AWS.
Infraestrutura - DevOps, administrador do sistema etc.
Outros especialistas são big data, aprendizado de máquina, engenheiro de desempenho, especialista em segurança, líder de controle de qualidade.

Coleta de informações do projeto

Você deve coletar o máximo de informações possível sobre o projeto. Você pode usar técnicas diferentes, dependendo da situação:

Questionários e outros meios de comunicação por correio. A maneira mais ineficiente.
Reuniões online.
Ferramentas especiais para troca de informações, como: Google doc, Confluence, repositórios, etc.
Reuniões "ao vivo" no local. A maneira mais eficaz e mais cara.

O que deve ser recebido do cliente?

Informação básica. Qual é o projeto? Sua finalidade e valor. Os principais objetivos e planos para o futuro. Objetivos e estratégias de negócios. Os principais problemas e o resultado desejado.

Informações sobre o projeto . Pilha tecnológica, frameworks, linguagens de programação. Implantação no local ou na nuvem. Se o projeto estiver na nuvem, quais serviços são usados. Quais padrões de arquitetura e design foram usados.

Requisitos não funcionais . Todos os requisitos relacionados ao desempenho, disponibilidade, usabilidade do sistema. Requisitos de segurança, etc.

Juskeys e fluxos de dados básicos.

Acesso ao código fonte . A parte mais importante! Você definitivamente deve ter acesso a repositórios e documentação sobre como montar um projeto.

Acesso à infraestrutura . Seria bom ter acesso ao palco ou à infraestrutura de produção para trabalhar com um sistema ativo. Isso é um grande sucesso se o cliente tiver ferramentas para monitorar a infraestrutura e a produtividade. Falaremos sobre essas ferramentas na próxima seção.

Documentação . Se o cliente tiver documentação, este é um bom começo. Pode estar desatualizado, mas ainda é um bom começo. Nunca acredite na documentação - verifique-a com o cliente, em uma infraestrutura real e no código-fonte.

Processo de Avaliação de Arquitetura

Como, então, processar uma quantidade tão grande de informações em tão pouco tempo? Antes de tudo, paralelize o trabalho.

DevOps deve olhar para a infraestrutura. Eu os conduzo ao código. Engenheiro de desempenho, consulte métricas de desempenho. Um especialista em banco de dados deve se aprofundar nas estruturas de dados.

Mas este é um caso ideal quando você tem muitos recursos. Normalmente, um projeto é avaliado por uma a três pessoas. Você mesmo pode realizar uma avaliação, o que geralmente acontece se você tiver o conhecimento e a experiência adequados em todas as áreas do projeto. Nesse caso, você precisa automatizar todos os processos o máximo possível.

Infelizmente, você terá que ler a documentação manualmente. Com a experiência adequada, você pode entender rapidamente a qualidade da documentação. O que é verdade lá e o que claramente não coincide com a realidade. Às vezes, você pode encontrar essa arquitetura na documentação que nunca funcionará na vida real. Este é um gatilho para você pensar, mas como isso é feito na realidade no projeto.

Ferramentas úteis para automatizar a avaliação do projeto

Avaliar um código é um exercício simples. Você pode usar analisadores de código estático para mostrar problemas de design, desempenho e segurança. Aqui estão alguns deles: O

Structure 101 é uma ótima ferramenta para um arquiteto. Ele mostrará o quadro geral, a relação entre os módulos e as áreas potenciais para refatoração. Como todas as boas ferramentas, custa muito dinheiro, ao mesmo tempo em que você pode usar a versão de avaliação de 30 dias.

SonarQube é uma boa ferramenta antiga. Ferramenta para análise de código estático. Permite identificar códigos incorretos, bugs e problemas de segurança para mais de 20 linguagens de programação.

Todos os provedores de nuvem possuem ferramentas de monitoramento de infraestrutura. Isso permitirá que você avalie corretamente a eficácia da infraestrutura em termos de custo e desempenho. Para a AWS, este é um consultor confiável . Para o Azure, é apenas um Consultor do Azure .

Monitoramento e registro de desempenho adicionais podem ajudá-lo a encontrar problemas de desempenho em todos os níveis. A partir de um banco de dados com consultas ineficientes, um back-end e finalizando com um front-end. Mesmo que o cliente não tenha instalado essas ferramentas antes, você poderá integrá-las rapidamente ao sistema existente para identificar problemas de desempenho.

Como sempre, boas ferramentas valem a pena. Eu posso recomendar algumas ferramentas pagas. Obviamente, você pode usar código-fonte aberto, mas precisará de mais tempo para isso. E isso deve ser feito antecipadamente, e não no processo de avaliação da arquitetura.

New Relic - ferramenta de avaliação de desempenho de aplicativos
Datadog - serviço de monitoramento de irmã baseado em nuvem

Há muitas ferramentas para testes de segurança. Desta vez, vou recomendar uma ferramenta gratuita de verificação do sistema.

OWASP ZAP é uma ferramenta para varrer aplicativos da Web quanto à conformidade com os padrões de segurança.

Juntando tudo.

Estamos preparando um relatório

Inicie seu relatório com dados do cliente. Descreva os objetivos do projeto, limitações, requisitos não funcionais. Depois disso, todos os dados recebidos devem ser mencionados como código fonte, documentação e infraestrutura.

O próximo passo. Liste todos os problemas encontrados manualmente ou usando ferramentas automatizadas. Coloque grandes relatórios gerados automaticamente no final da seção de aplicativos. Aqui deve haver evidência curta e sucinta dos problemas encontrados.
Priorize os problemas encontrados na escala de erros, avisos e informações. Você pode escolher sua própria escala, mas isso geralmente é aceito.

Como um verdadeiro arquiteto, você deve fornecer recomendações sobre como corrigir os problemas encontrados. Descreva as melhorias e o valor para os negócios que o cliente receberá. Como mostrar o valor comercial derefatoração de arquitetura que discutimos anteriormente.

Prepare um roteiro com pequenas iterações. Cada iteração deve conter tempo para execução, descrição, quantidade de recursos necessários para melhoria, valor técnico e valor para os negócios.

Concluímos a avaliação da arquitetura e fornecemos ao cliente um relatório

Nunca basta enviar um relatório por correio. Pode ou não pode ser lido ou lido e não entendido sem uma explicação adequada. Em resumo, a comunicação ao vivo ajuda a eliminar mal-entendidos entre as pessoas. Você deve marcar uma reunião com o cliente e conversar sobre os problemas encontrados, concentrando-se nos mais significativos. Vale a pena prestar atenção ao cliente para problemas sobre os quais ele pode nem suspeitar. Como problemas de segurança e explique como eles podem afetar um negócio. Mostre seu roteiro com melhorias e discuta diferentes opções que são mais adequadas para o cliente. Pode ser tempo, recursos, quantidade de trabalho.

Como um resumo do seu rally, envie seu relatório ao cliente.

Finalmente

Avaliar a arquitetura é um processo complexo. Para realizar uma avaliação corretamente, você precisa ter experiência e conhecimento suficientes.

É real - fornecer ao cliente resultados úteis para ele e seus negócios em apenas uma semana. Mesmo se você fizer isso sozinho.

Com base na minha experiência, muitas melhorias foram baixadas no meio e às vezes nunca começaram. Aqueles que escolheram um meio termo para si mesmos e fizeram apenas parte das melhorias mais úteis para os negócios com o mínimo de mão-de-obra, melhoraram significativamente a qualidade de seus produtos. Aqueles que não fizeram nada depois de alguns anos podem fechar o projeto completamente.

Seu objetivo é mostrar ao cliente a melhoria máxima pelo menor preço.

Outros artigos da seção de arquitetura podem ser lidos à vontade.

Desejo a você um código limpo e boas soluções arquitetônicas.

Nosso grupo no Facebook é Arquitetura e Desenvolvimento de Software .

Como ler e corrigir 100.000 linhas de código por semana