2 Propiedad Colectiva del Código

[[Nombre de la institución]]
Guía respecto a la Propiedad Colectiva del Código.
[[fecha]]
Versión 1.0
[[Nombre del proyecto]]
1
1.1
Introducción
Propósito del documento
<Insertar los propósitos particulares del documento para la institución>
Cualquier miembro del equipo desarrollador podrá cambiar una línea de código para añadir
funcionalidad o eliminar algún tipo de error.
El documento presentado a continuación establece la filosofía de esta práctica como una guía para
que [[institución]] la pueda implementar de forma fácil al aplicar la programación extrema como
metodología de desarrollo.
Para profundizar en la guía se recomienda leer el documento: Guía_Propiedad_Colectiva.doc
2
Propiedad Colectiva del Código
Dentro de la programación extrema el código es una propiedad colectiva compartida por todos los
miembros del equipo de desarrollo. Según lo anterior, cualquier desarrollador puede cambiar
cualquier línea de código, añadir funcionalidad, arreglar fallos o aplicar refactoring.
Esta forma de trabajo debiera animar a todos los miembros del equipo de desarrollo de
[[institución]] a contribuir y aplicar refactoring con nuevas ideas en todos los apartados del
sistema, con lo cuál las personas dejarían de ser un cuello de botella en cuánto a la programación.
El objetivo fundamental de esta forma de trabajo es reducir al mínimo las obstrucciones para
distribuir e implementar rápidamente las tareas de programación. Adicionalmente, es un recurso
muy efectivo para evitar los problemas de cambio de personal.
Esta filosofía puede resultar difícil de comprender al principio. Es posible que para miembros del
equipo de desarrollo de [[institución]] sea inconcebible que todos ellos puedan responsabilizarse
del sistema, viendo imposible que se pueda llegar a buen término sin un jefe visionario de la
arquitectura del mismo. Bajo esta perspectiva clásica es fácil que un jefe de proyecto responda a
una pregunta sobre el sistema con una respuesta incorrecta. Responsabilizar a una sola persona
de la arquitectura del sistema hace que el resto del equipo no se beneficie de la visión del sistema
que el arquitecto mantiene en su mente.
Mantener bajo control [Nombre del Proyecto]] dentro de un contexto de propiedad colectiva, en
el cuál todo el equipo tiene capacidad de decisión se puede realizar a través la comunicación, las
pruebas unitarias y la integración frecuente. Dentro de la XP la comunicación en el equipo de
desarrollo es fundamental para que todos sus componentes trabajen en la misma dirección. Si a
esto se añade que todo el código del repositorio debe incluir pruebas de unidad, es posible lograr
que el conocimiento de la arquitectura del sistema sea distribuido sobre todos los miembros del
equipo, ya que cuando algún desarrollador modifica la funcionalidad del sistema el conjunto de
pruebas de unidad garantiza el sincronismo y la calidad del producto. Para completar lo anterior, la
integración frecuente permite que los posibles problemas generados por esta filosofía sean
detectados y corregidos de forma temprana.
[[Nombre del Proyecto]]
[[Nombre de la institución]]
Página 1 de 2
Guía respecto a la Propiedad Colectiva del Código
Versión 1.0
[[Autor]]
Uno de los efectos de la propiedad colectiva es que el código complejo no dura mucho tiempo
porque todo el mundo suele mirar todo el sistema y dicho código se encontrará tarde o temprano. Y
cuando se encuentre, alguien intentará simplificarlo. Si la simplificación no funciona, como
evidenciarán los fallos en las pruebas, entonces el código será desechado.
La propiedad colectiva tiende a prevenir también que sea introducido código complejo al sistema
desde el primer momento. Si se tiene conciencia que otro compañero pronto mirará lo que se está
escribiendo en ese momento, el desarrollador lo pensará dos veces antes de añadir una
complejidad que no pueda ser justificada inmediatamente.
Mediante una buena comunicación, pruebas de unidad e integración frecuente es posible eliminar
muchos de los problemas que puede generar la propiedad colectiva del código. Sin embargo,
todavía existen algunas situaciones derivadas de esta práctica que requieren actuaciones
complementarias por parte de [[institución]]:
1. Algunos desarrolladores pueden querer hacerse dueños del código y no permitirán
que otros lo modifiquen.
2. Como todo el mundo es responsable del código al final nadie es responsable del
mismo.
3. El conocimiento se encuentra distribuido, pero ningún miembro del equipo es lo
suficientemente experto.
4. Es difícil trabajar sobre el código fuente escrito por otro desarrollador.
3
Ventajas y desventajas de la propiedad colectiva
La propiedad colectiva del código tiene una serie de ventajas y beneficios como fue mencionado de
forma previa, algunas de ellas son las siguientes:





Ayuda a la integración, confiabilidad y creatividad en los equipos de trabajo.
Requiere y se esfuerza por un estilo y filosofía consistente para todo el sistema.
Maneja fácilmente el crecimiento y la contracción de los equipos.
Responde rápidamente a cambios o incrementos en los requerimientos.
Tiende a prevenir código complejo en la primera parte de construcción del sistema.
Como todo, también tiene su parte negativa que puede ser traducida en las siguientes desventajas:



La responsabilidad y los roles de las tareas puede ser difícil de establecer.
El sistema podría perder una arquitectura común, y su propósito inicial podría ser difícil de
alcanzar.
Existen posibilidades de realizar repetidos cambios de acuerdo a diferentes estilos
personales de programación.
[[Nombre del Proyecto]]
[[Nombre de la institución]]
Página 2 de 2