Só o código importa. Essa frase nem sempre me disse tanto quanto diz hoje em dia. Sua simplicidade desafia a compreensão de um profissional que vivenciou e ainda vivencia projetos de software nos quais o código é apenas mais uma das coisas que podem dar errado. Em um contexto no qual passamos boa parte da graduação aprendendo a montar diagramas e no mercado em que os profissionais passam o dia montando documentos, essa frase realmente não pode fazer sentido.

Desde 2009 atuo em um contexto diferente da maioria do mercado: O contexto de entregas rápidas e funcionais de software. Nele o tempo é um recurso que precisa ser muito bem aplicado e tudo o que for desnecessário ou demorado deve ser simplificado ou simplesmente removido do processo, buscando a entrega. Nesse contexto, onde o que importa é software funcionando, feedbacks rápidos e projetos adaptáveis à mudança de requisitos e tecnologias, o código ganha muito mais relevância do que tem nas fábricas e torna-se a base para obtenção de bons resultados. Trabalhar nesse contexto me trouxe algumas percepções que gostaria de compartilhar. Não são verdades absolutas é claro, mas fazem muito sentido para mim:

Teorias e soluções são comprovadas com código

Uma coisa comum em projetos é que ao nos depararmos com um problema, teorizamos sobre as possíveis soluções. Soluções que podem ser desde um simples design de classes até um projeto secundário que vai revolucionar o mundo. A questão é: Documentos e diagramas aceitam qualquer coisa, o código não.

Nenhuma solução é válida até que se prove sua viabilidade no código. Felizmente, na área de desenvolvimento o custo para se criar uma prova de conceito não é alta. Podemos passar trinta minutos discutindo possíveis soluções para um problema em um quadro branco ou folha de papel e já partir para construção do seu código.

Prolongar o tempo da solução fora do código é prejudicial, pois somente o código fornece o feedback necessário para uma avaliação. Na prática, o ideal é ficar o menor tempo possível com uma solução fora do código.

O código trás resultados. Documentos não.

Sabe o que você consegue quando gasta tempo confeccionando documentos e diagramas? Documentos, diagramas e nenhum software funcionando. Em um contexto no qual o objetivo é conseguir o software funcional rápido, tudo que não for essencial deve ser descartado ou simplificado, pois não há tempo a perder.

Software não é um fim, mas sim um meio. O objetivo do time de desenvolvimento não é desenvolver um requisito, mas sim entender a necessidade do cliente e atendê-la com uma solução de software. Apesar dos conceitos parecerem semelhantes, na prática são completamente diferentes.

Artefatos válidos são artefatos úteis. A utilidade do artefato está na informação em si, não no seu formato ou nas assinaturas de aprovação do requisito no fim da página. Reduzir o tempo de confecção de artefatos e investir em codificação é certamente uma das melhores práticas para se obter resultados rápidos.

Nenhum documento diz mais sobre o software do que seu próprio código

Uma linguagem de programação é tão útil para registrar uma informação quanto qualquer outro documento, com a vantagem de nunca ficar desatualizada.

Geralmente, documentos são gerados para expressar regras de negócio que seriam difíceis de entender no próprio código, além de outras razões burocráticas. Meu ponto não é contra documentações, mas sim a favor de um código expressivo que não necessite de artefatos externos para ser compreendido.

É claro que, até o código ser produzido, podemos precisar de documentos auxiliares para expressar as regras que devemos codificar. Porém, depois de escrito, o código passa a ser a única referência confiável sobre aquela regra. Muitas empresas acreditam que uma boa documentação irá auxiliar na passagem de conhecimento entre programadores, mas nada é tão útil quanto um código expressivo e com testes unitários que não só expressem a intenção do código, mas também garantam que o mesmo está funcionando corretamente.

É possível ter um código expressivo. Investir na qualidade do código traz mais resultados do que gastar tempo na confecção de artefatos para traduzi-lo.

O código levanta questões sobre o domínio

Construir software é expressar através de código as coisas como elas de fato acontecem, ou seja, as imperfeições e indefinições do ambiente do cliente ficarão explicitas no momento da codificação, o que levanta a questão: O que fazer nesse momento?

A comunicação entre cliente e time de desenvolvimento não é uma via de mão única, sendo totalmente plausível existirem questionamentos sobre o processo do cliente, afinal, tudo é passível de melhoria.

O time de desenvolvimento não pode ser omisso ao encontrar deficiências no domínio.  Uma coisa que não funciona na vida real também não vai funcionar no software, podendo inclusive potencializar problemas que não eram tão evidentes quando o processo era feito manualmente.

Convenções e regras de criação de código podem auxiliar na detecção de falhas em um processo.

O código mostra o nível de experiência de um profissional

Não importa quantas certificações ou anos de experiência um profissional tenha. O código que ele produz é a uma das maiores evidências de sua competência.

Alguns minutos de codificação ao lado de um profissional dizem muito sobre ele. Essa percepção foi a grande responsável por introduzir técnicas como Pair Programming e Coding Dojos em processos de seleção.

Conclusão

Em um cenário em que a entrega de software funcionando é o maior objetivo, o código se torna o bem mais precioso do projeto. O código é capaz de provar teorias, mostrar a experiência de um profissional, documentar uma regra e ainda trazer propostas de melhoria para o ambiente no qual será inserido.

Algumas Referências

• Documentação Ágil – Por Vinicius Teles
• Modelagem Ágil – Por Rodrigo Yoshima
• Palestra sobre Modelagem Ágil no TDC 2008 – Por Manuel Pimentel