A consultoria Synectics publicou o resultado de uma pesquisa cujo objetivo era obter uma lista com os 100 maiores gênios vivos. No 1º lugar desta lista está o inglês Tim Berners-Lee, o criador da World Wide Web, que divide esta colocação com o químico suiço Albert Hoffman, criador da droga LSD, que revolucionou os tratamentos psiquiátricos nos anos 40.

Além destes, a lista contém também o criador dos Simpsons, Matt Groening (4º) , Nelson Mandela (5º), o arquiteto brasileiro Oscar Niemeyer (9º), os fundadores do Google , Larry Page (20º) e Sergey Brin(20º), Steven Spielberg (26º), Dalai Lama (26º), Prince (33º), Osama Bin Laden (43º), Bill Gates (43º), a atriz Meryl Streep (49º), Paul McCartney (58º), Stephen King (58º), o co-fundador da Apple, Steve Wozniak (67º), a cantora Aretha Franklin (67º), David Bowie (67º), o inventor do celular, Martin Cooper (67º), o criador do Homem Aranha e dos X-Men, Stan Lee (72º), George Lucas (72º), a escritora J. K. Rowling (83º), o projetista do rifle AK-47, Mikhail T. Kalashnikov (83º) e Quentin Tarantino (100º).

Entre as ausências, a mais surpreendente, pelo menos pra mim, foi a do Steve Jobs, co-fundador e CEO da Apple, ainda mais porque o outro co-fundador, Steve Wozniak, foi incluído. Mas ao que parece, estar a frente de uma empresa que foi fundamental na definição da computação pessoal, tornar a Pixar um dos maiores estúdios de animação do mundo, e recuperar a Apple anos depois de ter sido demitido de lá, não é suficiente para ser considerado um gênio.

De qualquer forma, ainda que seja difícil(ou impossível) identificar alguém em particular como o maior gênio vivo, não podemos dizer que o Tim Berners-Lee é indigno deste título. Afinal de contas, ele criou algo que mudou o mundo para sempre, sem a qual você sequer estaria lendo este texto.

Ao pesquisar por listas de discussão sobre Ruby on Rails no Google, eu acabei indo parar no blog Tecnologias Web. Como o Rails é um dos temas do blog, e eu já estava lá mesmo, acabei dando uma olhada no conteúdo, e encontrei a tradução de uma entrevista do David Heinemeier Hansson(DHH), o criador do Rails.

A entrevista original foi concedida para a O’Reilly Network, em 30 de agosto de 2005, ou seja, já faz um bom tempo. Tanto tempo que é até curioso ver o David falar sobre o Capistrano, na época conhecido como SwithTower, como uma novidade a ser introduzida em uma versão futura do Rails.

Portanto, como se trata de uma entrevista bem feita, eu recomendo a leitura, tanto da versão original quanto da versão traduzida. Apesar disso, gostaria de destacar algumas coisas interessantes que foram ditas.

Uma destas coisas é a resposta do David quando perguntado sobre a sua funcionalidade favorita do Rails. Na resposta dele está muito da filosofia do Ruby on Rails, pois ele responde dizendo que é tudo aquilo que o framework não faz. E para realmente entender o Rails, devemos analisar não somente o que ele é, mas também tudo que ele abriu mão de ser em prol de uma visão focada das coisas.

Outro ponto interessante que o David ressalta na entrevista é que o Rails foi desenvolvido orinalmente para servir a ele mesmo no desenvolvimento de aplicações web. E ainda que o framework tenha alcançado bastante sucesso, ele não abre concessões e mantém o seu objetivo original.

Isto pode parecer um pouco egoísta, como ele mesmo admite na entrevista, no entanto, devemos lembrar que o DHH é um desenvolvedor de aplicações web, portanto os problemas dele são os problemas de milhares de outros desenvolvedores. Logo, ele está resolvendo também os problemas de uma quantidade enorme de pessoas, além de proteger esta solução, de forma a não “contaminá-la” com problemas que fogem ao foco original.

Por fim, gostaria de destacar também o fato dele lembrar na entrevista que o Rails foi extraído de uma aplicação real, no caso o Basecamp. Esta, aliás, é uma posição que ele e comunidade Rails defende com frequência, ou seja, o fato de que um framework, no caso o Ruby on Rails, deve ser extraído de algo concreto, tendo assim apenas funções cuja utilidade foram postas à prova, ao invés de tentar imaginar o que os desenvolvedores poderiam precisar. Este assunto, inclusive, foi mencionado recentemente em um post no blog da 37 Signals onde o DHH fala sobre o nascimento do Rails.

