Blog Gonow

*Por Flávio Gomes da Silva Lisboa

Em 2009, Richard Monson-Haefel editou um livro chamado “97 Things Every Software Architect Should Know” (97 coisas que todo arquiteto de software deveria saber). Richard é, entre outras coisas, arquiteto de software. Esse livro não é um compêndio sobre suas próprias ideias, mas uma reunião de artigos de vários arquitetos de software, os quais tratam sobre conclusões a que chegaram por experiência própria. O primeiro artigo é de autoria de Nitin Borwankar. Nitin é um profissional de banco dados com vinte anos de experiência na indústria. Ele trabalhou com Sybase e Ingres (no qual foi baseado o PostgreSQL) e atualmente trabalha com CouchDB.

O título do artigo de Nitin é “Não ponha seu currículo à frente dos requisitos”. Nesse artigo, ele discute um problema grave que ocorre no mundo da Tecnologia da Informação. Infelizmente tenho que confessar que, em relação a isso, sou testemunha ocular dos fatos, embora não seja o Repórter Esso. Se você não entendeu a referência, pode estar cometendo o mesmo erro que Nitin aponta. Nunca menospreze o passado, porque é dele que tiramos as lições que, aplicadas ao presente, garantem um bom futuro. O artigo diz que, às vezes, os engenheiros de software não recomendam tecnologias, metodologias e abordagens para solucionar problemas porque elas são as melhores, mas simplesmente porque querem que elas estejam em seu currículo. Eu já vi isso! Já vi equipes decidirem por uma tecnologia não para atender ao cliente, mas porque eles queriam aprendê-la! Um projeto de software termina por se tornar uma desculpa para  um curso de aperfeiçoamento. E isso pode não acabar bem!

Não que eu seja contra o aprimoramento dos profissionais. Muito pelo contrário. Precisamos estar sempre atentos à evolução das tecnologias, mas isso não significa ter que usar a versão mais recente do software “X” simplesmente porque ela está disponível. Temos de atender à necessidade do cliente. Mais importante do que utilizar o último paradigma de computação, é pensar em uma estrutura que seja fácil de manter. A pergunta não deve ser se isso é o mais novo, mas sim se isso é o mais adequado. Se você utilizar a tecnologia certa para um projeto, e não a que você gosta, com uma arquitetura bem feita, tenha certeza de que terá tempo para estudar as coisas que gosta, e encontrará espaço para aplicá-las no momento adequado.

Arquitetura de software não pode ser confundida com a produção estética de certas construções, na qual o atendimento ao usuário fica em segundo plano. Talvez por nos acostumarmos com erros na arquitetura tradicional dos produtos tangíveis, os transportemos para o mundo do software. Irei agora fazer uma rápida viagem ao mundo real para tentar deixar claro um problema do mundo do software.As cidades do Brasil, pelo menos as capitais, tem um sério problema em comum: o desprezo pelo pedestre. Diga-me, com sinceridade, se você consegue andar a pé tranquilamente de uma ponta a outra da capital de seu estado. Quando digo, tranquilamente, considero a existência de semáforos para pedestres e passarelas que te permitam cruzar todas as vias sem ter de correr desesperadamente para fugir dos carros ou dar voltas imensas para chegar a um lugar. Certamente sua resposta é não. Por quê? Por um erro arquitetural da urbanização das cidades, que privilegia o carro. E, por esse mesmo motivo, fica difícil tirar o carro da rua, se tudo acaba funcionando para quem tem carro, forçando quem não tem a adquirir um.

Claro que esse não é o único motivo para forçar o aumento da frota de carros, porque ninguém quer cruzar a cidade inteira a pé. O fator preponderante é a falta de transporte público de qualidade. Se o cidadão não consegue chegar na hora em seu trabalho, ou já chega exausto de ter sido espremido e empurrado nos ônibus e trens, ele vai desesperadamente adquirir um veículo, mesmo enfrentando dificuldades de mantê-lo. Tudo isso advém de um erro de planejamento. Quando o governo optou por investir no transporte rodoviário individual, ele condenou várias gerações a um problema grave. Agora, a solução que era adequada naquela época torna-se quase inviável, a saber, o investimento em transporte coletivo ferroviário. Na Rússia você consegue atravessar o país de trem, sem ter suas pernas esmagadas. Aqui temos de escolher entre o mais caro e o mais cansativo, mas ambos compartilhando o esmagamento de pernas.

Pois bem, você quer que seu software crie um problema similar? Que você não durma à noite, que não tenha final de semana, que não chegue cedo em casa? É fácil, basta tomar uma decisão que lhe agrade, ou tomar a decisão certa. Em tecnologia, é preciso tomar cuidado, para não utilizar canhões para matar moscas, e terminar derrubando a parede. Escolha a tecnologia que resolve o problema. E guie-se pelo princípio de que a melhor solução é a mais simples. Vou terminar este artigo recontando uma lenda que palestrantes adoram. Uma fábrica estava com problemas em sua linha de produção. Às vezes, algumas caixas escapavam do braço mecânico que colocava o produto e ia vazia para a distribuição. Isso gerava problemas quando o erro só era percebido pelo cliente, ao abrir a caixa. A diretoria se reuniu, contratou uma consultoria e instalaram um sistema que parava todas as caixas em uma balança. Se o peso indicasse que ela estava vazia, um braço mecânico a retirava da esteira. Isso resolveu o problema, mas diminuiu a velocidade da linha de produção.

A diretoria ficou preocupada, e no final do mês foi verificar qual teria sido a queda de produtividade para pensar nas próximas ações. Qual não foi a surpresa ao verem que a produtividade se manteve. Resolveram visitar a linha de produção e descobriram que a balança e o robô dispensador estavam desligados, e a esteira funcionava como antes. E os funcionários avisaram que o robô só havia funcionado no primeiro dia. O mais intrigante é que não houve mais problemas de caixas vazias. A diretoria perguntou por que eles desligaram o sistema que custou os olhos da cara à empresa. Os funcionários explicaram que aquele processo demorava muito e eles não tinham como atingir as metas. Então eles simplesmente colocaram um ventilador ao lado da esteira. Se uma caixa vazia passasse, ela caía do outro lado.
Tome cuidado a partir de hoje, para não propor soluções megalomaníacas e nem deixar que outros as implementem!
–

*Flávio Gomes da Silva Lisboa é consultor e instrutor Java, PHP e Python. É autor dos livros “Zend Framework: Desenvolvendo em PHP 5 Orientado a Objetos com MVC“, “Zend Framework: Componentes Poderosos para PHP” e “Criando Aplicações PHP com Zend e Dojo“, entre outros. Atualmente trabalha na Coordenação Estratégica de Tecnologia do Serpro.

Tags:Arquitetura de Software, Flávio Gomes da Silva Lisboa, gonow tecnologia, Nitin Borwankar, Richard Monson-Haefel

Categorias: Agile