Simplicidade

Eu aprendo muito com meus amigos.

Quase 3 anos atrás, um amigo meu me apresentou uma das metodologias (eu prefiro chamá-las de filosofias) ágeis de desenvolvimento de software, Extreme Programming ou "XP". Como tudo nela fazia muito sentido pra mim (eu desenvolvo software profissionalmente há mais de uma década e tenho cicatrizes por todo o corpo para provar isso), me tornei um proponente e defensor dela a ponto de explicá-la numa Comdex, mesmo nunca tendo aplicado completamente. Ouço que o pessoal desse meu amigo desenvolve um dos seus produtos usando XP. Isso é bom.

Um dos pilares (há pelo menos 12) do XP é a simplicidade.

E isso faz muito sentido, principalmente no meu ramo.

É muito fácil se deixar seduzir pelos modismos do mercado de software. É quase certo que usar as siglas XML, SOAP, .net (que eu chamo de dot-not), J2EE e outras tantas valoriza seu sistema aos olhos de muitos pointy-haired-bosses. É mais sério do que isso: esses modismos ditam que profissionais serão contratados. Saber Java hoje é essencial.

O problema mora em se deixar seduzir facilmente.

O XP (e o bom-senso, antes dele) recomenda que, ao implementar uma solução, você a implemente da forma mais simples que resolver o problema. Qualquer complexidade adicional virá ao seu encalço depois. Virá na forma de maiores dificuldades para localizar bugs e acrescentar funções, mais tempo de manutenção e maior custo de propriedade e, ao final, uma vida útil mais curta para o sistema (quando os custos de mantê-lo excedem os benefícios de operá-lo). Tanto pior quanto mais vital for o produto para o cliente.

O Desastre

Nessas últimas semanas ando às voltas com um produto (uma aplicação web escrita em Java e JSP) que enfrenta muitos problemas (eu quase arriscaria dizer que ela é um paciente terminal) derivados da falta de simplicidade. O cliente e a aplicação permanecerão anônimos, para proteção dos inocentes que costumam ser decapitados quando más notícias assim chegam às gerências.

Parece ter havido uma ênfase enorme na interface sem, necessariamente, um estudo de usabilidade. Há degradées em botões, menus pull-down, fundos de tela fotográficos e, sendo essencialmente uma aplicação de workflow, nenhuma tela onde o usuário entre e descubra o que ele tem, exatamente, que fazer. Não existe o conceito de caixa de entrada.

Há também um extensivo uso de frames, que elimina a URL do browser como forma de orientação (eu não posso mandar um link com uma tela para um colega e, num bug-report, eu tenho que explicar passo a passo o que eu fiz para chegar lá, se eu conseguir). Esses frames são operados por scripts em JavaScript que os acionam para obter o comportamento de uma aplicação desktop, só que pela web, em HTML, JavaScript e Java.

O projeto deve ter estourado os prazos. As telas bonitas (de gosto duvidoso) devem ter sido mostradas no início do projeto, o responsável por elas deve ter sido louvado pela sua iniciativa e os gerentes acima dele devem ter ficado orgulhosos dos caminhos que a empresa estava trilhando. Com o tempo os programadores devem ter descoberto o quanto as telas bonitas estavam realmente atrapalhando, mas a notícia não subiu a hierarquia. Prazos estouraram e, no final, os sobreviventes entregaram um sistema sem documentação interna (documentação interna costuma ser a última coisa a ser feita).

Também no início do projeto, sentindo a falta do XML, a equipe (ou alguém dela) decidiu usar XMLDSO (uma tecnologia Microsoft para acessar dados em XML a partir do cliente) para povoar drop-lists. Esse approach tem, em si, vários problemas:

• Torna a depuração das páginas desnecessariamente complicada. Quando se identifica um bug na página, este pode estar no JSP que montou a página, no Java que ajudou o JSP a buscar dados no BD, no JSP que gerou o XML ou no JavaScript que montou tudo.
• Como a estrutura que o browser mostra foi gerada dinamicamente no próprio browser, o "view source" não serve para quase nada. Todos os dados importantes vieram de outro jeito, entraram diretamente no browser e não podem mais ser facilmente vistos.
• É uma solução Microsoft-only. Provavelmente um desktop Unix-like ou Macintosh ou até mesmo um PDA ou H/PC Windows CE não seriam capazes de mostrar as páginas corretamente. Se vamos nos limitar a desktops Windows, por que não fazer a aplicação logo em VB ou algo ainda mais simples?

Por coisas assim, manutenções que poderiam custar pouco custam muito. O TCO do sistema vai às nuvens e os seus usuários nunca estão satisfeitos porque as alterações pedidas levam meses para ficar prontas.

