Uma decisão fundamental na construção e administração de um time de desenvolvimento é o acordo relativo à propriedade de código: quem trabalhará em que código; qual o tamanho do trabalho a se fazer e se ele deve ser distribuído pelo time; e quem será responsável pela qualidade do software. A abordagem que você adotar terá impacto imediato no desempenho e no sucesso do time, assim como um impacto de longo prazo na forma e na qualidade do código.

Martin Fowler descreve três diferentes modelos de propriedade de código em um time:

• Propriedade estrita de código – todo módulo é exclusivamente de propriedade de alguém, desenvolvedores podem apenas mudar o código que é deles e, se precisarem alterar o código de outra pessoa, precisam conversar com o dono do código e fazer com que ele concorde primeiro – exceto talvez em emergências.
• Propriedade restrita de código – os módulos ainda são atribuídos a mantenedores, mas desenvolvedores podem modificar o código de outras pessoas. Espera-se que os mantenedores mantenham a atenção a qualquer mudança que outras pessoas façam, e que os desenvolvedores primeiro peçam permissão antes de realizar mudanças no código de alguém.

Isso pode ser visto como um modelo de propriedade compartilhada, no qual um indivíduo é obrigado a compartilhar a propriedade de seu código com outros; ou Comissariado de Código, em que o time possui todo o código, mas apenas uma pessoa é responsável pela qualidade de um código específico e por ajudar outros a efetuar mudanças nele, revisando e aprovando todas as grandes mudanças, ou pareando com outros desenvolvedores quando necessário. Brad Appleton diz que o trabalho de um comissário de código não é realizar todas as mudanças em um trecho de código, mas “salvaguardar a integridade/consistência do código (tanto conceitual, quanto estruturalmente) e de disseminar amplamente a outros o conhecimento e o expertise relativo ao código.

• Propriedade coletiva de código – a base de código é compartilhada pelo time todo, e todos são livres para efetuar qualquer mudança que eles precisem – ou queiram – fazer, incluindo refatoração ou reescrita do código que outra pessoa escreveu originalmente. Este é um modelo que veio do Extreme Programming (XP, ou Programação Extrema, uma “metodologia” de programação ágil), no qual o time inteiro é responsável pela qualidade e a integridade do código e por entender e manter o design.

Argumentos contra a propriedade estrita do código

Fowler e outros defensores do XP, tais como Kent Beck, não apreciam uma forte propriedade individual do código, porque ela cria barreiras e dependências artificiais dentro do time. O trabalho enguiça e se você precisa esperar que alguém faça ou mesmo aprove uma mudança, e o “dono de um código” pode se tornar, com frequência, o caminho crítico para todo o time. Isso pode encorajar os desenvolvedores a contornar o problema de outras formas, efetuando gambiarras. Por exemplo, em vez de mudar uma API da forma apropriada (o que envolveria alterar o código de alguém), eles podem enfiar a mudança em algum lugar existente. Ou eles talvez façam uma cópia do código de alguém e acrescentem as mudanças que precisam, tornando a manutenção mais difícil no futuro.

Outros argumentos contra a propriedade estrita são que ela pode levar à defesa e protecionismo excessivos por parte de alguns desenvolvedores (“ei, não toque no meu código!”), em que eles tomam qualquer crítica em relação ao código como um ataque pessoal, criando uma tensão no time e desencorajando esforços de refatoração além de exagerada otimização em determinadas partes do código – é o caso de desenvolvedores que passam tempo demais aperfeiçoando seu precioso código e não pensam no quadro mais amplo.

E é claro que há o fator “atropelado por um trator” – o impacto que uma pessoa que deixa o time exerce sobre a produtividade geral, caso ela seja a única que trabalhe com aquele trecho de código.

Ward Cunningham, um dos autores originais do XP, também acredita que há mais orgulho em relação ao código quando ele é compartilhado, porque o trabalho de todos está sempre visível para o restante do time.

Argumentos contra a propriedade coletiva de código

Mas também há argumentos contra a propriedade coletiva de código. Um artigo de Mike Spille lista alguns dos problemas que ele já testemunhou em times que tentam compartilhar “excessivamente” seus códigos:

• Inconsistência. Não há uma arquitetura discernível, apenas soluções individuais para problemas individuais. Muitos esforços duplicados, quase sempre levando a um comportamento inconsistente.
• Bugs. Pessoas “refatorando” código que elas não compreendem e quebrando o funcionamento do código original.
• Rodadas constantes de “a culpa é dele”. Pessoas têm uma inclinação para atitudes estúpidas frente aos bugs, dizendo: “Funcionava quando eu escrevi, mas desde que o Joe refatorou… então isso é problema dele agora”.
• Desenvolvimento lento. Ninguém tem expertise em nenhuma área, então as pessoas passam mais tempo tentando entender o código de outras pessoas do que escrevendo código novo.

Matthias Friedrich, em Thoughts on Collective Code Ownership, acredita que código compartilhado só funciona se você tiver o ambiente com as condições certas:

• todos os membros do time possuem um nível semelhante de conhecimento.
• os programadores são cuidadosos e confiam uns nos outros.
• a base de código está em bom estado.
• testes unitários estão sendo utilizados para detectar problemas nas mudanças (embora testes unidades não cheguem além disso).

Lembre-se de que a propriedade coletiva de código veio da Programação Extrema. Modelos bem-sucedidos de propriedade de código dependem de que todos compreendam a área e a arquitetura e mantenham um alto nível de disciplina técnica: não apenas escrever bons testes automatizados, como uma forma de se prevenir contra mudanças indesejadas, mas que todos sigam as mesmas convenções de consistência de código e padrões de desenvolvimento em toda a base, ao trabalhar pareado, pois, com sorte, um dos dois conhecerá o código – ou, pelo menos, duas cabeças podem pensar melhor do que uma e se ajudarem mutuamente, cometendo assim menos erros.

