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.

8 Responses to “Bolas de chumbo”


  1. 1 Davis 21/jun/2007 às 11\1152

    Muito bom o texto mano.
    Faculdade faz muito isso de nivelar por baixo, com isso a qualidade do curso cai e todo mundo acaba sendo prejudicado.

  2. 2 Samir 21/jun/2007 às 13\0145

    Já tive a experiência de trabalhar em 2 lugares assim e confesso que não é saudável.

  3. 3 Andre Furtado 27/jun/2007 às 20\0818

    Concordo com teu ponto-de-vista. Algumas práticas para compartilhar código e conhecimento (XP que o diga) dão bem mais resultado do que nivelar por baixo.

    Mas acho que não se pode atribuir o termo “fábrica” a qualquer produção (desordenada, inclusive) em massa. Nas definições mais atuais (das várias que já existiram para isso, eu sei), fábricas estão ao nosso lado ao encapsular abstrações em padrões, linguagens, frameworks e ferramentas, permitindo que tais abstrações sejam mais facilmente entendidas e utilizadas. A intenção é capturar a expertise de especialistas e abstrai-las, evitando justamente que o uso dela se torne bolas de chumbo!

    []s
    — AFurtado

  4. 4 thiagoarrais 27/jun/2007 às 20\0836

    André, com certeza não se pode e não se deve usar o termo deste modo. Porém isso não impede muita gente de fazer exatamente o que está descrito no artigo.

  5. 5 Juan Maiz 11/jul/2007 às 14\0251

    É como a teoria dos macacos, que afirma:

    Colocando um número muito grande de macacos em máquinas de escrever, em um certo tempo, algum escreverá Shakespeare.

    Abraço.

  6. 6 Marcelo 29/set/2007 às 00\1214

    Li seu texto e me identifiquei muito com o seguinte trecho:
    “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.”
    Cara! Eu sinto exatamente isso. E o pior: quando tento introduzir uma idéia nova à diretoria, a resposta é imediata: “não dá prá implementar, já tentamos e não deu certo”.
    Eu fico sempre muito frustrado. Qdo chego em casa, parece que eu carreguei uma bola de chumbo o dia todo.

    Desculpe o desabafo, mas seu post fala muito sobre a realidade que eu vivo todo santo dia.

    []’s


  1. 1 davis.zc » Arquivos » Bola de chumbo - por Thiago Arrais Trackback em 21/jun/2007 às 11\1154
  2. 2 rascunho » Blog Archive » links for 2007-06-22 Trackback em 22/jun/2007 às 20\0821
Comments are currently closed.




%d blogueiros gostam disto: