O tamanho é o inimigo

O mais recente de Steve Yegge, O pior inimigo do código, é como todos os seus posts: rico, gratificante e ridiculamente longas. Steve não escreve com frequência, mas quando o faz, é uma maravilha. Como eu mencionei há um anoComecei uma indústria caseira extraindo os textos insanamente ótimos de Steve, mas que espero que o senhor tenha uma hora para matar, e condensando-os em seus pontos mais curtos. Então, vamos começar:

Steve começou a escrever um jogo multijogador em Java, Wyvern, por volta de 1998. Se o senhor estiver curioso para saber como ele é, veja as capturas de tela dos fãs um e dois.
Nos últimos 9 anos, o Wyvern cresceu para 500.000 linhas de código Java.
Steve percebeu que é impossível para um único programador manter e dar suporte, sozinho, a meio milhão de linhas de código. Mesmo que o senhor seja Steve Yegge.

Há muito mais, mas quero fazer uma pausa aqui por um momento. É absolutamente verdade que qualquer programador que mantenha pessoalmente meio milhão de linhas de código está automaticamente em um clube bastante rarefeito. Steve está certo sobre isso. A maioria dos desenvolvedores nunca terá o privilégio sobre-humano de manter pessoalmente 500 mil LOC ou mais. Em qualquer projeto racional de desenvolvimento de software, o senhor teria uma equipe de desenvolvedores trabalhando nele ou abriria o código-fonte totalmente para distribuir o esforço em uma comunidade.

Mas eis o que eu não entendo:

Acontece que eu tenho uma opinião minoritária, conquistada a duras penas, sobre bases de código. Particularmente, acredito, com bastante convicção, que a pior coisa que pode acontecer a uma base de código é o tamanho.

Portanto, Steve acredita que o maioria dos desenvolvedores, ao se deparar com uma base de código aproximadamente do tamanho do Estrela da Morte, pensaria o senhor:

Eu poderia construir isso.

É um indicador revelador da público de cientistas da computação com barba impressionante com o qual Steve corre. Eles provavelmente também usam chinelos de dedo para trabalhar. Entre os programadores que conheço, a reação muito mais comum – e certamente mais racional – a uma base de código tão grande seria fugir, gritando, o mais rápido possível. E eu estaria logo atrás deles.

Não acho que o senhor tenha necessariamente que passar dez anos escrevendo 500 mil códigos Java bastante complicados para chegar à mesma conclusão de forma independente. O tamanho é o inimigo. Simplesmente passar de 1k para 10k LOC – supondo que o senhor seja suficientemente autoconsciente como programador – é mais do que o suficiente para o senhor vislumbrar a loucura que está por vir. Mesmo que o senhor não tenha escrito nenhuma linha de código, se já leu algum Livros de Steve McConnell, o regra do tamanho é muito importante, repetidas vezes:

O tamanho do projeto é facilmente o fator determinante mais significativo do esforço, do custo e do cronograma [for a software project]. As pessoas naturalmente presumem que um sistema que é 10 vezes maior que outro sistema exigirá algo como 10 vezes mais esforço para ser construído. Mas o esforço para um sistema de 1.000.000 de LOC é mais do que 10 vezes maior do que o esforço para um sistema de 100.000 LOC.

Um dos conselhos mais fundamentais e realmente eficazes que se pode dar a uma equipe de desenvolvimento de software… qualquer equipe de desenvolvimento de software – é escrever menos código, por qualquer meio necessário. Divida o projeto em subprojetos menores. Entregue-o em fragmentos complementares. Experimente o desenvolvimento iterativo. Pare de escrever tudo em linguagem assembly e APL. Contrate programadores melhores que naturalmente escrevam menos código. Comprar código de terceiros. Fazer absolutamente tudo o que for necessário para escrever o mínimo de código possível, porque o melhor código é não ter código algum.

Ainda não terminamos. Eu avisei aos senhores que esta seria uma postagem longa. Continuando a partir de cima:

Como o Java é uma linguagem tipada estaticamente, ele exige muito código boilerplate tedioso e repetitivo para que as coisas sejam feitas.
Esse código padrão tedioso e repetitivo foi codificado na fé Java como os livros seminais “Design Patterns” e “Refactoring”.
Os desenvolvedores de Java acreditam fervorosamente, quase que exclusivamente, que os IDEs podem superar o inevitável inchaço de LOC do Java.
Uma reescrita do Wyvern do Java em uma linguagem dinâmica executada na JVM poderia reduzir o tamanho do código bruto em 50% a 75%.

É aqui que Steve passa, não tão gentilmente, de “o tamanho é o problema” para “Java é o problema”.

Maior é algo com que o senhor tem que conviver em Java. O crescimento é um fato da vida. O Java é como uma variante do jogo Tetris em que nenhuma das peças pode preencher as lacunas criadas pelas outras peças, portanto, tudo o que o senhor pode fazer é empilhá-las infinitamente.