Boas notícias. O encontro de Ruby on Rails que está sendo organizado pela Improve It está mais do que confirmado. Ele se chamará Rio on Rails e tem como logo a imagem ao lado. E que belo logo, diga-se de passagem.

O evento irá ocorrer no dia 8 de dezembro, um sábado, no SENAC , que fica na Rua Santa Luzia, 735, 7º andar, Centro do Rio de Janeiro. A propósito, é neste mesmo local que são realizadas as reuniões do XP Rio e do RioJUG.

Os palestrantres confirmados até o momento são: Fábio Akita, Carlos Eduardo, Ronaldo Ferraz, Danilo Sato, Demetrius Nunes e a equipe do Projeto Lucidus . No entanto, o tema das palestras ainda não foi divulgado, além disso, é possível ainda que o encontro tenha também a presença do Nando Vieira.

O formulário para inscrição será disponibilizado no site da Improve It na próxima semana, sendo que o preço da inscrição ainda não foi definido. De qualquer forma, é interessante ressaltar que o local onde o Rio on Rails será realizado possui capacidade para apenas 80 pessoas, sendo assim, as vagas serão preenchidas rapidamente. Portanto, quem pretende ir deve-se cadastrar assim que a inscrição for disponibilizada.

Parece que os eventos de Rails estão finalmente começando a acontecer aqui no Brasil. Sendo assim, abaixo resumo brevemente o que acontecerá em cada estado.

São Paulo

Em São Paulo, o Fabio Akita está organizando um encontro de Rails chamado RejectConf SP’07. O evento ocorrerá no dia 17 de novembro, um sábado, das 11:00 às 17:00, sendo realizado no auditório Jacy Monteiro do Instituto de Matemática e Estatística da USP, e terá a entrada gratuita.

Acontece que este encontro despertou bastante interesse na comunidade, tendo a sua lotação (90 pessoas) atingida em 3 dias. No entanto, a inscrição para o RejectConf SP’07 continua no ar, só que agora ela passa a ser uma lista de espera. Dessa forma, a vaga dos participantes que já se inscreveram, mas não poderão mais comparecer, será realocada. Portanto, se tiver interesse em participar, não deixe de se inscrever.

Mas nem tudo é boa notícia quando o assunto é encontros de Rails em São Paulo. O 2º seminário de Ruby on Rails, que estava sendo organizado pelo Tempo Real Eventos e aconteceria no dia 20 de outubro, foi cancelado devido a problemas com a universidade onde o evento seria realizado.

Rio de Janeiro

O Vinicius Manhães Teles e o pessoal da Improve It estão organizando um evento de Rails em parceria com o SENAC/Rio, a ser realizado no início de dezembro. Embora nem o local nem a data estejam definidos ainda, o evento provavelmente será realizado num sabádo.

Minas Gerais

O encontro de Rails em Minas Gerais está sendo organizado pelo Ronaldo Ferraz e pelo Leonardo Faria, sendo que ele ocorrerá em Belo Horizonte. Embora a data, local e palestrantes ainda estejam indefinidos, este encontro provavelmente ocorrerá em novembro.

Outros estados

Felizmente não são só os estados acima que estão planejando alguma coisa. O Urubatan está organizando um encontro de Ruby on Rails no Rio Grande do Sul, enquanto em Brasília o Tiago Ramos faz o mesmo.

No dia 12 de outubro, foi publicado o anúncio da versão 1.2.5 do Ruby on Rails no blog oficial do framework, sendo que, assim como a versão 1.2.4, este release não apresenta grandes mudanças. O Rails 1.2.5 apenas corrige uma vulnerabilidade no JSON, além de fazer outras correções de bugs menos importantes. Ou seja, trata-se de um release de manutenção e segurança.

De qualquer forma, a atualização para esta nova versão é aconselhada, ainda que só seja realmente necessária para quem use o JSON. Para atualizar a sua versão do Ruby on Rails, basta digitar o comando gem install rails na janela de comando do seu sistema. Além disso, você também deve mudar o RAILS_GEM_VERSION no config/environment.rb dos seus projetos Rails já criados, uma vez que eles estão com uma versão anterior configurada.

Primeiro tivemos o post sobre código sem comentários, depois o post abordando comentários em excesso, agora, finalmente, veremos algo que devemos usar: código autodocumentado.

