Arquivo de junho \21\UTC 2007

Bolas de chumbo

Você já deve ter visto muita gente copiar e colar código deliberadamente quando um pouco de senso crítico e abstração resolveriam facilmente o problema. Eu sei que eu já vi e o argumento para tamanha aberração tem sido sempre parecido: “Cara, eu e você sabemos que é melhor extraírmos o comportamento comum deste outro modo e que dá para enxugar o código desse outro jeito. Mas infelizmente não somos só nós dois que vamos trabalhar neste sistema. Acho que desse modo repetitivo fica mais fácil para o restante do pessoal que não é tão brilhante quanto a gente. Além disso, precisamos preparar a aplicação para ser mantida por qualquer tipo de idiota que a empresa resolva contratar no futuro.”

A idéia é bastante simples e, de um certo ponto de vista, parece até lógica: eliminar todo tipo de conceito que uma pessoa com uma semana de treinamento não vá entender. Assim é possível maximizar a quantidade de código que elas serão capazes de produzir, pois não vai ser preciso parar para aprender esses tais padrões de projeto e demais conceitos abstratos complicados que os concorrentes tanto usam. Pessoas pouco treinadas têm a tremenda vantagem de serem baratas. Deste modo, pode-se pagar bem pouco para cada programador e amontoar tantos quanto possível em grandes fazendas de cubículos para vomitar código repetido à maior velocidade possível. A maioria do código não vai servir para muita coisa, mas como a quantidade de gente à disposição é bem elevada, com um pouco de sorte dá até para produzir algo que o departamento de vendas consiga vender como útil. Quando nosso esquema estiver funcionando, podemos dizer que é uma “fábrica” e achar tudo muito bonito.

Eliminar todo tipo de conceito abstrato para permitir que qualquer pessoa com um mínimo de instrução possa trabalhar no sistema pode até parecer racional. Esse tipo de argumento é muitas vezes invocado em nome de algo que se chama de “pragmatismo”. Esta palavra está na muito na moda recentemente e, como toda boa palavra da moda, não são raras as vezes que é invocada do limbo apenas para defender uma idéia falida. O fato é que, sendo pragmatismo ou não, estas iniciativas servem muito bem ao intuito de nivelar a capacidade da equipe.

Por baixo.

Ao invés dos programadores mais versados na arte da escrita de código serem encorajados a passar seu conhecimento aos demais, eles são obrigados a correr com uma bola de chumbo amarrada aos pés para não ultrapassarem os outros. Eles perdem toda a energia que o design elaborado os proporcionava para que os demais possam continuar lentamente. Não gosto nem de imaginar o que isso pode fazer com a auto-estima deles e, conseqüentemente, com o futuro do projeto.

Em dois artigos recentes, Vitor Pamplona argumenta contra a busca do Santo Graal da Orientação a Objeto e preciso dizer que este argumento me parece bastante razoável. Mas como todo bom argumento ele pode ser interpretado de forma extrema e levar uma equipe a abominar completamente os objetos e padrões de projeto. Eles podem passar a considerá-los simples mecanismos para tornar uma aplicação mais difícil de entender. Apenas uma tentativa patética por parte dos mais escolados de manter a equipe dependente de seu conhecimento.

Esta opinião extrema parte do pressuposto falho que objetos e padrões são mais complicados do que código seqüencial, repetido e bagunçado em geral. Aqui é onde encontramos o principal ponto de discordância entre os que defendem o código elegante e os que estão do lado da bagunça compreensível. Ambos defendem que o seu estilo é mais legível. Os últimos simplesmente por empregar conceitos mais simples e os primeiros por dedicarem mais tempo aos aspectos estéticos do código.

Código que não é legível não é elegante. Se for preciso vagar por toda a base de código para entender a idéia geral de uma única linha, não importa a densidade de padrões de projeto por metro quadrado: o código é deselegante. Por outro lado, se preciso consertar um defeito sutil relacionado à mesma linha, espero que deva ser preciso dar uma olhada em uma quantidade razoável de código além dela. Mas quando estou apenas lendo, não.

Isso não quer dizer que código precise ser simplista para ser legível. Quando alguns conceitos um pouco mais elaborados são usados dentro de um contexto específico, podem tornar o código muito mais legível que a alternativa simplista. Tome como exemplo as interfaces fluentes. Muita gente ainda não ouviu falar delas, mas poucos fariam muito esforço para entender esta linha caso a encontrassem num teste:

mock.expects(once()).method("m").with("hello")

Apesar disso este pequeno trecho de código está fazendo uso de pelo menos um padrão de projeto (nominalmente o Builder) e de um estilo de código ao qual nem todo mundo foi formalmente apresentado (uma interface fluente). Este trecho é legível apesar de não ser nada que um novato escreveria. Ele funciona porque os conceitos são aplicados onde fazem sentido.

A encrenca começa a aparecer quando os garotos dos padrões entram em cena forçando soluções inadequadas para os problemas errados, fazendo de tudo para encaixar um cubo em um buraco com forma de círculo. Ou pior: quando eles começam a inventar problemas só para aplicarem suas soluções preferidas.

Alguém tem um Mac por aí?

Então parece que a Apple está preparando uma versão do seu navegador Safari para Windows. Parece também que o bicho está disponível como beta e, como tenho acesso a uma máquina Windows XP no trabalho, achei que não faria mal a ninguém testar o navegador que há algum tempo atrás era exclusividade de usuários Mac. Claro que o primeiro site que testei foi o do projeto Motiro e o resultado não foi muito animador:

Motiro no Safari 3 Beta em Windows XP

Os trechos de texto com alguma modificação de estilo (títulos, negrito, cores personalizadas) não foram exibidos e houve alguns problemas de perda de alinhamento em alguns elementos. Isso tornou o site totalmente inútil para qualquer pessoa com um mínimo de juízo (como não sou uma dessas pessoas, ainda tentei abrir algumas páginas da wiki e parece que os problemas continuam em todas as páginas).

Há algum tempo venho usando o BrowsrCamp.com para ver algumas fotos de como o Motiro aparece no Safari. Obviamente que ver fotos estáticas do seu site não é uma opção tão boa quanto vê-lo ao vivo, mas é melhor do que nada. A versão que eles usam não é este beta do Safari 3, mas um Safari 2 que presumo ser estável. Nele o Motiro aparece bem mais apresentável:

Motiro no Safari 2.0.4 em Mac OS X

Será que o Safari mudou tanto do 2 para o 3 que passou a renderizar sites de modo completamente diferente? Ou este é um comportamento apenas da versão Windows do Safari 3? Se alguém tiver um Mac por aí e puder fazer estes testes com o Motiro, eu agradeceria muito. Depois dessa estou pensando seriamente em concentrar os esforços completamente nos aspectos de compatibilidade com navegadores para o release 0.6.7.

Comunidade Eclipse lisonjeada

Parece que a Microsoft anunciou esta semana a nova versão do Visual Studio. Antigamente ele era um ambiente de desenvolvimento, mas agora parece que vai ser uma plataforma para várias aplicações. Pelo que pude encontrar de cobertura on-line, parece que agora eles querem produzir uma plataforma extensível para ferramentas de desenvolvimento. A idéia básica é usar o alicerce do Visual Studio para construir aplicações como plugins. Mais ou menos como o Eclipse vem fazendo desde os tempos memoráveis da versão 2.0, lá pelos idos de 2002. Qual será a próxima? Construir aplicativos de propósitos diversos sobre a plataforma Visual Studio? Algo como Eclipse RCP, que está disponível desde a versão 3.0 (que saiu mais ou menos em 2004)?

Ian Skerret, diretor de marketing da Fundação Eclipse está mais do que certo em afirmar que a cópia é a forma mais sincera de admiração. Todas as organizações e indivíduos que formam a comunidade de desenvolvedores da plataforma Eclipse devem estar lisonjeados. Afinal de contas quando os seus competidores mergulham com tanta vontade nesse tipo de perseguição gato-e-rato, eles estão involuntariamente dizendo que você estava certo o tempo todo.

Os fornecedores externos interessados em construir sobre esta nova plataforma devem estar ansiosos para que a brincadeira continue. Talvez eles consigam um pouco do ambiente colaborativo, da abertura e da flexibilidade que o Eclipse já experimenta há anos. Porém, tendo em vista os recentes desdobramentos do caso TestDriven.NET, parece que isso não vai acontecer muito cedo.