Voltando ao nosso jogo maluco de Tetris, imagine que o senhor tenha uma ferramenta que lhe permita gerenciar enormes telas de Tetris com centenas de andares de altura. Nesse cenário, empilhar as peças não é um problema, portanto, não há necessidade de eliminar peças. Esse é o problema cultural: [Java programmers] não percebem que não estão mais jogando o jogo certo.

Steve destaca Martin Fowler, que recentemente “abandonou” a linguagem estática Java em favor da linguagem dinâmica Ruby. Fowler literalmente escreveu o livro sobre refatoraçãotalvez haja alguma verdade na afirmação de Steve de que a arquitetura rígida das linguagens clássicas e estaticamente tipadas acaba impedindo que o senhor refatore o código até onde for necessário. Se Fowler não pode refatorar as peças do Java para que se encaixem, quem pode?

Bruce Eckel é outra personalidade notável do Java que aparentemente chegou a muitas das mesmas conclusões sobre o Java anos atrás.

Não posso quantificar [the cost of strong typing]. Não consegui chegar a uma prova matemática de primeiros princípios, provavelmente porque isso depende de fatores humanos, como quanto tempo leva para lembrar como abrir um arquivo e colocar o bloco try nos lugares certos e lembrar como ler as linhas e depois lembrar o que o senhor estava realmente tentando realizar ao ler esse arquivo. Em Python, posso processar cada linha de um arquivo dizendo:
for line in file("FileName.txt"):
# Process line
Não precisei procurar ou sequer pensar nisso, porque é muito natural. I sempre tem que procurar a maneira de abrir arquivos e ler linhas em Java. Suponho que o senhor poderia argumentar que o Java não foi projetado para processar texto e eu concordaria com o senhor, mas, infelizmente, parece que o Java é usado principalmente em servidores em que uma tarefa muito comum é processar texto.

As linhas de código são, e sempre foram, o inimigo. Mais linhas de código significam mais para ler, mais para entender, mais para solucionar problemas, mais para depurar. Mas isso é possível ir muito longe na outra direção também. Se não tomar cuidado, poderá acabar jogando outro jogo completamente diferente. Sim, você evitou habilmente a armadilha do Tetris infinitamente alto do Java, mas será que caiu na armadilha do O golfe do Perl em vez disso?

Perl “golf” é o passatempo de reduzir ao mínimo o número de caracteres usados em um programa Perl, da mesma forma que os jogadores de golfe procuram dar o menor número possível de tacadas em uma rodada.

Originalmente, ele se concentrava nos JAPHs usados em assinaturas nas postagens da Usenet e em outros lugares, mas o uso do Perl para escrever um programa que executava criptografia RSA provocou um interesse prático e generalizado nesse passatempo. Nos anos seguintes, o code golf foi adotado como um passatempo em outras linguagens além do Perl.

Em nossa guerra contra a verbosidade, há um inevitável inevitável entre verbosidade e compreensibilidade. Steve reconhece isso ao basear sua escolha de linguagem JVM no que é “sintaticamente convencional”: JRuby, Groovy, Rhino (JavaScript) e Jython. Vou estragar o final não tão surpreendente para os senhores: Steve está reescrevendo o Wyvern em Rhino e, no processo, ajudará a adequar o Rhino às especificações do futuro EcmaScript Edition 4 atualização para JavaScript. Ela é não há solução mágica, mas parece ser um compromisso razoável com base em seus objetivos.

Assim termina a história épica de dez anos de Stevey e seu alegre bando de Wyverneers. Mas onde isso nos deixa? Eu tenho minhas opiniões, naturalmente:

Se o senhor escreve pessoalmente 500.000 linhas de código em qualquer linguagem, está totalmente ferrado.
Se o senhor reescrever pessoalmente 500.000 linhas de código de linguagem estática em 190.000 linhas de código de linguagem dinâmica, ainda assim estará muito ferrado. E o senhor também perderá um ano de sua vida.
Se estiver iniciando um novo projeto, considere o uso de uma linguagem dinâmica como Ruby, JavaScript ou Python. O senhor pode descobrir que pode escrever menos código que significa mais. Muitas pessoas incrivelmente inteligentes como Steve apresentam um caso convincente de que a grama realmente é mais verde no lado dinâmico. No mínimo, o senhor aprenderá como a outra metade vive e talvez remova algumas vendas que nem sabia que estava usando.
Se o senhor está preso ao uso exclusivo de linguagens estáticas, pergunte a si mesmo: por que do temos que escrever tanto código para conseguir fazer alguma coisa… e como isso pode ser mudado? Coisas simples devem ser simples, coisas complexas devem ser possíveis. É saudável questionar a autoridade, particularmente autoridades linguísticas.

Lembre-se: tamanho real é o inimigo. Logo depois de nós mesmos, é claro.