Mas os problemas não acabam por aí.

The Plot Thickens

Outro problema vem da combinação da falta de simplicidade com os prazos curtos. Há uma tendência em qualquer pessoa de abandonar boas práticas sob pressão. Programadores não são diferentes. Quando apertados, programadores começam a fazer experiências com o código. Começam a mudar uma coisa aqui ou alí para puxar uma ou outra informação sem realmente saber o que estão fazendo. Com isso, o grau de complexidade desnecessária aumenta a cada manutenção. Às vezes eu sou tentado a fazer isso. Quando isso acontece eu sei que é hora de uma pausa para um café.

Como se o próprio problema não fosse sério o suficiente, ele é consistentemente ignorado pelas gerências responsáveis. Ninguém comenta o problema. Têm-se a impressão de que a vida de um desenvolvedor de sistemas é assim mesmo. Funciona mais ou menos assim: Quando um problema é identificado e passado um nível hierárquico acima, espera-se que providências sejam tomadas. Como o gerente mediano detesta tomar providências sobre problemas já instalados (ser reativo, como diz o jargão do ramo), isso vai criando pontos de atrito no relacionamento. Existe uma tendência histórica de que os mensageiros que carregam más notícias correm mais risco de ser decapitados do que os que carregam boas notícias.

Esse último é um problema gerencial mais do que operacional. Não é necessário um Richard Feynman para descobrir que más notícias não sobem hierarquias com facilidade (ele apontou isso como uma das causas da perda do ônibus espacial Challenger). Isso é observável em qualquer empresa maior (eu chamo esses lugares de "ambientes dilbertizados"). É só observar alguns sinais como tiras do Dilbert nas paredes ou acesso ao domínio "dilbert.com" a partir da rede interna. Acho que com esse último dá até para medir precisamente um índice-dilbert para a companhia.

Como se resolve?

Há três problemas aí. Um estritamente técnico, um estritamente gerencial e um problema social. Os dois últimos merecem um artigo só para eles. Falarei do primeiro.

A Natureza da Besta

O problema técnico é, de todos, o mais simples de resolver: Enfatizar a simplicidade. O mesmo amigo que me apresentou XP me ensinou que algumas coisas se aprende errando. Outras coisas, como desenvolver software, só se aprende acertando. Crie um projeto e o mantenha simples. Simples não quer dizer feio.

O importante aqui é estabelecer fronteiras nítidas entre armazenagem, apresentação e funcionalidade (pense em Model, View e Controller).

Pensando assim, você vai evitar colocar funcionalidade na camada de apresentação (dica - aquela que vira HTML e vai pro browser). Vai evitar codificar suas regras de negócio na forma de triggers no banco de dados. Fazer essas duas coisas vão te dar uma vantagem inestimável: testabilidade.

Outro pilar do XP é a idéia de que você deve testar sempre. Se você imaginou ter uma equipe de testadores, está no caminho errado. Tome um café, pense, e volte ao texto em 5 minutos.

Teste bom é teste automatizado. Testes que podem ser repetidos com absoluta confiabilidade e precisão. Testes que cobrem todas as funcionalidades. Testes que exercitem tudo o que possa, concebivelmente, falhar.

É difícil testar automaticamente o HTML. É pouca coisa menos difícil testar a lógica de negócios quando ela mora no BD. É fácil testar suas classes (sejam elas em Java, Python, C# ou Smalltalk). Se é difícil testar, como se contorna isso? Simples: deixe toda a complexidade onde for mais fácil testar. Se for uma aplicação em 2 camadas, com PHP acessando um Oracle, talvez seja sensato escrever sua lógica em PL/SQL por ser mais fácil testá-la do que em PHP. O importante é ter esses testes. De posse dos testes, um programador pode implementar uma alteração e ter certeza de que ele não consertou uma coisa quebrando outra.

Os testes potencializam a simplicidade. Algo simples e testável acaba se tornando algo simples e confiável.

Beleza e Elegância

Ao buscar a simplicidade você está indo ao cerne do problema que você se propôs a resolver e fechando os olhos e ouvidos para o ruído à sua volta. Há beleza e elegância na simplicidade. Se você se deixar sensibilizar por ela e aprender a sentir seu caminho se pautando por ela, terá conseguido para si uma ferramenta muito valiosa. Ao fazer seu trabalho, você estará trazendo para a luz e expressando essa beleza e elegância que estavam ocultas dentro do problema.

Terá aprendido que programar não é apenas uma atividade mecânica e sim uma forma de expressão.

Nunca esqueça: Seu trabalho não estará pronto quando não houver mais nada a acrescentar. Estará perfeito quando não houver mais nada a ser retirado.

© Ricardo Bánffy