View
150
Download
0
Category
Preview:
Citation preview
¿Qué vamos a contar?
● Metodología Ágil: Scrum● Test Driven Development (TDD)● Control de versiones
● Preguntas
Tareas
● Tipo○ Bugs○ Historias○ Improvements
● Historias desde un punto de vista● Bugs describen el problema
Reunión Scrum diaria
● Hora fijada, 9:15am● De pie● Cada uno:
○ ¿Qué hice ayer?○ ¿Qué voy a hacer?○ Problemas
● Burndown
Demo
● Viernes a la tarde● Compilar alphas de antemano● Tarde: 1€/5 min
● Demostrar bugs● Demostrar tareas● Agrupar por funcionalidad● Apuntar nuevos bugs● ¡Cuidado con alargarse!
Planificación de Sprint
● Reordenar tareas● [Planning poker]● Valoramos los bugs: cantidad y dificultad● Elegimos cuánto entra
Planning Poker
● Leemos el nombre de la historia● Explicamos su alcance
○ Surgen preguntas interesantes● Estimación individual● Discusión de discrepancias● Acuerdo
¿Porqué?
Al principio usábamos TDD siempre que podíamos
● Inexperiencia○ Al plantear los tests○ En el lenguaje de programación
Tips (Do's & don'ts)
● Abusar de los mocksa. Los test se vuelven tediosos de mantenerb. Acabamos probando el resultado de los mocks en
lugar del SUTc. Probablemente la clase a implementar tenga
demasiados parámetros.
Tips (Do's & Don'ts)
● Hacer tests de implementaciones concretas en lugar de guiarnos por las especificaciones○ Suele ocurrir cuando hacemos tests después de
implementar○ Por ejemplo: si una clase realiza acciones sobre un
Collection, no hacer los tests asumiendo que
recibiremos un ArrayList. Podríamos recibir un
TreeSet y debería funcionar (Principio de sustitución de Liskov)
Tips (Do's & Don'ts)
● Otras malas prácticas:
○ Introducir dependencias entre tests○ "Romper" las reglas para maximizar la cobertura de
los tests (ej: comprobar métodos privados)○ Limitarse a probar los resultados esperables. Las
excepciones y los casos límite son importantes.○ No refactorizar las clases de tests unitarios.
Lecciones positivas
Aplicar los principios del TDD en el día a día nos ha enseñado valiosas lecciones
● Buenas prácticas de desarrollo○ Principios SOLID
● Criterios de nombrado de clases, métodos…
● El valor de hacer refactor● Un estilo de programación común
En definitiva...
● TDD es una herramienta de trabajo○ Bien usado ayuda a escribir buen código y facilita
su mantenimiento○ Usado en exceso da lugar a problemas y se
convierte en una carga● Si una herramienta resulta una carga, no
hay que temer en abandonarla
¿Cuándo usaríamos TDD?
Librerías/APIs● Código estable con pocos cambios en el
futuro● Documentación para el cliente
Nuevos proyectos● Utilidades: clases de peticiones a red, base
de datos, helpers...
Trabajo en equipo
● Modelo de ramas git-flow
● Adaptado○ Desarrollo: «3.5.x»○ Maintenance: «3.4.x-
maintenance»○ Cada funcionalidad
una rama: «feature/user-list»
Trucos
● git merge --no-ff○ Preserva la estructura de
ramas○ Por defecto git aplasta
(squash) los commits● git rebase -vip
○ [v] Verbose○ [i] Previsualizar y modificar
qué commits se aplican○ [p] Conservar el árbol de
commits
● gitx○ Interfaz visual
● git mergetool○ Indispensable para resolver
conflictos● git commit --amend
○ Arregla el último commit○ Añadir cambios olvidados○ Cambiar el nombre del commit
Trucos
● git cherry-pick○ Intenta aplicar los cambios de un commit
cualquiera○ Útil para aplicar un parche de una rama a otra
● git blame○ ¡WTF! ¿Quién ha hecho semejante burrada?○ Quién, cuándo y en qué commit se cambió
cada línea
Trucos
Trucos
git config --global alias.hist "log --color --graph --pretty=format:'%Cred%h%Creset |%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
git hist
?¿?
?
¿ ?
¿?
¿?
?
¿
¿ ?
?¿??
??
¿
?
?
¿?
?¿?
¿
?¿
???
¿
¿?
?
Preguntas
Descarga: bit.ly/quomai-agile-slides
Recommended