CODIFICACIÓN (coding)

27

 Spike Solutions

Crear soluciones de punta para averiguar las respuestas a difíciles problemas técnicos o de diseño. Una solución pico es un programa muy sencillo de explorar posibles soluciones. Construir el pico sólo aborda el problema objeto de examen y pasar por alto todas las demás preocupaciones. La mayoría de los picos no son lo suficientemente buenos para mantener, por lo que se espera desecharlo. El objetivo es reducir el riesgo de un problema técnico o de aumentar la fiabilidad de la estimación de una historia de usuario.

Cuando una dificultad técnica amenaza con retrasar el desarrollo del sistema de poner un par de desarrolladores en el problema durante una semana o dos, y reducir el riesgo potencial.

 Refactorizar

Usualmente los programadores de computadoras nuestros se aferran a sus diseños de software mucho después de que se han convertido en difícil de manejar. Seguimos en utilizar y reutilizar el código que ya no es fácil de mantener, ya que todavía funciona de alguna manera y que tienen miedo de modificarlo. Pero ¿es realmente rentable para hacerlo? Extreme Programming (XP) mantiene la postura de que no lo es. Cuando eliminamos la redundancia, eliminar la funcionalidad sin uso, y rejuvenecer los diseños obsoletos estamos refactorizando. La refactorización se realiza a lo largo de todo el ciclo de vida del proyecto y ahorra tiempo y aumenta la calidad.

Entonces es necesario Refactorizar sin temores para mantener el diseño simple sobre la marcha y para evitar el desorden y la complejidad innecesaria para mantener su código limpio y conciso por lo que es más fácil de entender, modificar y ampliar.

28 fases de un proyecto de XP requieren la comunicación con el cliente, preferiblemente frente a frente (in situ). Lo mejor es simplemente asignar uno o más clientes al equipo de desarrollo. Es necesario tener cuidado, sin embargo, porque se pueden tener dificultades cunado se asignan por parte del cliente a alguien principiante.

Las Historias de Usuario son escritas por el cliente, con los desarrolladores para ayudar, para permitir que las estimaciones de tiempo, y asignar prioridades. Los clientes ayudan a asegurar que la mayor parte de la funcionalidad deseada del sistema está cubierto por las historias.

 El Código debe estar escrito de acuerdo a estándares

El código debe tener el formato de estándares de codificación acordados. Los estándares de codificación mantienen el código consistente y fácil para todo el equipo.

 Codificar primero las pruebas unitarias

Al crear sus pruebas primero, antes del código, le resultará mucho más fácil y más rápido al desarrollador para crear su código. La creación de una unidad de prueba ayuda a un desarrollador para considerar realmente lo que hay que hacer. Si creamos nuestras pruebas de unidad primero entonces sabremos cuando se ha terminado, cuando en la unidad a prueba todos las características pasan.

 Programación en parejas

Todo el código que se enviará a la producción es creada por dos personas que trabajan juntas en un solo equipo. La programación en parejas incrementa la calidad del software sin impactar en el tiempo para la entrega. Es contrario a la intuición, pero 2 personas que trabajan en un solo equipo agregará tanta funcionalidad como dos trabajando por separado, excepto que será mucho más alto en calidad. Con el aumento de la calidad tiene un gran ahorro en adelante en el proyecto.

29

 Instalar una computadora de Integración dedicada.

Un solo equipo dedicado al lanzamiento secuencial funciona muy bien cuando el equipo de desarrollo es co - localizado. Este equipo actúa como una muestra física para controlar la liberación. Los desarrolladores tienen una fuente para el arbitraje final sobre los problemas de integración. El ordenador permite a los desarrolladores para ver cuál es el lanzamiento y cuándo. Cuando el equipo de lanzamiento está ocupado otros cambios pueden ser lanzados, se garantiza la estabilidad.

El último conjunto de pruebas de unidad combinada se puede ejecutar antes de liberarla. Debido a que una sola computadora se utiliza el conjunto de pruebas está siempre al día. Si las pruebas de unidad funcionan a 100 % se confirman los cambios, si no logran los cambios se depuran.

 Usar la Propiedad Colectiva

La Propiedad Colectiva del código anima a todos a contribuir con nuevas ideas para todos los segmentos del proyecto. Cualquier desarrollador puede cambiar alguna línea de código para agregar funcionalidad, corregir los errores, mejorar los diseños o refactorizar.

Una sola persona no se convierte en un cuello de botella para los cambios. Esto es difícil de entender al principio porque es casi inconcebible que un equipo entero puede ser responsable del diseño del sistema. Además la propiedad colectiva del código propicia el entrenamiento cruzado (Cross training) de este modo se evitan las denominadas “Islas de conocimiento” que puede demorar el desarrollo del proyecto por indisposiciones de los miembros del equipo o en general por problemas externos que afecten a los miembros. A continuación en la Figura 2.7 se muestra el esquema de la Propiedad Colectiva del Código para un proyecto XP desarrollada por Don Wells⁶.

6 Autor de la página www.extremeprogramming.org

30 Figura 2.7: Propiedad colectiva del código

Fuente: Extreme Programming ORG.

Elaboración: Estreme Programming ORG.