Do que se trata?

Um código é autodocumentado quando você pode compreendê-lo facilmente apenas lendo o seu arquivo fonte. Para atingir tal nível de fluência, além de um programador que conheça a linguagem utilizada, precisamos que a maior parte do código fonte seja perfeitamente claro, além disso, devemos também comentar os trechos de código complexos que eventualmente existirem.

Escrevendo código claro

Talvez a tarefa mais difícil na busca por um código autodocumentado seja programar de forma extremamente clara, não só para si, como também para todos os outros programadores. Para conseguir isto você precisará de prática, dedicação e até mesmo uma certa dose de talento. Ou seja, não é nada fácil, e é justamente por isso que eu disponibilizo abaixo algumas dicas para facilitar esta atividade.

1. Siga as convenções da linguagem de programação que você utiliza, mesmo que você não goste delas. Fazendo isso, você irá reduzir a surpresa dos outros programadores e adestrar o pensamento de forma a reconhecer automaticamente certas construções.
2. Dê nomes intuitivos a todas as estruturas do seu programa. Isto inclui, por exemplo, classes, variáveis, métodos, arquivos, entre outros. Fazendo isto, ninguém irá parar pra pensar no propósito dos elementos que compõem seu software, possibilitando assim uma leitura mais fluente.
3. Escreva código que cumpra o objetivo, e só. Não escreva nada desnecessário, lembre-se que quanto menos linhas melhor.
4. Não escreva métodos longos. Se um método acaba se prolongando, é provável que ele faça coisas demais, devendo assim ser refatorado em dois ou mais métodos.
5. Evite escrever instruções excessivamente longas ou complexas. Em geral, essas instruções podem ser decompostas, e, ainda que isto signifique mais linhas de código, é melhor do que criar um ponto potencialmente complexo.

Escrevendo comentários

Clareza no código é apenas metade do necessário para termos código autodocumentado, sendo o uso de comentários a outra metade. Esta necessidade se dá devido a natureza complexa do software, pois mesmo quando escrevemos código de forma clara, poderão existir trechos do código onde a compreensão seja naturalmente mais difícil, sendo preciso usar comentários para resolver o problema.

Contudo, é importante ressaltar que apenas comentar não adianta nada. Temos que fazer o comentário valer a pena, afinal, mesmo ele sendo necessário neste caso, ainda implicará em mais tempo para escrever, ler e manter o programa.

Tendo isto em vista, separei abaixo algumas poucas dicas que talvez possa ajudá-lo a escrever bons comentários:

1. A menos que esteja trabalhando com uma equipe muito grande, não é necessário escrever comentários referentes a autoria dos códigos. Em geral, uma divisão de tarefas adequada já se encarrega de definir claramente quem faz o quê.
2. Escreva comentários somente para trechos de código complexos. Um comentário para descrever o objetivo de um elemento do programa é desnecessário, uma vez que um bom nome já é o suficiente. Por exemplo, não é preciso comentar o objetivo de uma classe chamada LoginController, uma vez que o nome não deixa dúvidas sobre o seu propósito.
3. Quando for escrever um comentário, não fale sobre a sintaxe do código, e sim da sua semântica no domínio da aplicação. Lembre-se que você está comentando um programa, e não a linguagem utilizada.
4. O comentário deve ser absolutamente claro sobre o trecho de código que ele está explicando, de forma a não restar dúvida alguma sobre o seu funcionamento.
5. Os comentários são apenas pequenos textos explicativos, e não artigos, portanto, seja sucinto e evite comentários com muitas linhas. Se puder utilizar apenas uma linha, melhor.

Use apenas o que gostar

As dicas acima não são dogmas, assim como tudo mais que eu disse nessa série de posts. Trata-se apenas da minha opinião sobre esta questão, logo, sinta-se a vontade para ignorar parte das dicas, parte do que eu disse, ou até mesmo tudo que leu nestes posts. Cada um tem sua maneira de desenvolver software, e eu estou longe de ter autoridade suficiente pra dizer que alguém está errado simplesmente porque discorda do que eu acredito ser o ideal.

Foi lançada no último dia 4 de outubro a versão 1.2.4 do Ruby on Rails, no entanto, trata-se de um release de manutenção, não havendo, portanto, grandes mudanças no framework. Mais especificamente, nesta versão foram feitas correções relativas a segurança, pequenas melhorias na performance, além da adição de alguns avisos de deprecation.