Outro problema com a propriedade coletiva de código é que a propriedade é compartilhada entre muitas pessoas. Justin Hewlett fala sobre o problema da Tragédia dos Commons: as pessoas irão cuidar do seu próprio quintal, mas quem irá aparar a grama do parque, ou da rua – mesmo que elas caminhem pelo parque ou pela rua todos os dias? Se o código pertence a todos, sempre há “outra pessoa” que pode cuidar disso – seja lá quem for essa outra pessoa. Como desenvolvedor, você está sob pressão e pode nunca mais tocar naquele trecho de código de novo, portanto, por que não fazer o que você precisa fazer o mais rápido possível e passar para o próximo item da lista, deixando para a “outra pessoa” a preocupação de fazer a refatoração ou escrever um teste unitário extra ou…?

Propriedade de código no mundo real

Sempre trabalhei em times que seguiam um modelo dos extremos (coletivo ou estrito) de propriedade de código, exceto por um experimento em XP e propriedade coletiva puros, em um time em que trabalhei há mais de 10 anos. Uma (ou talvez duas) pessoa(s) são responsáveis por diferentes trechos de código e fazem todo, ou quase todo o trabalho pesado relativo àquele código. Porque só faz sentido que a pessoa que melhor entende o código seja aquela que faz a maior parte do trabalho, ou o trabalho mais importante. Não se trata apenas de querer o trabalho “feito direito” – às vezes, não há outra opção quanto a quem vai fazer o trabalho.

Como Ralf Sudelbucher aponta, o modelo coletivo supõem que todo o trabalho no código pode ser repassado através do time, o que nem sempre é verdade.

Algumas tarefas nem sempre podem ser passadas para outras pessoas por conta da tecnologia: diferentes partes do sistema podem ser escritas em diferentes linguagens com diferentes arquiteturas. Você terá que aprender a linguagem e o framework antes que possa começar a entender os outros problemas que precisam ser resolvidos.

Ou talvez seja por causa da área do problema. É claro que sempre há código em um projeto que precisa apenas “ser digitado”: trabalho rotineiro que é bem compreensível, como uma estrutura básica, outro formulário web, uma tela simples ou a conversão de um formato de arquivo que qualquer um que está no seu time há algum tempo sabe onde encontrar as coisas pode fazer (ou parear com alguém que saiba).

Mas há outros tipos de trabalhos de desenvolvimento que envolvem a solução de difíceis problemas e técnicas que necessitam de muito tempo para que haja uma compreensão apropriada – o que pode levar dias, semanas, meses ou mesmo anos de imersão no contexto do problema para que você tenha conhecimento o suficiente para saber o que fazer. Não é possível simplesmente chegar e começar a “codar”: nem mesmo parear resolveria muito o problema, nesses casos.

O pior desastre acontece quando você coloca aprendizes para fazer o trabalho que eles não entendem. Em um projeto comum, nem todo mundo pode aprender tudo – exceto em alguns lugares bem maduros, onde houve poucas mudanças estruturais no mercado nas últimas uma ou duas décadas. Jim Coplien, Code Ownership

Conheci uma pessoa que gerencia um time de desenvolvimento de um grande estúdio de animação computadorizada. Seu time tem alguns desenvolvedores experientes que fizeram seus doutorados e pós-graduações em animação de cabelos – é só isso que eles fazem. E, mesmo que você seja muito inteligente, precisará de anos de estudo e experiência só para entender como eles fazem o trabalho deles.

Muitos redutos científicos e de engenharia também funcionam assim – talvez não sejam tão especializados, mas eles envolvem um trabalho não-trivial que pode não ser fácil ou competentemente realizado por generalistas, mesmo que sejam generalistas competentes. Programação de equipamento médico, aeroespacial, robótico, de controle bélico ou qualquer tipo de área de negócio em que você está trabalhando na fronteira da resolução de problemas, aplicação de modelos avançados de estatística, supercomputação e computação de alta escala e programação paralela, escrever kernel de sistemas operacionais, resolver problemas de criptografia ou fazer um trabalho muito bom no projeto de experiência do usuário (UX). Nem todo mundo conhece os problemas que precisam ser resolvidos, nem todo mundo se interessa por esses problemas e pode fazer um bom trabalho com eles.

Fazer a coisa certa

Se você quer fazer a coisa certa, ou precisa que ela seja feita direito pela primeira vez, deve considerar alguém que já trabalhou no código antes e provou sua capacidade para o trabalho. Não alguém que possui uma familiaridade superficial com ele. Pesquisas feitas pela Microsoft e outros demonstraram que quanto mais pessoas mexem num determinado trecho de código, maiores as chances de erros e desentendimentos – e que as pessoas que fizeram a maior parte do trabalho em um trecho de código são aquelas menos propensas a cometerem erros.

Fowler volta ao assunto em “Shifting to Code Ownership”, onde ele compartilha uma história de um colega que mudou do modelo coletivo para o de propriedade restrita, porque programadores menos experientes estavam cometendo erros em partes fundamentais do código e impactando na qualidade, na velocidade e na moral do time. Eles trocaram o modelo de forma que todos pudessem trabalhar na base de código, mas, caso precisassem mexer no “core”, precisariam fazer isso com a ajuda de alguém que conhecesse bem aquela parte do código.

Ao decidir pelo modelo de propriedade, será preciso pesar flexibilidade e qualidade, coletivo e individual. Com propriedade individual, você pode ter problemas como “silos fechados” e dependência de algumas pessoas-chave, e precisará estar atento a eventuais evasões, mas pode ser que consiga fazer mais e mais rápido com menos gente.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2013/04/code-ownership-who-should-own-code.html