Escolhendo tecnologias: a beleza e a armadilha da besta

Arquitetura de software revelada: uma série de Igor Fraga oi pessoal, Igor Fraga aqui. Este é o quarto artigo dessas séries para revelar os desafios e o papel do que fazemos como arquiteto de software. Como arquiteto, um dos meus trabalhos mais importantes é escolher a tecnologia. É também um dos trabalhos mais perigosos. Sempre vemos ferramentas novas e emocionantes que prometem ser rápidas e maravilhosas. Eu chamo essas ferramentas de beleza. Mas também temos ferramentas antigas e confiáveis ​​que sabemos que funcionarão. Eles podem não ser emocionantes, mas são fortes. Eu chamo isso de besta. É um grande erro escolher a beleza e esquecer a besta. Eu sei disso porque já vi esse erro ter acontecido várias vezes, também em um projeto com uma equipe muito boa. Aqui está o que aconteceu. A história: o sonho de um sistema super-rápido, há alguns anos, uma empresa chamada X (não vou revelar o nome aqui, é claro) precisava de um novo sistema para lidar com muitos eventos de milhares de usuários em todo o mundo, integrando suas plataformas que até então foram separadas. O objetivo era processar esses eventos muito rapidamente, com muito pouco atraso. Nossa equipe era inteligente e experiente, mas o arquiteto achou que um sistema Java reativo era a melhor maneira de fazer isso. A beleza que ele queria que usássemos era uma tecnologia chamada Project Reactor e Spring Webflux. Prometia coisas incríveis: não era bloqueador. Isso significa que poderia lidar com muitas tarefas ao mesmo tempo sem esperar. Seria muito mais rápido que os sistemas antigos. Usou menos recursos. Isso poderia gerenciar milhares de conexões com apenas alguns threads. A maneira antiga precisava de um thread para cada conexão. O código estava limpo. Era uma maneira moderna e simples de escrever código complexo. A outra escolha foi a besta que conhecíamos muito bem: o clássico MVC da primavera. Usamos isso para muitos de nossos outros sistemas. Era forte e toda a nossa equipe entendeu. A equipe era meio cética em usar o reativo, mas o arquiteto insistiu em dizer que era a única maneira de ser rápido o suficiente. Eu estava preocupado que seria difícil aprender e manter, mas tudo, se esse paradigma fosse realmente necessário dentro de um arranjo praticamente todo legado. Mas não tínhamos escolha e ele não ouviu ninguém, ele acabou de sair com um esqueleto do serviço, para que devemos trabalhar acima disso. Então, vamos construir o sistema moderno e super-rápido. Os problemas começam: quando o sonho se torna difícil, construímos um pequeno sistema de teste e foi muito rápido. Ficamos felizes e pensamos que fizemos a escolha certa. Apesar da curva de aprendizado e da mudança completa do paradigma de codificação, conseguimos fazer isso de alguma forma. Mas então, começamos a construir o sistema real de produção. Foi quando os problemas começaram. A depuração foi um pesadelo. O código foi feito de cadeias muito longas de operadores. Quando houve um erro, a mensagem de erro era muito difícil de entender. Era difícil ver onde o problema aconteceu. Outras ferramentas não funcionaram bem com isso. Utilizamos muitas outras ferramentas para coisas como segurança e dados. Descobrimos que essas ferramentas não eram reativas. Eles estavam bloqueando. Quando os usamos, eles quebraram o design não bloqueador do nosso novo sistema. Havia novos tipos de insetos. Tivemos problemas muito difíceis de encontrar. Por exemplo, o sistema usaria lentamente cada vez mais memória e depois falharia. Não sabíamos o porquê. Nossa equipe parou de criar novos recursos. Em vez disso, eles passaram o tempo todo tentando corrigir esses novos e difíceis problemas. O belo código não bloqueador super-rápido que queríamos agora estava cheio de correções complexas e estávamos perdendo nossos cabelos. Não estou dizendo que a programação reativa é ruim e deve ser evitada ou que não funciona. O que estou dizendo que, neste caso, nunca fez sentido. Foi um pesadelo real sem nenhum benefício comercial real para este projeto em particular. A solução: uma lista de verificação para nos ajudar a escolher melhor essa experiência ruim me ensinou uma lição importante. Agora, quando estou escolhendo a pilha de tecnologia, uso uma estrutura simples para me ajudar a escolher novas tecnologias. Não é para parar novas idéias. É para garantir que escolhemos novas idéias de uma maneira inteligente que faça sentido para cada propósito. Lista de verificação de tecnologia 1. Está pronto e estável? Versão: é uma versão estável (como 1,0 ou superior)? As primeiras versões podem mudar de repente. Tomemos, por exemplo, as mudanças disruptivas da primavera AI M5 (Release Milestone) para o lançamento público final de 1.0.0 GA. Habilidades da equipe: nossa equipe já sabe como usar isso? Ou é completamente novo para todos? Considere especialmente o cronograma e a hora disponível ao analisar isso. Comunidade: Existe uma grande comunidade de usuários? Uma boa comunidade ajuda a corrigir bugs e responder a perguntas. 2. Funciona com nossas outras ferramentas? Compatibilidade: nossas outras ferramentas importantes funcionam bem com esta nova tecnologia? Integração: é fácil se conectar com nossos sistemas para monitoramento, segurança e implantação? 3. É fácil aprender? Boa documentação: existe uma documentação clara com bons exemplos? Isso explica problemas comuns? Tempo de aprendizado: quanto tempo levará para nossa equipe aprenderem bem? 4. É a escolha certa para o nosso projeto? Bom ajuste: esta tecnologia é uma boa solução para o nosso problema específico? Ou apenas achamos legal? Teste pequeno: podemos construir um pequeno projeto de teste primeiro? Este teste deve verificar as partes mais arriscadas. Plano de backup: se não funcionar, é fácil mudar para uma tecnologia diferente? Como você pode decidir hoje, ao pensar em uma nova tecnologia, siga três etapas simples: use a lista de verificação: a equipe preenche a lista de verificação. Construa um pequeno teste: construindo um pequeno projeto de teste para verificar as peças mais perigosas. Anote a decisão: escreva por que a equipe o escolheu (arquiteto e desenvolvedores, juntos), quais são os riscos e como eles serão gerenciados. Pensamento final A escolha da tecnologia é sobre o gerenciamento de riscos. A beleza de novas ferramentas é emocionante, mas elas podem ser imaturas e arriscadas. A besta das ferramentas antigas é previsível e segura. Um bom arquiteto entende os dois. Eles sabem que o mais importante é que um sistema funcione bem e a equipe possa mantê -lo. No próximo artigo, falaremos sobre como projetar sistemas que podem mudar facilmente, como construir com blocos de Lego. Vejo você então!

Fonte