Entre estas mudanças, os avisos de deprecation merecem atenção especial, principalmente se você pretende atualizar futuramente para a versão 2.0 Isso porque tudo que for marcado como warning ao rodar os testes na versão 1.2.4, se tornará erro na versão 2.0.

Sendo assim, conforme aconselha o post sobre o Rails 1.2.4 no blog oficial do Ruby on Rails, atualize a sua instalação para a versão 1.2.4. Para fazer isso, basta abrir uma janela de comando e digitar gem update rails -y.

Depois de vermos no post sobre código fonte sem comentários o quão ruim é esta prática, é hora de conhecermos outro cenário quase tão desagrádavel quanto: comentários em excesso.

A Transição

A maioria dos aspirantes a desenvolvedor já sabe da existência dos comentários quando está aprendendo a sua primeira linguagem de programação. Mas, como disse no post anterior, nesse momento nós ainda não temos maturidade para entender os benefícios desta abordagem, e consequentemente não comentamos nada.

Passado esse estágio inicial, e em geral quando já estamos na segunda linguagem, é comum lermos novamente sobre os comentários e a sua importância. Como neste momento nós já possuímos um pouco mais de conhecimento, e em geral também passamos a nos preocupar com as boas práticas no desenvolvimento de software, tendemos a reconhecer o valor dos comentários e os adotamos.

No meu caso, essa mudança de hábito ocorreu quando começei a estudar Java, aproximadamente 6 meses depois de aprender o básico sobre programação com o Pascal. Eu estava estudando através do clássico livro Java - Como Programar(6ª Edição), e o livro comentava bastante os seus códigos fonte, principalmente no início.Além disso, também lia costantemente sobre a importância dessa prática em fóruns sobre Java, principalmente no fórum do GUJ.

É claro que como resultado desta nova exposição ao tema, desta vez já tendo bagagem suficiente para assimilá-lo, eu acabei adquirindo o costume de comentar os meus códigos.

Pecando pelo Excesso

Acontece que eu não apenas escrevia comentários, eu escrevia muitos deles, bem mais do que o necessário. Se não me engano, eles ocupavam pelo menos metade das linhas dos meus arquivos fonte.

É claro que na época eu já desconfiava que aquilo não era uma boa prática, mas, como aquele código tinha fins meramente didáticos, achei que não tinha problema. E de fato, nesse primeiro contato com os comentários, o excesso até pode ser algo bom, uma vez que dá prática na tarefa, o que pode vir a ser útil no futuro. Além disso, também serve para agilizar o aprendizado, uma vez que você acaba escrevendo conteúdo sobre o que está aprendendo.

Mas, em cenários reais, pecar pelo excesso é quase tão ruim quanto pecar pela ausência. Portanto, quando estiver escrevendo programas de verdade, análise os comentários no seu código e tente avaliar se não há mais do que o necessário. Mesmo sendo esta uma questão subjetiva, em geral, se você se sentir desconfortável, é porque provavelmente exagerou mesmo.

Por que é tão ruim?

Se você leu o post anterior, onde eu descrevo como uma irresponsabilidade o ato de não comentar o código de um programa, pode estar confuso agora sobre o porquê de eu estar chamando a atenção para o excesso de comentários. Acontece que a velha máxima também se aplica aqui: tudo em excesso é ruim.

Neste caso, é ruim porque idealmente um programa deve atingir o objetivo proposto com o mínimo de linhas possível, obviamente sem sacrificar a legibilidade do código. Dessa forma será mais rápido para criar o programa, para ler ele, e também para mantê-lo, já que os comentários devem ser atualizados junto com o código que descreve.

Contudo, quando escrevemos comentários demais, o número total de linhas do programa aumenta desnecessariamente, criando assim vários pontos de disperção, pois será gasto mais tempo em atividades que não agregam valor real.

Seja Preguiçoso!

Por fim, uma dica final que eu posso dar quanto a esse assunto é para você seguir o meu exemplo e ser preguiçoso. Sempre que você sentir aquela indisposição pra inserir um comentário em um determinado trecho do programa é porque provavelmente ele não merece existir. E se ele não merece existir, não há porque colocá-lo. Lembre-se, não exagere jamais no quantidade de comentários que você escreve em um programa.

Uma das abordagens em relação aos comentários é simplesmente não comentar nada no código fonte. É cômodo, prático, e não exige esforço algum. Mas será que esta é mesmo a melhor prática?

