Danilo Sato

O post do rbp sobre “teste para ter menos o que testar” me inspirou a pensar um pouco sobre o assunto. Eu já percebi que muitos desenvolvedores têm medo de jogar código fora. É sempre aquela coisa: “Não, deixa comentado CASO a gente precise algum dia”. E é assim que a coisa começa. Com o tempo, você começa a ter trechos enormes de código comentado que você não sabe mais o que faz e prefere não mexer para não piorar. Se comentário no código é considerado desodorante, para mim código no comentário é mal-cheiro muito pior!




Por isso, está lançada a campanha antes chamada “Eu Não Tenho Medo de Jogar Código Fora”, que foi renomeada para anti-CC (Código Comentado) por sugestão do Julian. A nova sigla segue a filosofia “menos é mais” e evita eventuais problemas de censura se eu escolhesse duas letras de cada palavra :-)




Se você compartilha desse sentimento, deixe um comentário e espalhe a notícia! Vamos acabar com esse mal, que pode ser facilmente resolvido com um bom sistema de controle de versão, propriedade coletiva do conhecimento e um pouco de coragem. E tenho dito! :-)

Depois de recentes discussões sobre o assunto, achei interessante compartilhar algumas idéias sobre uma das práticas de XP: a Propriedade Coletiva de Código.




Uma das principais características nas definições da prática é o que podemos chamar de socialização do código. Não é que ninguém é dono do código, mas sim TODOS são responsáveis por TODO o código. Isso implica que a equipe não corre o risco de depender do “dono da classe” para fazer uma alteração ou melhorar uma parte do sistema. Se o “dono” ficar doente ou tirar férias, a equipe continua produzindo. Porém, como em toda metodologia ágil, essa prática pode precisar ser adaptada ao seu contexto.




O Giuliano me fez perceber hoje que minha definição da prática ia um pouco além do que descrevi acima. Acredito que a equipe tem muito mais a ganhar com o compartilhamento do conhecimento sobre o código. Poder alterar qualquer classe é importante, mas é muito melhor saber o que está acontecendo no sistema como um todo. É essa visão global que vai aguçar o “olfato” da equipe para identificar “maus-cheiros”.




Mas como esse compartilhamento de conhecimento acontece na prática? XP sugere outras práticas que podem ajudar, como Programação Pareada e Integração Contínua. Minha experiência me mostrou que analisar os logs e diffs entre as revisões do repositório também ajuda. Não vamos excluir também a comunicação face-a-face. No entanto, analisar logs e diffs nem sempre é uma tarefa trivial. Especialmente quando a equipe integra código novo várias vezes ao dia.




Outro dia estava discutindo exatamente sobre o mesmo assunto com o Julian e ele estava procurando por um meio mais eficaz de garantir que certas informações essenciais seriam lidas pelos outros programadores. Coisas do tipo: “Criei uma nova classe para encapsular o comportamento X. Usem essa classe a partir de agora”, “Novo padrão de código: cabeçalho alterado para incluir dados-extra. Alterar em todas as classes criadas/atualizadas a partir de agora” ou “Filtro de autenticação criado. Considerar esse aspecto ao criar novas funcionalidades”. Seria uma espécie de “Release Notes” das últimas alterações no repositório. Acredito que uma ferramenta poderia auxiliar os desenvolvedores na comunicação desse tipo de conhecimento. Eu gostaria de ver algo assim ao sincronizar minha cópia local do projeto.




E vocês, como lidam com esse compartilhamento de conhecimento técnico no seu projeto? Quais as adaptações que vocês consideram apropriadas para o seu contexto?