cubo_vazado

Existe código bonito?

Mudei tudo por que achei que estava muito feio

Inúmeras vezes ouvi esta frase para em seguida me questionar: o que é ser bonito? Em 2004 meu plano de vida era fazer mestrado na área de Estética (Filosofia, não Cosmética). Foi uma decisão que não se concretizou, mas o problema fundamental – a essência do belo – nunca me abandonou. Este é  mais um daqueles posts nos quais penso o modo  como usamos as palavras. :)

Código é arte ou apenas desejamos que seja?

Quando uso termos como “belo”  ou “feio” falamos sobre o que agrada ou não. O que é o (des)agradável? Esta é a questão fundamental da Estética, e há uma área de imensa subjetividade neste território: como o assunto é software, uma armadilha se arma diante de nós.

O que é arte? Quando a questão estética emerge a primeira coisa que pensamos é em arte pois é a maneira mais direta em que a questão estética se manifesta. Pensamos em pinturas, esculturas, filmes, poemas, músicas…  No livro “Arte é o que eu e você chamamos Arte” do Frederico Morais há 801 definições para o termo “Arte”. Com tantas definições, podemos pensar em alguns aspectos que sempre aparecem:

  • Há a criação de um produto: pintura, escultura, música… código?
  • Há uma atividade artesanal.
  • Há criatividade de alguma forma (bastante polêmico este ponto)
  • Há uma pessoa que gera o produto, o “artista”

E ao pensarmos no artista, nos vêm diversas imagens à cabeça: um pintor, escultor, músico, cantor, ator, escritor e tantas outras atividades que pensamos estar diretamente relacionadas à criação. São aquelas pessoas que acabam se tornando de uma forma ou outra nossos ídolos. Talvez por isto haja este esforço em tentar aproximar código de arte: queremos ser ídolos também.

O melhor livro que conheço sobre História da Arte

O melhor livro que conheço sobre História da Arte

Esta visão do artista, no entanto, é preponderantemente a que temos formada no século XX (e final do XIX). Dado que há um trabalho artesanal, há um outro tipo de artista que poucas vezes vejo ser mencionado: o relojoeiro (ou engenheiro, mas vou focar no relojoeiro). Este, para mim, é aquele que mais se aproxima do programador/desenvolvedor (ou o nome da moda que você quiser).

Excelente livro de Frederico Morais sobre a definição de arte

801 definições de arte que Frederico Morais compilou

A imagem do relojoeiro não soa excitante o suficiente para muitos, talvez por isto não se fale tanto a seu respeito como um artista, mas gosto dela pois me trás aquilo que agrada tanto quem compra meu software como quem o manipula: o objeto complexo, artesanal, preciso, difícil de ser feito e que requer paciência infinita. A mesma coisa se aplica à pintura, mas com uma diferença: o relógio precisa atender à risca o requisito de mostrar o tempo com precisão. Há subjetividade, mas o aspecto objetivo grita mais.

