AdoptandoPropiedadDelCodigo
Escrito por Martin Fowler
Traducido por Jorge Ferrer
Revisado por Carmen Vidal
En la reciente entrada de mi bliki Propiedad de código (CodeOwnership), describí mi modo de ver diversos asuntos relacionados con quien es responsable del código. Muchos de mis amigos son practicantes de Extreme Programming (XP) y tienden a favorecer la propiedad colectiva del código. Sin embargo este tipo de prácticas no son absolutas y siempre deben ser tenidas en cuenta por las consideraciones del momento y lugar. Un de mis colegas me envió hoy una nota con la siguiente historia que he pensado que era un buen indicador de cuándo debes cambiar tus prácticas, incluso aunque seas un fan de XP. (Como este colega habla de su propio equipo, prefiere permanecer anónimo):
Yo cambié nuestro equipo de un modelo 'colectivo' a un modelo de propiedad 'débil' del código para contrarrestar la programación indisciplinada de un par de desarrolladores. Combinada con un poco de realimentación imparcial, el resultado fue una mejora de la velocidad dado que los desarrolladores que ahora “poseen” nuestras partes clave del código no están constantemente rehaciendo código de baja calidad, mientras que los que solían hacerlo se dedican a asuntos como búsqueda de defectos o cambios de código con poco riesgo – lo que libera tiempo del resto.
También ha supuesto un incremento de la moral, dado que todos menos los desarrolladores menos cualificados se sentían frustrados de tener que estar pendientes de cada uno de sus cambios en busca de defectos y arreglando los problemas que no descubrieron a tiempo. Este cambio premió a los que se tomaron en serio la calidad, TDD, la no especulación, etc.
Sin embargo, también hemos necesitado algunas prácticas y políticas adicionales para contrarrestar:
- Mayor frecuencia de cambio de parejas (nuestra política actual es que aún puedes trabajar en cualquier parte del código, pero si es en un área en la que no tienes total libertad, necesitas tener como pareja a quien sí la tiene, o confirmar en detalle tus ideas con ellos, antes de empezar.
- La forma de repetir es preguntando a los propietarios. Si se sienten cómodos con que tu código estará a la altura de las expectativas, podrás actuar con libertad de nuevo en esa parte del código.
- Si las cosas no mejoran, es necesario llevar a cabo pasos adicionales.
Este proceso ha sido muy educativo para mí, porque nunca había tenido que llegar tan lejos antes y fuí muy reticente de 'pasar a mayores'. Fué duro introducir una práctica que dirige en lugar de una que capacite, pero las cosas han mejorado mucho desde entonces.
Este tipo de adecuación a las circustancias propias es una parte esencial de Extreme Programming o cualquier método ágile. En condiciones normales mi colega aún prefiere la propiedad colectiva de código, pero las condiciones rara vez son normales.
