Ou arte de se pesar as escolhas em prol do benefício comum

Créditos: http://squoodles.co.nz/products/3-little-pigs-finger-puppets-set-of-8/

Você certamente não construiria um bangalô na praia com toras de madeira, da mesma forma que não utilizaria um telhado de palha em sua cabana nos Alpes. Isso porque aprendeu, desde pequeno, que há arquiteturas que se adaptam melhor a fins específicos. Afinal, se o objetivo for construir uma casa sólida e proteger-se do Lobo Mau, a escolha mais sábia parece ser mesmo a boa e velha alvenaria.

Com desenvolvimento é "quase" a mesma coisa. A diferença é que a opção default nem sempre é a melhor uma vez que padrões e tecnologias evoluem a uma grande velocidade e, aquilo que parecia uma ótima ideia hoje, pode não ser tão bom amanhã. Mas se o cenário muda tão rápido, por que se preocupar com isso? Justamente porque decisões de arquitetura são aquelas que mais impactam o desenvolvimento de qualquer software, uma vez que tendem a ter consequências de longo prazo. Para permanecer no mesmo campo comparativo, "não é fácil trocar a coluna depois que o arco já está em pé".

Antes de começar qualquer projeto, considero um ato de prudência estudar bem quais são as alternativas e tecnologias disponíveis para tornar o caminho o mais curto e menos acidentado possível. É certo que todo desenvolvedor ou time possui a sua "caixa de ferramentas" padrão com, por exemplo, bancos de dados, linguagens, frameworks, bibliotecas e suítes de testes que já estão habituados a trabalhar.

O "hipster" corre o risco de apostar demais em algo que pode "ir por terra" antes do esperado. Já o conservador, por outro lado, obriga todos a percorrer um caminho longo e tortuoso quando outro mais curto e simples levaria ao mesmo ponto. Nem sempre é possível antever todos os possíveis desdobramentos, contudo, analisar tendências faz parte do processo.

O desafio do arquiteto de sistemas é justamente pesar as alternativas disponíveis para encontrar a razão perfeita entre o tempo e o esforço necessários para se introduzir algo novo em relação aos benefícios que a introdução desta nova tecnologia trará ao projeto. Quando os potenciais benefícios forem superiores, é hora de arriscar. E é tentando algo novo que se gera aprendizado.

Pergunte a si mesmo uma série de questões: as tecnologias escolhidas estão alinhadas às necessidades do sistema? Que futuro elas terão? A performance possível dará conta da demanda? Qual o custo e a dificuldade para que o time de operações mantenha a aplicação rodando a partir das escolhas feitas? É fácil recrutar novos desenvolvedores para garantir crescimento? A manutenção do código e o tempo de desenvolvimento de novas features é compatível com as necessidades do sistema e de seus usuários?

Calcular custo-benefício pode parecer uma tarefa fácil, mas não se trata de algo trivial. Cerque-se do máximo de informações possíveis a fim de garantir que o desenvolvimento se dê sobre uma fundação sólida. Para tal fim, conhecer o terreno é tão importante quanto escolher o material de construção. Caso contrário, corre-se o risco de ver o prédio tremer já nos primeiros andares.

Publicado originalmente na coluna Post do Kemel na Revista Locaweb #56