O Bom e o Ruim
A beleza e o propósito
Ecce Homo
No ano de 2012, a pacata cidade Borja, na Espanha, e o mundo das artes foram violentamente chacoalhados com uma inovadora restauração.
Uma singela idosa, como muitos de vocês sabem, resolveu restaurar a antiga obra religiosa Ecce Homo por conta própria, “sem pedir permissão”, mas “com boas intenções”. O detalhe é que restaurações, digamos, não são o ponto forte do seu talento e ela tinha consciência disso.
Ela contava com sua fé inabalável e esperava que isso fosse suficiente para que uma incorporação divina tomasse seu corpo e a inspirasse na restauração, à la Patrick Swayze e Whoopi Goldberg no inesgotável clássico "Ghost — do outro lado da vida".
A restauração saiu pela culatra e o resultado foi completamente diferente do esperado. Entretanto, o tiro pela culatra também saiu pela culatra e produziu um notório feito de marketing — Talvez a idosa tenha sido incorporada por um artista publicitário.
O fato ganhou proporções mundiais e catapultou a então desconhecida cidade ao estrelato, recebendo dezenas de milhares de turistas para apreciar a obra.
A instituição passou a cobrar pela entrada para financiar a conservação da pintura e suas obras de caridade
Para finalizar a cereja desse bolo repleto de cerejas, a idosa, receptáculo de espíritos em potencial, ao perceber o resultado da sua aventura, alegou direitos autorais e recebe praticamente metade de tudo que é recebido pela instituição.
Dependendo do aspecto avaliado da restauração, é possível afirmar que ela é magnífica!
O propósito do código
Quando falamos de qualidade de códigos de programação imediatamente nos vem à cabeça termos como coesão, acoplamento, legibilidade, padrões de projeto e uma infinidade de buzzwords.
Apesar de, normalmente, ser o que se procura quando um código é escrito, também existem outros objetivos na escrita do código e os termos anteriores não são os principais adjetivos procurados na avaliação de qualidade desse código.
Com a liberdade que só meu próprio texto me proporciona, questiono: quem disse que o código bom é aquele que é de fácil compreensão e manutenção?
Antes mesmo que eu possa finalizar meu questionamento, sei que serei interrompido com um: “Uncle Bob, no livro Clean Code”, e a famosíssima imagem:
Sim, existem códigos cujo único propósito é repousar eternamente no fundo do lixo. Muitos outros, no entanto, possuem propósitos diferentes. Contrariando a convenção social, é engano associar imediatamente a qualidade do código à sua legibilidade, limpeza e facilidade de manutenção.
Para reforçar meu argumento, apresento o seguinte código:
Ele serve muito bem ao seu propósito: servir de exemplo. Podemos questionar sua limpeza, praticidade, segurança, padronização e tal. Mas temos que aceitar que ele é excelente para reforçar meu ponto.
Sob essa ótica, percebemos que para analisarmos a qualidade do código, temos que entender o seu propósito.
A qualidade do código está estritamente relacionada ao seu objetivo.
O bom código
Robert Nystrom, no seu livro de estreia Game Programming Patterns, elenca três objetivos na escrita de códigos. Todos eles giram em torno da maximização da velocidade. São maximizações da velocidade de escrita, da velocidade de execução e da velocidade de compreensão.
Essas finalidades são relacionadas de tal modo que priorizar uma pode acarretar no detrimento de outra, fazendo com que raramente as atinjamos simultaneamente. Ainda assim, o código não deixa de ser melhor se pendermos para uma finalidade e sacrificarmos outra.
Velocidade de escrita
Existe sempre a pressão de terminar a tarefa o mais rápido possível deixando todo o resto para depois. Se nós socarmos tantas funcionalidades quanto possível, nosso projeto se tornará uma pilha de confusão, gambiarras, bugs e inconsistências que afetará a produtividade no futuro.
Mas há valor no código escrito rapidamente. É comum escrever código sabendo que ele será jogado fora.
Se o propósito é testar se a ideia funciona, projetá-la com maestria significa torrar mais dinheiro antes de colher algum resultado. Se a ideia não se mostrar promissora, o tempo perdido esculpindo um código elegante é desperdiçado quando ele é jogado fora.
Aglutinar código funcional o suficiente para responder uma pergunta de design é uma prática perfeitamente legítima e tem até nome: prototipação.
Além dessa, existem outras ocasiões onde a velocidade da escrita é a principal diretriz por trás da escrita.
Em uma palestra com uma escrita de código ao vivo, por exemplo, com o tempo contado, a intenção do palestrante tende a ser exemplificar como a ideia funciona e não a beleza do código. Já presenciei, inclusive, vários códigos que sequer compilavam sendo apresentados e o palestrante não exibir o mínimo de constrangimento por isso. Em muitas vezes, eu era o palestrante. 😃
Velocidade de execução
A implementação mais rápida de ser escrita raramente é a de melhor desempenho. Um código de desempenho extremo tende a dificultar uma eventual mudança posterior. Sempre que for necessário fazer uma adição ao código, mais tempo será despendido para escrevê-lo.
Otimizar performance requer tempo para experimentar e explorar. O que funciona bem em uma aplicação pode não funcionar em uma outra. O ideal é possuir um leque de alternativas e testar suas combinações entre si até encontrar a melhor.
Por exemplo, pode ser que a substituição da estrutura de dados seja uma excelente opção. Às vezes, minimizar acessos ao disco é um enorme alívio. Há momentos em que a própria configuração de hardware pode limitar a beleza do código.
Maximizar a velocidade de execução também pode acarretar em um prejuízo na velocidade de compreensão do código. Abrir mão do polimorfismo e elegância em prol do desempenho parece um preço razoável a se pagar para a economia de ciclos computacionais.
A depender do objetivo, o código pode se tornar um verdadeiro teste de QI e a carga cognitiva para sua compreensão ser altíssima. Ainda assim, o código pode ser excelente.
Velocidade de compreensão
Finalmente, o terceiro ponto e o que se pressupõe ser único.
Certamente, lemos nosso código muito mais do que o escrevemos. Faz sentido otimizar sua compreensão, o que resulta em menos tempo empregado no conjunto dessas duas atividades.
Muitos outros fatores influenciam na compreensão além da "qualidade da escrita": familiaridade com a linguagem, padrões adotados pelo time, conhecimento sobre o assunto, etc.
Como um codificador, você é um autor e artista — Como o amigo Caique Rodrigues gosta de afirmar — e o seu trabalho será lido e apreciado. É seu papel assegurar que a leitura seja fácil.
Escrever códigos compreensíveis exige pensamento cuidadoso e isso se traduz em tempo. Às vezes, até para piorar um produto e tornar algo ruim é necessário tempo também, o tomate seco e a água com gás estão aí para confirmar isso.
Pior, manter o código compreensível requer muito esforço e seguir aquela máxima dos escoteiros: sempre deixar o acampamento em melhor estado do que o encontrou.
Dar um capricho para agilizar a leitura requer um maior tempo de escrita. Indo diretamente ao encontro do primeiro dos objetivos apresentados.
A qualidade do código
Para a avaliação de obras de arte, existem inúmeros fatores além do estético.
A beleza é uma característica subjetiva e varia conforme o avaliador. De que outra forma você explicaria alguém pagar U$ 5 milhões pela seguinte pintura, que, literalmente ofende a todos que a visualizam?
Mas, para além da beleza como critério de qualidade, cito também o impacto social, o contexto panorâmico e o sentimento.
O código-fonte, enquanto produto de arte da computação, não é diferente. Podem e devem ser avaliados por múltiplos aspectos.
Essas perspectivas nos levam a uma conclusão: existem momentos e lugares para os diferentes objetivos do produto.
Assim como a maioria dos meus textos técnicos, este também é sobre trade offs e ponderações…
Não há resposta certa, apenas diferentes sabores de errado.
Robert Nystrom
Um sabor para cada propósito, complemento.
