O artigo de hoje aborda o conceito do livro “Arquitetura Limpa”, de Robert C. Martin, contendo frases escritas por Robert e algumas anotações minhas. O objetivo é fixar os conceitos na minha mente e compartilhá-los com todos os envolvidos na programação.
Começamos com uma ideia de Robert, intitulada “Um conto de dois valores”. Todo sistema de software proporciona dois valores distintos aos stakeholders: comportamento e estrutura. Os desenvolvedores de software são responsáveis por garantir que ambos esses valores permaneçam elevados. Infelizmente, eles frequentemente focam em um e negligenciam o outro. Pior ainda, muitas vezes concentram-se no menor dos dois valores, deixando o sistema sem valor no final.
O primeiro valor do software é seu comportamento. Os programadores são contratados para fazer com que as máquinas se comportem de uma maneira que economize dinheiro ou traga benefícios para os stakeholders. Portanto, escrevem o código que faz as máquinas dos stakeholders satisfazerem esses requisitos. Muitos programadores acreditam que isso é tudo o que precisam fazer, que seu trabalho se resume a fazer a máquina implementar os requisitos e corrigir qualquer bug. Estão redondamente enganados por pensarem que essa é sua única responsabilidade.
O segundo valor do software está relacionado à palavra “software”, que é composta por “soft” (suave) e “ware”. Para cumprir esse propósito, o software deve ser suave, ou seja, fácil de mudar.
Essa diferença entre escopo e forma muitas vezes resulta em um aumento nos custos do desenvolvimento de software. É a razão pela qual os custos aumentam desproporcionalmente em relação ao tamanho das mudanças necessárias. É por isso que o primeiro ano de desenvolvimento é muito mais barato que o segundo, e o segundo ano é mais barato que o terceiro, pois o software se torna cada vez mais rígido e, consequentemente, mais caro de ser modificado. Cada novo pedido é mais difícil de se encaixar do que o anterior porque a forma do sistema não se alinha com a forma do pedido.
O problema, é claro, é a arquitetura do sistema. Quanto mais a arquitetura preferir uma forma à outra, mais difícil será encaixar os novos recursos nessa estrutura.
Agora, a pergunta: função ou arquitetura, qual desses dois fornece o maior valor? É mais importante que o sistema de software funcione ou que seja fácil de mudar? Talvez você já tenha uma ideia da resposta com base no que foi escrito até agora.
Se você perguntar aos gerentes de negócios, a resposta para a segunda pergunta será que é mais importante que os sistemas de software funcionem. Os desenvolvedores, por sua vez, muitas vezes concordam com essa atitude. Mas é a resposta errada, como é provado com uma simples ferramenta lógica de examinar os extremos.
Se você me der um programa que funcione perfeitamente, mas seja impossível de mudar, então ele não funcionará quando as exigências mudarem e não poderei torná-lo funcional, tornando-o, portanto, inútil. Se você me der um programa que não funcione, mas seja fácil de mudar, então eu posso torná-lo funcional e mantê-lo funcionando à medida que as exigências mudarem. Portanto, o programa permanecerá continuamente útil. Você pode não achar esse argumento convincente. Afinal, não existe um programa impossível de mudar, mas existem sistemas praticamente impossíveis de mudar porque o custo da mudança excede seu benefício. Essa analogia é extrema e mostra que, a longo prazo, o sistema bem arquitetado sempre será mais lucrativo para todos.
Os gerentes de negócios não estão equipados para avaliar a importância da arquitetura. É para isso que os desenvolvedores de software são contratados. Portanto, é responsabilidade da equipe de desenvolvimento de software garantir a importância da arquitetura sobre a urgência dos recursos.