Desenvolvimento

17 set, 2012

Arquitetura de software?

Publicidade

Introdução

O desenvolvimento de software é uma dessas atividades que estão associadas ao conceito de arquitetura. Portanto, temos arquitetos de software que trabalham na arquitetura de software para o projeto, aplicação, sistema, ou qualquer outra coisa. Mas, pessoalmente, acho que a arquitetura de software é um equívoco, um paradoxo, uma ilusão, um desejo ou uma mentira, dependendo de quem a expressa em um determinado contexto. Em qualquer caso, estou muito convencido de que a associação entre software e arquitetura é incorreta.

Arquitetura do futebol

Vou tentar explicar o meu ponto de vista, começando com um desvio para o mundo dos esportes. Se você der uma olhada nos esportes, como o futebol, é possível ver que cada equipe tem um objetivo que deseja atingir, que vai desde ganhar a competição (seja ela qual for) a não ser rebaixado. Além da temporada, há sempre o próximo jogo, para o qual  o treinador tenta preparar a equipe, a partir de uma comparação dos pontos fortes e fracos da equipe e do adversário.

O futebol possui estratégias. Alguns times jogam no estilo “chutar e correr”, enquanto outros preferem prender a bola. Alguns times se preocupam com a bola, enquanto outros se preocupam com a defesa forte combinada com marcadores afiados (para um exemplo notável, clique aqui). O futebol possui táticas como jogadas ensaiadas (clique aqui para um bom exemplo), que podem realmente mudar o curso do jogo. O futebol possui o elemento sorte: há coisas que funcionam melhor do que o previsto, embora às vezes a bola só esteja contra você.

Habilidade também está envolvida (uma manifestação de Zlatan) e há muitos jogadores e treinadores que possuem uma visão de como o jogo deve ser jogado e que certamente sabem o que estão fazendo e por que eles fazem isso.

Agora, permita-me fazer a seguinte pergunta: um jogo de futebol tem arquitetura? Tenho certeza de que sua resposta seria “claro que não”. Então por que o software tem arquitetura?

Arquitetura?

Na verdade, o que é arquitetura? Ela deriva do grego “ἀρχι τέκτων” que significa “mestre de obras”. Então, arquitetura remete tanto ao que o mestre de obras faz (processo) e ao resultado de seus esforços (artefato). De alguma forma, em algum lugar, função e semântica mudaram um pouco e, nos dias de hoje, o arquiteto realmente não constrói mais, e a arquitetura refere-se à atividade de projetar uma estrutura.

Portanto, se a arquitetura lida com o projeto de estrutura, então o que é a estrutura? Ela é que o que revela a carga. No contexto de uma construção, é o conjunto de vigas, colunas, molduras, escoras e outros elementos estruturais, juntamente com a sua configuração espacial. É a única coisa que, uma vez construída, não mudará mais, porque você teria que começar tudo de novo. Se você iniciar uma pesquisa para a estrutura de software, vai descobrir que não há ou, pelo menos, que não deve haver uma.

Ao trabalhar em um projeto/produto de software, você tem que fazer escolhas e, às vezes, pode até ver uma solução muito boa para o atual conjunto de requisitos. O problema é que você sabe que esses requisitos mudarão em algum momento no futuro, e que a sua solução ideal será muito dispendiosa para mudar. Então você aplica o estratagema “design for change”, e escolhe deliberadamente ignorar a solução que faz produzir o melhor ajuste às necessidades, mas escolhe o que implicará custos mais baixos para a futura mudança de direção.

Basicamente, você está tentando evitar que o software assuma uma certa estrutura. Você está fazendo o oposto da arquitetura. O que quero quero dizer é que acho que a metáfora está errada.

Acho que a melhor metáfora é considerar o desenvolvimento de software como um jogo de estratégia em tempo real jogado contra o universo. Esse jogo envolve estratégia, tática e sorte, mas não envolve arquitetura.

Estratégia

Há certamente um aspecto estratégico no desenvolvimento de software. Ele só não recebe muita atenção e, se isso acontecer, geralmente é em uma linguagem excessivamente simplificada com slogans como “Design for change” ou “KISS!” ou “Separation of concerns”. De fato, quando a estratégia é considerada como sendo um conceito relevante no contexto do desenvolvimento de software, é quase sempre vista em relação à parte do processo, e nunca para a parte de codificação diretamente.

Algumas das escolhas estratégicas que causam grande impacto na chance de sucesso para um projeto/produto, como o  ecossistema de desenvolvimento, paradigma de programação, linguagem de programação quase nunca são feitas. No entanto, as escolhas feitas são igualmente importantes.

