Extreme Programming Practices. Pair-Programming, Collective Code Ownership, Frequent Integration

Transcripción

1 Extreme Programming Practices Pair-Programming, Collective Code Ownership, Frequent Integration

2 12 Prácticas de XP 4 Prácticas de Codificación: estándares, vocabulario, refactoring, diseño simple. 4 Prácticas de Desarrollo Adoptar TDD Practicar Pair Programming. Adoptar propiedad colectiva del código. Integrar contínuamente. 4 Prácticas de Negocio: cliente al equipo, planificar, versiones regulares, trabajo a paso sostenible.

3 12 Prácticas de XP

4 Pair Programming Todo código destinado a producción es creado por dos personas trabajando juntas en un mismo computador. PP mejora la calidad del software sin impactar la fecha de entrega. Es contra-intuitivo, pero dos personas trabajando juntas agregarán tanta funcionalidad como dos trabajando por separado, excepto que la calidad será mucho mayor. La mejor manera es sentarse uno al lado del otro frente al monitor. Uno teclea y piensa tácticamente en el método que se está escribiendo (driver), mientras el otro piensa estratégicamente cómo ese método calza en la clase (navigator). Se van rotando en los roles continuamente. Dentro del equipo, los pares cambian continuamente.

5 Pair Programming Ventajas: Mejora la calidad del software desarrollado, tanto a nivel de diseño y limpieza (simple design & refactoring), como de funcionalidad correcta (TDD). Conocimiento compartido: respaldo si un desarrollador se ausenta. Refuerzo de buenas prácticas de programación y uso de los estándares definidos por el equipo. Facilita el conocimiento colectivo del código (otra práctica XP).

6 Pair Programming Referencia por excelencia: Otros: Un ejercicio: PairDraw industriallogic.com/games/pairdraw.html

7 Collective Code Ownership Todo el código del sistema pertenece a todo el equipo. Responsabilidad compartida. Se evitan asignaciones personales, aún cuando en la práctica cada uno se focaliza en ciertos módulos. Si alguien requiere hacer un cambio a una clase, la puede hacer, pudiendo así conocerla. Obviamente, se soporta con TDD (pruebas unitarias). Reemplaza la dependencia de un arquitecto (quien igualmente puede tener una visión parcial e incluso errónea).

8 Collective Code Ownership Ventajas: Dado que todos conocen el código, fomenta el cumplimiento de estándares y de diseño simple. Fomenta refactoring: cuando alguien revisa código de otro, lo puede mejorar. Conocimiento compartido: respaldo si un desarrollador se ausenta. Fomenta la integración frecuente (otra práctica XP).

9 Frequent Integration Integrar nuevo código y tests al repositorio central apenas estén OK. Depende de estructura de control de código (version control). Las integraciones deben estar testeadas por desarrolladores. Los elementos integrados deben ser simples, de modo de siempre estar lo más cerca posible de la versión más actualizada funcionando.

10 Frequent Integration Ventajas: Evitar o disminuir procesos de integración tediosos cuando la frecuencia es baja. Evitar sorpresas de funcionalidades y/o diseño. Evitar desviaciones muy grandes cuando se realizan experimentos. Evitar los freezes : congelamiento de versiones para ser puestas en producción, perdiendo el potencial avance de los desarrolladores en funcionalidades importantes.

11 Version Control Repositorio que mantiene proyectos con su código fuente estructurado en los mismos módulos y jerarquía del proyecto. Funciones: Check Out. Check In. Show Differences. Get Current/Latest version. Manejo de vistas o workspaces (subconjuntos de código). Manejo de código en estructuras de árbol. Features: Control por usuario. Métricas.

12 Version Control Productos CVS, WinCVS (Code Version System) Visual Source Safe (Microsoft) SourceOffSite (SourceGear) aplic. cliente. VS Team System + Team Foundation Server (Microsoft). Perforce (P4).

13 Source Off Site

14 Daily Build El Daily Build es una compilación automática, diaria y completa del código completo de un sistema. Automática: porque se programa una compilación a una hora fija al día utilizando algún tipo de proceso calendarizado. Diaria: o aún más frecuentemente. Mientras más frecuente, más confiable. Completa: ya que es posible que el software tenga diferentes versiones. Versiones de múltiples lenguajes, o múltiples plataformas, o incluso versiones full y express o light. Hay que compilar todas las versiones y cada compilación debe partir desde cero, evitando la posibilidad de que el compilador juegue con compilaciones incrementales.

15 Daily Build Beneficios: Cuando se corrige un bug, los testers cuentan con una nueva versión rápidamente. Los desarrolladores pueden despreocuparse de preparar ellos las versiones de distintas plataformas y que sus cambios no romperán la compilación. Los cambios chequeados son más confiables y trazables. Roles externos (comercial, JP, ) siempre cuentan con la última versión disponible para demos. Al mantener un histórico de versiones, se pueden usar para rastrear un bug, descubriendo cuándo apareció. Permite rastrear el trabajo de los desarrolladores cuando un tester encuentra un error en alguna versión. Referencia: