Como o usuário participou de todo o planejamento, especialmente como coautor das User Stories, ele deve estar sempre disponível (Customer Always Available) durante o processo de codificação, a fim de sanar eventuais dúvidas que possam surgir e colaborar com sugestões.
A equipe de desenvolvimento deve concordar com os Coding Standards (padrões de codificação) que serão utilizados, preferencialmente baseando-se em experiências de comprovado sucesso anterior. Todas as linguagens e frameworks de programação modernos possuem um ou mais padrões de codificação sugeridos, publicados na web. O livro Código Limpo – Habilidades Práticas do Agile Software, de Robert C. Martin (o Uncle Bob) é uma excelente referência para a ampla adoção e acordos sobre padrões de codificação.
Uma regra que sempre gera alguma surpresa (e até polêmica) é a do TDD, Test Driven Development, o desenvolvimento baseado em testes, que estabelece que os testes devem ser definidos e codificados antes mesmo que uma classe e suas funções, que serão testadas, estejam escritas. A atitude de pensar nos testes que serão feitos já refina a codificação e contribui para a eliminação prematura de possíveis erros.
Os desenvolvedores devem trabalhar em pares (Pair Programming). O resultado prático é uma programação mais criativa, clara e menos sujeita a erros. Por incrível que possa parecer, a produtividade também é maior quando se tem dois programadores trabalhando ao mesmo tempo no mesmo código, além de ser mais fácil disseminar o conhecimento entre técnicas e projetos trocando-se os pares de tempos em tempos. No XP, a propriedade do código é coletiva (Collective Code Ownership); dessa forma, todos compartilham o mesmo orgulho e as mesmas críticas.
A otimização do código deve ser feita por último (Optimize Last) e apenas quando for necessária. Não tente resolver gargalos antes que eles apareçam. Lembre-se de que o preço do hardware é muito menor do que era há dez anos, ao passo que as horas de bons desenvolvedores estão mais caras. Pondere se não é mais barato aumentar o espaço de armazenamento ou comprar processadores mais rápidos – estejam eles fisicamente em seu ambiente ou na nuvem – do que pagar um mês de um DBA para otimizar a base de dados.
A última regra da Codificação é No Overtime – sem horas extras. Em XP, o dia é de oito horas e a semana, de quarenta horas, no máximo. Dessa forma é que os projetos devem ser dimensionados. Por mais que às vezes seja difícil afastar um programador de uma tarefa que ele faz com prazer, isso deve ser feito. A prática mostra que a produtividade diminui e a quantidade de erros aumenta quando se trabalha demais: existem limites que, antes de qualquer coisa, são limites físicos. Mesmo que o programador sinta-se compelido a continuar trabalhando, ele deve abandonar a codificação e concentrar-se na documentação e no planejamento. Apresente para a equipe jogos que possam ser jogados coletivamente. Xadrez é uma boa ideia. Nerds gostam de coisas “vintage”.
