A falsa impressão de um bom código

2 12 2010

Desde de quando comecei a trabalhar com desenvolvimento de software, ouvia sempre uma frase que é muito repetida até hoje que diz que: “Código bom é código comentado”. Em conversas com outros desenvolvedores alguns reclamavam porque que se viam obrigados a comentarem seus códigos para poderem passar pelas auditorias internas. Hoje vejo isso como um absurdo (para não dizer outra coisa). Muitos comentários podem mesmo ser parâmetro para definir um bom código? Eu, particularmente sou defensor de um código não comentado, ou com o mínimo de comentários possível. Muitos devem estar se perguntando agora, como assim, código não comentado? Esse cara está ficando louco? Mas não falem mal de mim ainda vou explicar o meu ponto de vista.

Um código comentado quase sempre é sinal de código ruim. Se você sentiu a necessidade de comentar seu código é porque até você está percebendo que o mesmo não está expressivo e, todas as suas linhas não conseguem refletir o seu verdadeiro objetivo.

Acredito que tem certos códigos que realmente são difíceis de serem expressivos, mesmo sendo refatorados. Podemos citar por exemplo, o uso de bibliotecas de terceiros que às vezes não apresentam o funcionamento esperado e, nesses casos somos obrigados a comentar determinados trechos, para facilitar a vida dos outros desenvolvedores que futuramente irão dar manutenção no código. Um outro caso que também pode caber comentários é quando estamos desenvolvendo uma biblioteca para ser utilizada externamente, nessa situação os comentários “podem” auxiliar o uso da biblioteca. Mas ainda permaneço com o pensamento que podemos sempre buscar alternativas para evitar os comentários.

Um código muito comentado pode trazer outro problema: a manutenção do próprio comentário. Sabemos da dificuldade que é em muitos casos dar manutenção em um código de produção, agora some a isso o esforço de atualização também do comentário.

Seu código deve ser expressivo

Para tentar demonstrar um código expressivo imaginei um exemplo onde seja necessário implementar um método que aplique descontos nas mensalidades dos alunos do 5° período ou superior, e que tenham o coeficiente de rendimento maior ou igual a 7.

Código com necessidade de comentárioCódigo com necessidade de comentário 

Abaixo apresento o método “AplicarDescontosMensalidades” refatorado, com um código mais expressivo.

imgCodigoRefatoradoCódigo refatorado sem a necessidade de comentário 

Depois de refatorar o código do método “AplicarDescontoMensalidades”, percebe-se que o mesmo está mais expressivo e o seu objetivo se mostra mais claro para quem lê o código do método agora.

Meu objetivo aqui não é condenar totalmente os comentários no código fonte, mas sim levantar a questão que, mais importante que ter um código muito comentado é ter um código expressivo, que diz a sua intenção tanto nos nomes dos métodos que o compõe, quanto nas suas linhas. Ao sentir a necessidade de fazer um comentário, pare e reflita sobre a sua real necessidade, faça sempre as perguntas: Porque tem que ter esse comentário? O código fica claro sem o comentário? Outros desenvolvedores irão entender mesmo esse código? E se possível procure sempre mostrar seu código para outros desenvolvedores da equipe e receber feedbacks sobre o mesmo.

Robert C. Martin (Uncle Bob) cita no seu livro Código Limpo “Habilidades Práticas do Agile Software”, uma frase que diz muito sobre o pensamento que tenho: “O único comentário verdadeiramente bom é aquele em que você encontrou uma forma para não escrevê-lo”.

É isso ai, espero que tenha conseguido passar o recado e que agora vocês analisem bem a real necessidade dos comentários nos seus códigos. Para qualquer feedback deixe seu comentário, esse sim é um tipo de comentário que aceito e recebo com prazer :) .





Coding Dojo

19 04 2010

Dojo

Antes de começar a falar sobre o que é o Coding Dojo, é importante destacar alguns pontos que motivaram a sua criação. Dentro de um ambiente de desenvolvimento de software, na maioria das vezes encontramos situações em que a equipe deve correr para cumprir os prazos e atender o cliente, porém, isso em alguns momentos faz com que os desenvolvedores não se preocupem com as boas práticas de desenvolvimento, afetando assim a qualidade do código gerado. Analisando esta situação, percebemos que os programadores não treinam, pois, estão sempre focados em desenvolver código de produção, baseando-se nesta realidade surge o Coding Dojo, como uma alternativa para melhorar este cenário.

O Coding Dojo é uma reunião onde os programadores se juntam para trabalharem na solução de um desafio de programação. Esta prática surgiu na França e foi trazida para o Brasil pelo Danilo Sato. O termo “Dojo” veio do judô e significa lugar do caminho, é uma área onde se pratica artes marciais, este local é muito respeitado pelos judocas, sendo visto como uma casa dos praticantes.