(o aspecto pintor é também fundamental. Recomendo a leitura do texto Hackers and Painters de Paul Graham : http://www.paulgraham.com/hpt html)

Aqui está como tornar a coisa um pouco mais excitante para vocês: já ouviu falar em Jaquet Droz? No vídeo abaixo você pode ver um dos seus trabalhos. Mais de 6000 partes interagindo entre si, programaticamente, em 1774. Muito similar ao que você faz hoje com seu código.

Então, sim: há um aspecto artístico no código. É uma atividade criativa (com limitações que falarei a seguir), há um produto (o software), é artesanal (sempre é diferente) e uma pessoa, o “artista” está por trás daquela criação. Mas o que torna o código belo?

O que torna o código belo?

Após anos lendo sobre Estética fica claro para mim o que é belo (sou arrogante). Segue a definição Kiconiana Espartana de belo:

Belo é aquilo que atende a um ou mais requisitos de alguém e com isto o agrada.

Ok, então qual a definição Kiconiana de código bonito?

Código bonito é aquele que funciona e sua equipe consegue entender

O requisito a ser atendido é funcionar: quando faz exatamente aquilo que foi proposto. Neste ponto o código é quase bonito. Se funcionar consumindo o mínimo de recursos computacionais e executando da forma mais rápida possível sem incluir bugs, tá bonitinho (feio arrumadinho).

O alguém é sua equipe. A coisa vai ser bonita mesmo apenas quando sua equipe (não só você)  conseguir entender claramente o funcionamento da sua criatura. Aqui entra o limite criativo do código: se for inteligível por apenas um, estamos lidando com um risco, e não um produto. Risco por que você não terá outra pessoa capaz de evoluir aquele objeto com a saída do seu criador.

Se houver uma discussão em sua equipe do tipo: “olha: eu faço de uma maneira e você de outra, gosto não se discute”, já sabe: a situação foi pro pior lado possível do problema estético que é o estritamente subjetivo. Seu objetivo que é criar um objeto com finalidade bem definida se perdeu, e seu código, por mais belo que cada tolo acredite ser, para o resto da equipe não passa de uma horrorosa aberração.

Sendo assim, você só pode dizer que “mudou a coisa toda por que tava achando muito feia” quando os requisitos acima tiverem sido satisfeitos. Na realidade, você sequer pode dizer “eu acho”, pois o bom profissional (de software) não “acha”, ele é pago para oferecer seu parecer técnico e soluções acerca dos problemas que enfrenta.

PS: dicas de leitura

Este assunto é um ramo extenso da Estética: a “beleza das máquinas”. Você vai encontrar muitos livros bacanas a respeito, mas neste post vou indicar apenas dois.

a_beleza_das_maquinas

“A Beleza das Máquinas” de David Gelernter: é sobre de que maneira o conceito de belo se manifesta em produtos industrais. Você irá ver exemplos que vão do telefone ao desktop do Macintosh. Leitura excelente.

cultura_da_interface

“Cultura da Interface”, de Steven Johnson: uma leitura excelente sobre o modo como elementos culturais e estéticos se manifestam na interface dos sistemas que usamos.

11 thoughts on “Existe código bonito?

  1. Excelente texto. Esse é um assunto que muito me interessa, e concordo com seu ponto de vista. Mas ainda penso que belo seja um conceito subjetivo. O que você define como ‘código bonito’, considero ser na verdade ‘código de boa qualidade’: Funciona e outros desenvolvedores conseguem entender sem dificuldade. Por que digo isso? Pense em outras entidades cuja beleza pode ser avaliada. Pessoas, carros, relógios, obras de arte, no sentido convencional. Cada um de nós pode eleger um ‘mais belo’ diferente, mas ao mesmo tempo concordarmos que todos os eleitos são bonitos. Voltando ao código, eu posso achar bonito usar , já você pode achar horrendo, no entanto com ou sem isso o código pode funcionar e ser compreendido muitíssimo bem pelos demais que o lerem, desde que seja um código de boa qualidade. Creio que o importante não é o código ser bonito, pois dificilmente agradará a todos, esteticamente. O importante é que o código apresente boa qualidade, sendo eficiente, de fácil compreensão e de fácil alteração.

    Responda

    Rafael Romão Reply:

    A formatação no meu comentário não funcionou. Antes desse link gigantesco e sem título, leia “Fluent Interfaces”.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Rafael, valeu!

    Eu também penso na mesma direção: na realidade, acredito que sequer podemos usar o termo “bonito” profissionalmente justamente por causa do fator subjetivo.

    Este fator sempre vai existir, mas quanto menor no caso do código, melhor.

    A “beleza do código” deveria ser substituída por “qualidade do código”. :)

    Responda

  2. Mas que fazer um código inteligível requer sensibilidade e feeling, requer. Muitos de nós não somos capazes de ir direto ao ponto nem em português, que dirá em JavaScript ou COBOL. Não há uma faculdade que se possa fazer para adquirir essa habilidade, aliás acadêmicos têm tendência a se expressar de maneira prolixa. Ser claro, seja no falar ou programar, depende de uma vida focada nesse objetivo e disposição para reescrever as coisas N vezes.

    Responda

    Rodolfo Mendes Reply:

    Discordo quando você diz que não é possível aprender a escrever com clareza. Ao me preparar para vestibular tive aulas de redação, e o tema das aulas era justamente sobre como se expressar bem. Nesse tipo de aula, avalia-se se você sabe dispor as idéias de maneira lógica, conectar início, meio, fim, evitar vícios de linguagem, etc. É claro que o aprendizado requer prática, mas é perfeitamente possível estabelecer critérios objetivos que possam ser ensinados. Por outro lado, concordo que quem tem dificuldade em se expressar em linguagem natural encontrará sérias dificuldades para se expressar em linguagem de programação.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Éderson, discordo.

    O ato de se escrever com clareza está diretamente ligado à boa compreensão do assunto que você trata.

    Além disto há técnicas que te ensinam a melhorar a qualidade da escrita. Claro, você não vai ser um Camões, mas isto não implica que também vai gerar algo ilegível. :)

    Responda

    Éderson Cássio Reply:

    Rodolfo, eu não disse que “não é possível aprender”, nem que não há técnicas objetivas. Pelo contrário, enfatizei a necessidade de prática constante e muita, muita paciência. Referi-me à habilidade, que tem um componente intuitivo, que é alimentado no decorrer do tempo. Isto nenhum curso ensina.

    É preciso deixar claro que uma coisa não exclui a outra. Se você escreve bem, é porque já tem o componente inconsciente bem desenvolvido pela leitura e escrita, então é fácil assimilar as lições de redação. Para vc elas são intuitivas, mas para a maioria dos estudantes, que sequer se importaram em aprender a escrever direito, as regras não fazem o menor sentido.

    Não existe pensamento 100% racional, todas as soluções que pensamos são processadas de maneira inconsciente, ainda que com o filtro da razão batendo o carimbo final. Isso é neurológico (me metendo a falar do que não sei mas baseado em coisas que li), sem os processos inconscientes você levaria um dia inteiro para escolher o que comer ou qual roupa vestir.

    Quanto ao que o Kico falou, vou discordar também (rs). Sim, quem não sabe do que está falando, tergiversa e começa a costurar, tentando ele próprio entender o que está querendo dizer. Mas é muito possível você escrever de uma maneira mais prolixa, cansativa, difícil de interpretar, e ainda assim estar correto. Quando leio textos muito áridos, eu não penso que o escritor não sabia do que estava falando, mas que ele poderia ter se expressado de outra forma. Eu quis dizer que, para o sujeito se expressar claramente, ele tem que ter esse objetivo.

    Mas vou concordar que posts escritos rapidamente e de maneira curta geram controvérsia. Não gosto da ideia de escrever um post do tamanho deste, mas às vezes é preciso ser mais longo para explicar melhor o que eu queria dizer. E, por mais claro que eu seja (não estou dizendo que isso aconteceu aqui, apenas acrescentando já que o assunto é a “clareza”), o que as pessoas entendem depende muito da (falta de) generosidade interpretativa.

    E código mal-escrito é culpa dos “petralhas”.

    Responda

  3. Acho que há várias formas de beleza em um software, consigo pensar em 3:
    1) Beleza do código fonte: é o que você chama de “sua equipe consegue entender”, tenho pra mim que esta é a beleza mais difícil de ser encontrada, o código legível, e aqui entra, também, a maior parte da subjetividade (edentação, identificadores, uso de parênteses, espaços, etc), mas ainda acho que podemos determinar, com algum grau de objetividade, o que é um código fonte belo e um feio (existem algumas ferramentas engatinhando neste ramo);
    2) Beleza da interface: é a área do designer, e assemelha-se muito a pintura, arquitetura e designer em geral;
    3) Beleza da funcionalidade: é a parte “código bonito é aquele que funciona”, de sua definição (com todas as ressalvas que você fez para o “funciona”), acho que software “bonitinho” é o que funciona, software *belo* é o que além de funcionar otimiza o seus uso, é o que apresenta algo a mais para o cliente, pense em Gimp x Photoshop, por exemplo, os dois funcionam para editar fotos, mas o último parece ser mais belo neste particular.

    Determinado software pode ser belo em um dos aspectos e feio nos outros, a obra prima tende a ser belo em todos os aspectos.

    Responda

  4. Bacana!
    Pra mim, o fonte é bonito, quando além de rodar perfeitamente e otmizado, é bem identado, comentado, documentado informando forma de retorno e parametros, explicado nos lugares mais complexos, não existem espaços em branco (linhas) a não ser que separe passos importantes, é legivel, aplica os patterns de forma elegante, variaveis e métodos com nomes bem sugestivos…

    Responda

  5. Como Vovó ja me dizia: “Quem ama o feio, bonito lhe parece.”

    Kico e quando a equipe é formada por um cara só? Como faz?
    Uma das dificuldades que sinto em dar manutenção em software legado é exatamente essa.
    Quando vejo o projeto eu simplesmente ‘encontro’ tantos problemas ‘estéticos’ que em 99.99% dos casos fico com vontade de reescrever tudo.
    Me sinto mau e mal por isso. Pois muitas vezes o que o cliente quer é apenas uma nova funcionalidade.
    Um exemplo bobo mas que me da calafrios são códigos com indentações com espaços e tabs misturados .
    Como você faz quando você é a equipe?

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Nestes casos a coisa fica até mais simples né?
    O que falta na hora em que vamos lidar com código legado é o posicionar-se no lugar do outro. Ao invés de chegar dando tapa no código de cara, se perguntar por que foi escrito daquela forma.

    Responda

Leave a Reply

Your email address will not be published. Required fields are marked *