Danilo Sato

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?