PropiedadDelCódigo

Escrito por Martin Fowler
Traducido por Jorge Ferrer
Revisado por Carmen Vidal

Existen varios enfoques para afrontar la propiedad del código que se escribe. Yo las organizo en tres grandes categorías:

• Propiedad fuerte del código:divide el código fuente en módulos (clases, funciones, ficheros) y asigna cada módulo a un desarrollador. Estos sólo tienen permiso para realizar cambios en sus módulos. Si necesitan hacer un cambio en el módulo de otro desarrollador deben hablar con él para que lo realice. Este proceso puede acelerarse escribiendo un parche para el otro módulo y enviándoselo al desarrollador propietario.

• Propiedad débil del código: es similar al anterior en el sentido de que los módulos también son asignados a desarrolladores concretos, pero diferente en que también se permite que otros desarrolladores realicen cambios. Los propietarios de cada módulo deben tomar responsabilidad de los mismos revisando los cambios que otros realizan en ellos. Si un desarrollador quiere realizar un cambio sustancial en un módulo que no le ha sido asignado se considera conveniente hablar con el propietario antes de llevarlo a cabo.

• Propiedad colectiva de código:abandona por completo la noción de propiedad individual de los módulos. El código fuente es propiedad del equipo entero y todos pueden realizar cambios en cualquier parte. Puede considerarse este enfoque igual a no tener ningún tipo de propiedad de código, pero sus defensores prefieren poner el énfasis en la noción de propiedad por parte de un equipo en contraposición a propiedad por parte de un individuo. (El término propiedad colectiva del código, Collective Code Ownership en inglés, viene de Extreme Programming, aunque en su segunda edición se ha renombrado como Código compartido o Shared Code en inglés)

De los tres enfoques, el que no me gusta en absoluto es la propiedad fuerte del código. Hay demasiadas situaciones en las que se necesita cambiar el código de otro. Convencerle de hacer el cambio y esperar a que lo lleve a cabo, a menudo lleva tanto tiempo que provoca retrasos y problemas más profundos. Esta situación es especialmente desesperante cuando se trata de realizar un cambio sencillo.

Un buen ejemplo de un cambio sencillo que provoca problemas es renombrar un método público. Las herramientas modernas de refactorización permite realizar este cambio incluso en métodos públicos usados ampliamente. Pero esto viola la propiedad del código, si los cambios afectan a más de un módulo. En definitiva, se han convertido todas las interfaces entre desarrolladores en Interfaces Publicadas (PublishedInterfaces), con toda la sobrecarga de trabajo que eso implica al realizar un cambio.

Aún peor es cuando se quiere cambiar la implementación, así que, cuando no se consigue incorporar el cambio con la suficiente rapidez, se termina realizando una copia en el módulo que se posee e invocar esa copia, donde sí se ha realizdo el cambio. Por supuesto, la intención siempre es arreglar el desaguisado con posterioridad.

La propiedad débil del código es una buena manera de mitigar este tipo de problemas. Los desarrolladores pueden realizar cambios en el código libremente, pero el propietario debe estar atento a dichos cambios.

La elección entre la propiedad débil y la propiedad colectiva tiene que ver con las dinámicas sociales del equipo. Parece que las dos funcionan, y fallan, más o menos lo mismo. Personalmente me gusta más la dinámica de los equipos con propiedad colectiva – en particular en el contexto de Extreme Programming.
Artículo Original