CodeOwnership—Propiedad de código
Solo yo debo tocar el código que me asignaron? Otros también? O todo el equipo?…¿Quién tiene la propiedad del código?
Una traducción del articulo Code Ownership de Martin Fowler
Hay varios formas de propiedad del código que he visto. En general, las clasificó en tres grandes categorías:
- Fuerte propiedad individual del código divide una base de código en módulos (clases, funciones, archivos) y asigna cada módulo a un desarrollador. Los desarrolladores solo pueden realizar cambios a sus módulos asignados. Si necesitan un cambio en el módulo de otra persona, deben hablar con el propietario del módulo para hacer el cambio. Este proceso se puede acelerar escribiendo un parche para el otro módulo y enviándolo al propietario del módulo.
- Débil propiedad individual del código es similar al de arriba, en que los módulos son asignados a los desarrolladores, pero diferente en que ellos pueden cambiar el código de los módulos que son propiedad de otras personas. Se espera que los desarrolladores tomen la responsabilidad de sus módulos asignados y vigilen los cambios realizados por otras personas. Si quieres hacer un cambio sustancial en el módulo de otra persona, tienes que hablar primero con el propietario del módulo.
- La propiedad colectiva del código abandona cualquier noción de propiedad individual de los módulos. El código es propiedad de todo el equipo y cualquiera puede realizar cambios en cualquier lugar. Puede considerarlo como si no existiera propiedad de código, aunque prefiero verlo como propiedad del equipo en vez de solo un individuo. (El término propiedad del código colectivo proviene de la Programación Extrema, aunque en la segunda edición se denomina Código Compartido).
De los tres el que realmente no me gusta es la fuerte propiedad del código. Hay demasiadas situaciones en las que algo que se necesita hacer requiere cambios en el código de otras personas. Persuadirlos a hacer el cambio y esperar el cambio a menudo toma tanto tiempo que conduce a retrasos y problemas más profundos, esto es particularmente irritante cuando el cambio es simple.
Un buen ejemplo de un simple cambio que causa problemas es cambiar el nombre de un método público. Las modernas herramientas de refactorización pueden hacerlo de forma segura con métodos públicos utilizados ampliamente. Pero esto viola la propiedad del código si es que se atraviesa el límite de un módulo. En esencia, usted ha convertido todas las interfaces entre desarrolladores en Interfaces Publicadas , con todas las sobrecargas de atención necesarias para cambiar.
Aún peor es cuando deseas hacer un cambio en la implementación, pero como no lo puedes obtener lo suficientemente rápido, tienes que hacer una copia del código, llamar a la copia del código desde tu módulo y hacer el cambio. Por supuesto que tienes la intención de resolver este desorden más tarde (no?).
La propiedad de código débil es una buena manera de mitigar estos tipos de problemas. La gente puede hacer cambios libremente, el dueño del código sólo tiene que mantener puesto un ojo a estos cambios.
La elección entre propiedad débil y colectiva tiene más que ver con la dinámica social del equipo. Ambas parecen funcionar, y fracasar, igualmente. Personalmente prefiero la dinámica de un equipo con propiedad de código colectiva, particularmente en el contexto de la Programación Extrema.