Para a realização de um Coding Dojo é necessário apenas um computador e um projetor. Durante um Dojo é comum que haja comida, o ambiente deve ser sempre divertido e inclusivo. Todo Dojo utiliza TDD (Test Driven Development) durante o seu desenvolvimento. É muito importante deixar claro que jamais um Dojo deve ter continuidade, sempre devemos começar do zero, ou seja, a cada reunião um novo desafio é proposto, sendo que os desafios que não foram finalizados em reuniões anteriores não podem ser continuados.

Um Coding Dojo tem como objetivos fornecer uma maneira para praticar programação, aprender sobre novas técnicas com a experiência de outros participantes, ensinar e transmitir sua experiência para os participantes, além de oferecer uma possibilidade de discussões com base concreta sobre o código.

Princípios

Para a prática de Coding Dojo temos alguns princípios, tais como:

  • Aprendizado contínuo

As reuniões de Coding Dojo são sempre movidas por discussões, debates e questionamentos sobre o código desenvolvido para a solução do desafio proposto, estes pontos são a base para um aprendizado contínuo de todos os envolvidos no Dojo.

  • Ambiente Seguro

Para um Dojo de sucesso é importante que todos aqueles que estejam envolvidos com o desafio se sintam a vontade para fazer questionamentos e participar do processo de construção da solução, o ambiente deve ser colaborativo não havendo nenhum tipo de competição entre os participantes, o ambiente deve transmitir um sentimento de inclusão.

  • Baby Steps (Passos de Bebê)

Durante a construção do código para a solução do desafio, é essencial que se desenvolva apenas pequenos trechos de código, sempre caminhando com passos curtos.

  • Melhoria Contínua

MELHORAR SEMPRE, um dos motivos para criação do Coding Dojo é fazer com que os desenvolvedores tenham a oportunidade de aprimorar cada vez mais os seus conhecimentos e técnicas relacionadas à programação.

Formatos

Um Coding Dojo é desenvolvido com base em alguns formatos que ditam como será o decorrer da reunião.

  • Kata

Este formato de Coding Dojo é muito parecido com uma palestra, pois, um participante apresenta um desafio já resolvido. Deve ser destacado que toda a apresentação da solução inicia-se pelos testes e, todos devem conseguir reproduzir o que foi feito. Neste formato as interrupções são permitidas para tirar dúvidas que possam surgir durante a apresentação.

  • Randori

No Randori o desafio é resolvido durante a reunião. Utiliza-se programação em par, onde temos turnos de 5-7 minutos para revezamento dos pares, é importante lembrar que a platéia deve permanecer em silêncio quando um par estiver trabalhando no desafio, os comentários são permitidos apenas na fase verde, ou seja, somente quando os testes estiverem passando.

  • Kake

Este é um formato novo que é muito parecido com o Randori. O nível do Kake é mais avançado, pois, temos vários pares simultâneos que se revezam entre máquinas a cada turno e, a solução ainda pode ser desenvolvida em linguagens diferentes.

Retrospectiva

A retrospectiva é um momento ao final da reunião onde todos os participantes avaliam como foi o Coding Dojo, normalmente uma retrospectiva é movida com base nas seguintes perguntas:

  • O que aprendemos?
  • O que gostamos?
  • O que poderia melhorar?

As discussões e comentários gerados durante uma retrospectiva são pontos importantes que levam a uma melhoria do Coding Dojo e, enriquece todo o grupo envolvido.

Cuidado!

  • Nunca corra para resolver o desafio;
  • Não escolha um problema real como desafio;
  • Nada de discussões sobre tecnologia, foque no problema e na sua solução;
  • Nada de competição entre os participantes;
  • Nunca deixe os participantes sem entender o que está sendo feito;

Conclusão

O Coding Dojo é uma excelente alternativa para os desenvolvedores aprimorarem suas técnicas de programação. O fato dos desafios não envolverem problemas reais que fazem parte do cotidiano de um ambiente de desenvolvimento, possibilita aos desenvolvedores trabalhar sua criatividade e técnicas, o que pode vir a impactar em melhorias que são refletidas no ambiente de produção.

Espero que este artigo possa oferecer a vocês uma visão sobre Coding Dojo, assim como levá-los a uma reflexão sobre suas técnicas de programação e como melhorá-las, pensem nisso. É isso aí pessoal!

Referências

[1] Daniel Cukier [locaweb], http://agilblog.locaweb.com.br/2009/10/09/coding-dojo/

[2] CodingDojo.org, http://codingdojo.org/

[3] Coding Dojo Piauí, http://www.slideshare.net/regispires/coding-dojo-1923746