Num post recente, o Hugo Ribeiro fala de “Code Ownership”, assumindo-se como defendendo do que chama de “Strong Code Ownership“. Num dos livros mais interessantes que li nos últimos tempos, “Organizational Patterns of Agile Software Development”, de James Coplien e Neil Harrison, os autores descrevem e defendem o padrão “Code Ownership” (pp. 261-263):
– Something that is everybody’s responsibility is really no one’s responsibility.
– Each code module in the system is owned by a single Developer. Except in exceptional and explicit circumstances, code may be modified only by its owner. Anyone else that wants to make changes must approach the owner and get approval.
Este padrão aplica-se, recomendam os autores, a todo o tempo de vida de cada módulo de software, não terminando com a entrega do projecto ou produto.
Parece-me óbvio que a necessidade de recorrer a este padrão aumenta com a dimensão da equipa de desenvolvimento, e que os principais problemas estão relacionados com a existência de apenas uma pessoa com conhecimento sobre cada módulo específico: a) cada developer pode ser um bottleneck às alterações necessárias aos seus módulos (pode estar ocupado com outras tarefas); b) em casos de rotação de pessoal, corre-se o risco de perder o know-how sobre o módulo.
Os autores reconhecem estes riscos, e sugerem algumas abordagens para os minimizar: a utilização do padrão Code in Pairs (“Pair compatible designers. Together, they can work together to produce more than the sum of the two individually.“), uma técnica muito “XP”, ou a realização de inspecções de código. Sugerem também, para evitar bottlenecks, que em circunstâncias especiais o owner possa conceder autorização para realização de alterações a outros developers. Referem ainda que o dono do módulo pode ser um grupo de pessoas, com um líder designado (o arquitecto/chefe de equipa), o que pode ser especialmente interessante em projectos de maior dimensão.
Relativamente ao paralelo com o defendido por Kent Beck, nomeadamente a “collective code ownweship“, os autores respondem simplesmente com: “Ownership by everybody is really ownership by nobody.”
Na minha opinião pessoal, a utilização deste padrão (definido explícitamente ao nível de política dos projectos) faz todo o sentido, nem que seja pelas consequências da sua não utilização, ao nível da falta de controlo de alterações, modificação da lógica/desenho, convenções seguidas, ou até a simples violação de encapsulamento (neste caso ao mostrar a outros Developers como está desenvolvido o módulo).
jota
[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]
