Entre Padrões de Código e a Programação Literária

Dentro da programação, uma coisa é certa: padrões são muito bem vindos. Uma vez que normalmente não estamos sozinhos num projeto, é importante que todos os desenvolvedores possam entender completamente o código produzido por qualquer um da equipe, evitando criar a idéia de propriedade de código para um único programador.
No processo de definição de padrões de desenvolvimento, deve-se levar em consideração os aspectos: Consistência, Estilo e ferramentas de suporte aos padrões.
Não me entendam mal, mas acreditar que sua equipe possue um padrão de código apenas por utilizar convenções de linguagem (ex: Java Code ConventionsM) é ingenuidade pura! (isso mesmo, ingenuidade). Code Conventions definem apenas a forma em que o código será escrito. Entretando devemos ir além, muito além disso.

Consistência
O código produzido utilizando padrões deve ser a marca da equipe e não o código produzido pelo Joãozinho ou a Mariazinha. Deve-se ter o entendimento de que qualquer um dentro da equipe pode ter desenvolvido aquele código, sem que se faça distinção de quem o escreveu.
Uncle Bob escreve muito bem essa definição ao afirmar que "Esta não é a fantasia de igualdade para que se possa sobrepujar a individualidade em detrimento do grupo, é uma necessidade básica". Como todo indivíduo possui seus próprios vícios e fetiches relacionados ao desenvolvimento, imagine 10 programadores trabalhando num mesmo código ao longo do projeto. Conforme o tempo passa, a mistura de padrões e estilos diferentes dentro do código tornará impossível sua leitura.

Estilo
Sim, uma parte importante do processo de desenvolvimento. Muitos podem se perguntar: "Qual a utilidade de definir o número de espaços que o tab representa? Por que determinar a identação correta para todos da equipe??". Falo aqui apenas da forma, não do conteúdo.
E neste ponto é importante diferenciar estilo de consistência pois eles existem para diferentes motivos. E graças a Deus nós temos o Eclipse e a capacidade de exportar um padrão determinado para arquivos xml que serão importados pelos outros desenvolvedores.

Para trasmitir o conhecimento sobre padrões é necessário um ambiente em que a comunicação possa fluir livremente, ferramentas automatizadas são importantes, mas esse conhecimento deve estar na cabeça dos desenvolvedores. Assim, práticas de Pair Programming e Code review podem ser de grande valia. Durante uma sessão de PP, para um programador mais novo, é importante que ele seja apresentado aos padrões existentes para o projeto. De forma oral, e imediata ao que ele estiver produzindo. Esqueça documentação escrita sobre padrões de código, nomes de métodos, etc... Seu código é a documentação! Um exemplo vivo dos padrões determinados em sua aplicação. Explore-o!

Acredito realmente que times devem ousar em adotar os próprios padrões de desenvolvimento, e que devam encorajar outras equipes a fazerem o mesmo. É também uma questão de identidade do grupo.

E a programação literátia?? Pois bem, falemos dela agora.

Bem, definida há quase 30 anos, a Programação Literária diz respeito à promessa de tornar o código fonte de um sistema tão fácil de compreender quanto um livro. Parece impossível? Mas não é...
Talvez seja uma herança dos tempos do Cobol, em que reduzir o nome de um método ao máximo era sinônimo de performance e economia de bytes do programa. Mas já superamos essa fase. Entretanto os problema continuam, e tentamos reduzir o nome dos métodos apenas por preguiça de escrever. Assim, um método simples com o nome: validaSenhaUsuaria() pode tornar-se algo mais complicado de se entender: valPwd(), expressando pouco sobre o significado do método.

Métodos e variáveis devem expressar seu real significado, facilitando e muito a leitura do código. Existem pessoas bastante adiantadas nesse processo, entre elas Martin Fowler, que já trata da questão com o nome: Language-oriented Programming (vale a pena ver a palestra promovida por ele)

Parece besteira, certo? Mas nem tanto. Imagine-se como um programador que, 6 meses depois, é designado a fazer manutenção de um código escrito apenas com abreviações... lhe desejo sorte para compreender o que foi produzido.
Devemos pensar no desenvolvimento como um processo contínuo de garantir a manutenção sadia para os futuros programadores, garantindo que qualquer um possa compreender e trabalhar dentro do sistema, idenpendentemente de quanto tempo atrás ele tenha sido escrito.


É isso...