“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, no qual 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 é alto. 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 traz 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 as 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 quantos 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
De 0 a 10, o quanto você recomendaria este artigo para um amigo?