Já ouviram falar na expressão em inglês “Code Ownership”? Este termo é utilizado quando um determinado desenvolvedor é definido como “proprietário” de um código ou módulo do software, ou seja, o desenvolvimento ou manutenção só é realizada por este desenvolvedor em particular. Apesar de comum, manter desenvolvedores como proprietários de código pode ser arriscado e evita o compartilhamento de conhecimento. Acompanhe.
O Code Ownership, originalmente, foi elaborado como um conceito válido no desenvolvimento de software e ainda é utilizado nos dias atuais. Desenvolvedores são propositalmente atribuídos a módulos individuais do software como um mecanismo de “capacitação residente”. Desse modo, a evolução e a correção destes módulos tornam-se mais rápidos e acurados devido ao conhecimento avançado do desenvolvedor proprietário.
Imagem via Shutterstock
No entanto, algumas vezes, o Code Ownership é introduzido implicitamente na equipe quando ninguém decide assumir o módulo e o empurra para outros desenvolvedores. Por exemplo, quando é necessário realizar uma manutenção em um módulo específico, principalmente se for complexo, o Code Ownership emerge em frases como:
“Foi o João quem desenvolveu este módulo. Como ele já o conhece, é a pessoa ideal para assumir o trabalho.”
Ou então:
“O José foi o último desenvolvedor que fez uma correção nesse módulo. Ele já está por dentro de como funciona. Passe para ele!”
Convenhamos: isso já se tornou uma tradição nas empresas de desenvolvimento de software, não é? 🙂
A princípio, essa “fuga” do código-fonte é uma situação péssima. Se isso ocorre, há algo muito errado com a equipe ou com o código-fonte. Eu aposto as minhas fichas na segunda probabilidade. Quando o código está deteriorado, de difícil interpretação ou é um local crítico na arquitetura do software em função das dependências, qualquer um deseja passar longe mesmo…
Para esclarecer melhor, existem três níveis de propriedade de código. O primeiro, conhecido como “forte propriedade do código” (Strong Code Ownership), se refere à atribuição intencional de um código a um desenvolvedor, como citado no início do artigo. Algumas empresas decidem adotar esse nível para qualificar desenvolvedores em segmentos específicos no software e garantir entregas rápidas. Em um ambiente favorável, este nível pode trazer bons resultados.
O segundo nível, oposto ao primeiro, é definido como “fraca propriedade do código” (Weak Code Ownership). Como a própria definição sugere, desenvolvedores são alocados em módulos específicos, mas não assumem a total propriedade do código. Outros desenvolvedores recebem a liberdade de expandir ou modificar o módulo, desde que o proprietário seja informado. Por sua vez, o proprietário deve acompanhar as alterações realizadas para manter-se atualizado das novas funcionalidades, bem como identificar possíveis revisões e impactos, caso necessário.
Antes de prosseguir, vale refletir sobre os níveis acima: o que acontece quando o proprietário do código sai de férias ou é desligado da empresa? A situação é visível: como os outros desenvolvedores têm pouco (ou nenhum) conhecimento sobre o código, as próximas implementações provavelmente serão comprometidas! Um novo desenvolvedor pode ser atribuído como proprietário, mas, mesmo assim, levará um tempo considerável para que ele compreenda o código e as regras de forma suficiente para assumi-las. Enquanto isso, as alterações ficam praticamente congeladas.
Diante dessa reflexão, nos deparamos com o terceiro nível de propriedade no código que, na verdade, consiste em uma “propriedade coletiva” (Collective Code Ownership). O código ou módulo deixa de ser individual e passa a ser compartilhado com toda a equipe, portanto, todos podem realizar as alterações solicitadas. Para promover este conhecimento mútuo sobre os módulos do software, a equipe pode organizar eventos de demonstração do código e das funcionalidades, conhecidos como workshops. No Scrum, esse evento pode ser encaixado durante a reunião de retrospectiva.
Na minha opinião, o terceiro nível é o ideal. Evitar a propriedade do código agrega conhecimento sobre as funcionalidades do software, dissemina a compreensão das regras de negócio e colabora para uma distribuição mais precisa de tarefas entre a equipe, além de eliminar o cenário de “fuga” do código. Apenas para efeito de conhecimento, Collective Ownership é uma das práticas abordadas no eXtreme Programming! Agora a minha preferência ficou mais clara, não é? 🙂
Fico por aqui, pessoal!
Um grande abraço a todos e lembrem-se: compartilhe a propriedade do seu código!
Originalmente publicado em Blog André Celestino
