Buenas Prcticas de

Metodologas giles
Rodriguez, Matas (rodriguezmatias@gmail.com)
Papp, Esteban (esteban.papp@gmail.com)
2
Agenda
>Manifesto gil
>PP
>Peer Review
>TDD
>Prototype Development
>Principios giles
>Refactoring
3
Manifesto gil
> Estamos poniendo al descubierto mejores mtodos para
desarrollar software
1. A los individuos y su interaccin, por encima de los procesos y las
herramientas.
2. El software que funciona, por encima de la documentacin exhaustiva.
3. La colaboracin con el cliente, por encima de la negociacin contractual.
4. La respuesta al cambio, por encima del seguimiento de un plan.
> Aunque hay valor en los elementos de la derecha, valoramos ms
los de la izquierda
Pair Programming
> Papp Esteban
5
PP (Pair Programming)
>Dos programadores, una mquina
Combinan esfuerzo de desarrollo en una sla estacin de trabajo.
Roles:
Driver
Navigator
>Cambio de roles y de pareja
Cambio de roles cada hora y cambio de parejas peridicamente.
>Origen en XP
Idea central en la metodologa XP.
6
PP XP
7
PP Pros y Contras
> Pros
Mejor cdigo
Dos cabezas piensan mejor que
una
Obligados a hacer lo correcto
Ms divertido
Tutora
Cohesin del equipo
Ms eficiente
Menos distracciones
Menos interrupciones
Mltiples desarrolladores
contribuyen al diseo
Cdigo ms compartido
> Contras
Desarrolladores
experimentados vs menos
experimentados
Diferencias de estilo
Diferencias en los horarios
Mtricas por programador
ocultadas
Diferente locacin
Remote PP
8
PP Costos y beneficios
The Costs and Benefits of Pair Programming Williams (Utah
University) and Cockburn (Humans and Technology ACM)
Peer Review
> Rodriguez Matias
10
Que es Peer Review?
> Es un proceso por el cual un producto (documento, cdigo) es
revisado por los pares con el fin de encontrar y remover
errores.
> Esta metodologa es til ya que distintas personas pueden
identificar mayor nmero de errores ms fcilmente.
> Por qu utilizarla?
Ayuda a encontrar errores rpidamente.
Asegura la calidad del producto revisado.
Transfiere el contenido del producto a los interesados.
COSTOS: Mientras ms rpido encontremos los errores ms barato ser
corregirlos.
11
Work Flow del proceso
Planificacion
Preparacion
Overview
Reunion
Proceso de
Mejora
Correccion
Seguimiento
Opcional
12
Algunos puntos claves
> El producto a revisar debe estar finalizado.
> El material debe estar disponible para los revisores.
> Es muy importante prepararse para la revisin: sino no tiene
sentido.
> El propsito de la revisin es encontrar errores pero NO
resolverlos.
> Las crticas son al producto y NO al autor.
> Aseguremos la calidad de nuestro trabajo.
Test Driven Development
> Papp Esteban
14
TDD (Test Driven Development)
>Desarrollo guiado por pruebas
>Tcnica de desarrollo donde primero se escribe el caso
de prueba y luego el cdigo necesario para pasar la
prueba.
>El desarrollo es orientado a pasar las pruebas.
Todo el cdigo es escrito para pasar las pruebas. Las pruebas son escritas
para cumplir requerimientos. Entonces todo el cdigo es escrito para
cumplir los requerimientos. No se escribe cdigo de ms.
>Origen en XP
15
TDD XP
16
TDD Ciclo
Agregar un test
Correr todas las
pruebas, ver cual falla
Escribir cdigo
Correr todas las
pruebas y ver que
ninguna falla
Refactorizar
desprolijo
?
17
TDD Reglas
1. No est permitido escribir ningn cdigo productivo al
menos que sea para pasar un caso de prueba fallido.
2. No est permitido escribir ms de un caso de prueba
que sea suficiente para fallar. Fallas de compilacin
son fallas.
3. No est permitido escribir ms cdigo productivo que
el suficiente para pasar un caso de prueba fallido.
18
TDD Beneficios y Limitaciones
> Beneficios
El programador est ms
preocupado por la interfaz
que por la implementacin
Pequeos pasos rpidos de
desarrollo
Todo el cdigo es probado
Gran cantidad de pruebas
escritas (nivel de confianza)
Reduce el costo de fix
Mejores diseos
(desacoplamiento)
Hace un minuto, todo
andaba!!!
Tests de regresin
Documentacin de uso
> Limitaciones
Debe complementarse con
otras tcnicas para asegurar
calidad.
TDD anti-patrones
Casos de Prueba incorrectos
producirn cdigo
incorrecto.
No puede utilizarse para
producir nuevos algoritmos
Es difcil de utilizar en
algunos escenarios
Prototype Development
> Rodriguez Matias
20
Prototype Development
> Tecnica mediante la cual se bosqueja la interfaz de usuario de
un sistema iterativamente:
Permite explorar el problema en conjunto con el cliente. Artefacto de
Anlisis.
Permite explorar el espacio de accin de nuestro sistema. Artefacto de
Diseo.
Una forma de publicacin de los diseos de interfaz de usuario.
Como posible inicio para el desarrollo. Artefacto de Implementacin.
21
Tipos de Prototipos
>Prototipo Evolucionario
Basado en tcnicas que permiten iteraciones rpidas.
La verificacin es imposible por que no hay especificaciones
La validacin se basa en la adecuacin del sistema.
>Prototipo Descartable
Utilizado para minimizar riesgos en los requerimientos.
El prototipo es descartado luego de ser utilizado.
El prototipo NO debe ser considerado por el cliente como el sistema
final.
22
Flujo de Trabajo
23
Beneficios
> Expone los malos entendidos entre los usuarios del sistema y
los desarrolladores.
> Expone funcionalidades que no se tuvieron en cuenta.
> Identifica funcionalidades confusas.
> Obtenemos una versin ejecutable ms temprano en nuestro
proceso
> El prototipo sirve como una entrada para la especificacin del
sistema.
> El prototipo puede evolucionar hasta convertirse en el sistema.
Principios giles
> Papp Esteban
25
Principios giles KISS
>KISS: Keep it simple stupid (Mantenlo simple,
estpido): principio que declara que la
simplicidad debe ser un objetivo clave.
Tendencia a complicar las cosas
Se encuentran soluciones a los problemas que no estn en el dominio
Se utiliza en todos los mbitos de la ingeniera
La solucin ms simple es generalmente la mejor
26
Principios giles YAGNI
>YAGNI: You aint gonna need it
(No lo necesitars), sugiere no
agregar funcionalidad hasta que no sea necesaria.
La tentacin de agregar cdigo no necesario actualmente pero posible en
un futuro tiene las siguientes desventajas:
El tiempo utilizado quita tiempo a las dems funcionalidades requeridas
(desarrolo, pruebas, etc)
Las nuevas funcionalidades deben ser debuggeadas, comentadas y
soportadas
Cada funcionalidad nueva impone restricciones sobre futuras
funcionalidades
Hasta que la funcionalidad no es requerida, es dificultoso definir que
debe hacer y probarlo
Produce code bloat, el software se vuelve ms grande y complicado.
Al no haber especificaciones, no ser utilizado
Snowball effect
27
Principios giles DRY
>DRY: Dont repeat yourself (No te repitas),
sugiere reducir la duplicacin.
Tambin conocido como OOO (Once and Only Once) o SPOT (Single
Point of Truth).
La duplicacin incrementa la dificultad de cambios, pierde claridad y da
oportunidades de inconsistencia.
Cuando es aplicado eficientemente, un cambio en un elemento del
sistema no afecta a otros elemento lgicamente independientes.
Cada pieza de conocimiento del sistema debe tener una sla
representacin.
Si se tiene ms de una manera de de expresar la misma cosa, en
algn punto esas representaciones perdern consistencia.
Se aplica a bases de datos, planes de test, build, documentacin.
28
Principios giles Hollywood
>Hollywood dont call us, well call you (No
nos llames, nosotros te llamaremos).
Principio que favorece la alta cohesin y el bajo acoplamiento que es
ms simple de debuggear, mantener y testear.
El programa cede el control al sistema, registrndose en eventos.
La evolucin en paradigmas:
Event Loop
Event-driven y OOP
Inversin de control (Dependency Injection)
29
Principios giles Otros
> Cowboy Coding
Deja a los programadores hacer lo que les plazca (Laisse fair). Depende mucho
de la experiencia de stos. Produce resultados rpidamente. Slo es til en
equipos chicos.
> Worse is better
Plantea todo un dilema
Es preferible lo bien hecho a lo disponible y barato?
No lo considero un princio gil sino un aviso de mirar las mtricas adecuadas. La
definicin de correcto e incorrecto puede variar segn el ambiente.
> Quick and dirty
Es utilizada para solucionar un problema de forma imperfecta, poco elegante e
inadecuada, pero que lo resuelve ms rpida y fcilmente que una solucin
correcta.
Refactoring
> Rodriguez Matias
31
Porqu arreglar lo que ya funciona?
> Cualquier tonto puede escribir cdigo que entienda
una computadora. Los buenos programadores escriben
cdigo que puedan entender los humanos.
Martin Fowler
> Objetivos
Mejorar el diseo del software
Hacer que el cdigo sea ms entendible
Ayuda a encontrar bugs ocultos
Aumentar la productividad (en serio!)
32
Cdigo duplicado
>El principio de todos
los males
>Refactorings:
Extraer mtodo
Extraer clase
Subir campo
Mtodo plantilla
33
Mtodo largo
>Uno de los clsicos
>Refactorings:
Extraer mtodo
Reemplazar mtodo
por Objeto mtodo
Descomponer
condicin
34
Clase muy grande
>Otro clsico
>Refactorings:
Extraer Clase
Extraer Subclase
Extraer Interfaz
Reemplazar valor de
datos con Objeto
35
Lista de parmetros muy larga
>Un vicio popular
>Refactorings:
Reemplazar parmetro
con Mtodo
Introducir Objeto
parmetro
Preservar Objeto
completo
36
Ciruga con escopeta
>Los cambios afectan
por doquier
>Refactorings:
Mover mtodo
Mover campo
Clase en una lnea
37
Envidia de caractersticas
>Clases que usan
ms los miembros
ajenos que los
propios
>Refactorings:
Mover mtodo
Mover campo
Extraer mtodo
38
Sentencias switch (o case)
> Desperdiciar el poder
del polimorfismo
> Refactorings:
Reemplazar condicional con
polimorfismo
Reemplazar tipo con
subclases
Reemplazar tipo con
estado/estrategia
Reemplazar parmetro con
mtodos explcitos
Introducir objeto nulo
39
Clase vaga
>Clases que no
cubren su costo
>Refactorings:
Clase en una lnea
Colapsar jerarqua
40
Generalidad especulativa
>No hace falta
todava, pero puede
ser que
>Refactorings:
Colapsar jerarqua
Clase en una lnea
Quitar parmetro
Renombrar mtodo
41
Cadenas de mensajes
>Demasiados saltos
sin una buena razn
>Refactoring:
Esconder delegado
42
Intimidad inapropiada
> Conociendo otras
clases demasiado de
cerca
> Refactorings:
Mover mtodo
Mover campo
Cambiar asociacin
bidireccional a unidireccional
Reemplazar herencia con
delegacin
Esconder delegado
Preguntas y Respuestas
Rodriguez, Matas (rodriguezmatias@gmail.com)
Papp, Esteban (esteban.papp@gmail.com)
http://groups.google.com/group/ing_computacion