No início…

Em geral, quando estamos aprendendo a programar, esquecemos completamente dos comentários, embora a maioria dos tutoriais ou livros sobre linguagens de programação ensine a sintaxe deles logo no início. Mas, nesse momento, o nosso foco é outro, estamos empolgados demais para ficar escrevendo comentários. Além disso, também não temos ainda a maturidade necessária para entender os seus benefícios.

Eu sei disso porque foi assim comigo, e muito provavelmente foi assim com você também. No meu caso em particular, eu iniciei na programação com o Pascal, a primeira linguagem de muita gente, e sinceramente nem lembro mais a sua sintaxe para comentários, tal a constância com que eu os usava.

Eu sei que isso não soa nada profissional, mas, neste contexto, onde estamos apenas aprendendo uma linguagem, ainda que não seja a primeira, esta abordagem é aceitável, afinal, não estamos falando sobre uma situação real de desenvolvimento.

E como ficam as coisas no mundo real?

No mundo real, onde estamos escrevendo código que irá virar um programa de verdade, não inserir nenhum comentário é uma tremenda irresponsabilidade, ainda que se trate de algo relativamente simples, onde você é, e sempre será, o único envolvido.

Sua memória irá te trair

Um dos motivos que faz com que tal prática seja condenável é o fato de nós, como seres humanos, termos uma memória incrivelmente falha. Você lembra o que almoçou 3 dias atrás? Provavelmente não, então como quer lembrar de cada detalhe de um programa que escreveu há semanas, meses ou até mesmo anos atrás? É simplesmente impossível.

Neste momento, você pode estar pensando que ainda que não lembre de cada detalhe do programa, você sempre poderá ler o código fonte e entender o seu funcionamento. Ledo engano! Software não é tão simples assim. Mesmo em linguagens expressivas como Ruby, podemos não entender o que queríamos fazer em certos trechos do código se ficarmos um certo tempo sem ter contato com ele.

O programa não é seu

Outro motivo para desconsiderar esta prática é o fato de que, na grande maioria dos casos, quem desenvolve o programa não é o seu dono. Em geral, o que acontece é que alguém nos paga para desenvolver um software com o objetivo de informatizar uma tarefa.

Esta pessoa, que investe na criação do programa, é o seu legítimo dono, e você tem a obrigração de desenvolver o sistema proposto de forma que ele não fique preso a você de forma nenhuma. Em outras palavras, o dono do programa deve ter a capacidade de mantê-lo facilmente sem a sua presença.

Para que isso ocorra, o código deve ser claro o suficiente para que qualquer outro programador com conhecimento na linguagem de programação utilizada seja capaz de entendê-lo.

Contudo, como vimos há pouco, às vezes é difícil entender o significado de certos trechos de código, mesmo quando escritos por nós mesmo. Logo, escrever um programa que seja claro não só pra nós mesmos, como também para outros programadores é ainda mais difícil. Por mais que escrevemos código legível, sempre há alguns pontos mais complexos.

É justamente para tentar resolver esse problema que existem os comentários, já que eles podem elucidar o funcionamente destes trechos mais problemáticos. Sendo assim, não comentar o código do programa é uma forma de dificultar, ou até mesmo impossibilitar, que ele seja compreendido por outros programadores, deixando assim o verdadeiro dono do programa preso a você.

Seja profissional!

Espero ter deixado suficientemente claro que não há motivo digno de consideração para não usar comentários, portanto, seja profissional! Não cometa este atentado contra as boas práticas do desenvolvimento de software. Os outros programadores agradecem.

Escrevendo o post sobre comentários no Ruby, me veio à mente um assunto bastante recorrente no desenvolvimento de software: o uso correto dos comentários.

Basicamente, existem 3 abordagens relativas a este assunto, e ao escrever sobre cada uma delas, eu percebi que se trata de um tópico um pouco mais extenso do que eu imaginava. Sendo assim, decidi dividir o que originalmente seria um post bem longo, em uma série de 3 posts mais focados, sendo um sobre cada abordagem.

O 1º post, Comentários são para fracos!, analisa a abordagem mais cômoda: não escrever comentário algum. Avalanche de comentários é o 2º post da série, e fala sobre a prática de entupir o código fonte de comentários. Por fim, temos o post Código autodocumentado, que é sobre o que eu acredito ser a melhor forma de atacar o problema: escrevendo código autodocumentado.

Espero que gostem desta pequena série de posts relacionados.