Por exemplo, Ken Thompson fez uma das escolhas mais bem sucedidas de NÃO escrever, o que acabaria por se tornar Unix, em linguagem assembly. Muita gente disse que ele era louco, e que nunca seria rápido o suficiente. Ele não foi dissuadido.

Uma das piores escolhas foi feita por uma empresa (que não vou citar) na qual trabalhei no passado. Estávamos construindo um aplicativo comercial para o usuário final em Java para OSX. O raciocínio era mais ou menos assim:

  • Os usuários do Linux não pagarão por software, e os usuários do Windows não estão dispostos também, enquanto usuários de Mac têm uma carteira aberta.
  • Java é uma excelente escolha tanto para o cliente quanto para o desenvolvimento do lado do servidor, e o OSX é uma boa plataforma Java.

Ambos os argumentos eram justificáveis, mas, na época, 90% dos usuários finais estavam no Windows, por isso, se você atingir uma comunidade com um produto que vai chegar apenas para uma porcentagem deles, é melhor que seja uma grande comunidade, e não uma marginal.

A escolha pelo Java foi bastante infeliz, mas, na época, eles ainda acreditavam na promessa da Apple para fazer do OS X a melhor plataforma Java no planeta. Mais tarde, tornou-se dolorosamente óbvio que a Apple mudou de ideia.

Em retrospecto, ela deveria ter sido feito em alguma linguagem. Net no Windows, mas o retrospecto é 20/20.

Táticas de software

O desenvolvimento de software possui táticas também. A famosa história de M. Abrash em Zen of Graphics Programming é assim:

Anos atrás, eu trabalhava em uma empresa que me pediu para escrever um código incrivelmente rápido para desenhar linhas para um driver AutoCAD. Eu implementei o algoritmo básico Bresenham para desenhar linhas; simplifiquei tanto quanto possível; special-case horizontal, diagonal e vertical; quebrei os separadores, rotinas otimizadas para linhas em cada octante, e maciçamente desenrolei os loops. Quando terminei, uu tinha uma linha desenhada com meras 5 ou 6 instruções por pixel, e entreguei o código para a pessoa do driver AutoCAD, sabendo que eu havia levado aos limites teóricos o algoritmo de Bresenham na arquitetura 80×86, e que isso era tão rápido quando um PC poderia desenhar uma linha. Essa sensação durou cerca de uma semana, até que Dave Miller, que hoje em dia é um Windows Display-driver Whiz na Engenius Solutions, casualmente mencionou um algoritmo de desenho mais rápido que o de Bresenham.

Aprendi duas dicas de segurança importantes da minha experiência com linha desenhada.

Primeiro, nunca, nunca, nunca pense que você escreveu o código mais rápido possível. Execute o seu código após outro bom programador, e ele ou ela provavelmente irá dizer: “Mas por que você não faz isso?” Você vai perceber que poderia realmente fazer isso, e seu código, então, seria mais rápido. Ou relaxe e volte ao seu código mais tarde, e você pode muito bem ver outra abordagem, mais rápida. Há um milhão de maneiras de implementar um código para qualquer tarefa, e você pode quase sempre encontrar uma maneira mais rápida se precisar.

Em segundo, quando o desempenho importa, nunca faça com que o seu código execute o mesmo cálculo mais de uma vez. Isso parece óbvio, mas é surpreendente como muitas vezes é ignorado.

(A propósito, desde então descobri exemplos que contradizem sua segunda regra)

Um algoritmo melhorado para um problema padrão pode de repente fazer uma vasta gama de aplicações viáveis que  antes eram consideradas dispendiosas demais para o hardware atual.

Pura sorte

Nihil sine Strategiam et fortuna omnibus vincit.

É difícil encontrar exemplos de sorte no desenvolvimento de software, já que a maioria das pessoas que está sendo assistida por ele tem a tendência de disfarçá-lo como um golpe de mestre. Não há nada de errado com estar acidentalmente no lugar certo na hora certa, e depois tirar vantagem disso. De qualquer forma, na ciência, muitas vezes eles usam o conceito de acaso para explicar coincidências felizes.

Últimas palavras

Eu deveria encerrar, pois isso está parecendo cada vez mais com um ensaio em vez de com um artigo.

Não entenda errado este discurso enfadonho. Não estou dizendo que você não deve planejar com antecedência ou pensar bem antes de começar a codar.

Só estou avisando que, se você começar a criar uma arquitetura de software, provavelmente vai acabar tendo uma. Ou, como a famosa frase diz:

Há dois tipos de pessoas infelizes: aquelas que não conseguiram o que queriam, e aquelas que conseguiram!

Divirta-se.

***

Texto original disponível em http://blog.incubaid.com/2011/11/15/software-architecture/