Prácticas de la programación extrema
Escrito el 23 de Septiembre de 2009 | 8:56 pm en Asignaturas, ISW II | 4 Comentarios »
El otro día en clase estuvimos hablando sobre los métodos ágiles y, entre ellos, de la programación extrema. Quedó pendiente que los alumnos buscaran información sobre las 12 prácticas que este proceso de desarrollo establece. A petición de ellos pongo el listado pero con la condición de crear otra entrada con las conclusiones obtenidas 
Retroalimentación a escala fina
- Desarrollo guiado por pruebas
- Juego Planificación
- On site Customer
- Programación en parejas.
Proceso continuo en lugar de por lotes
- Integración continúa
- Recodificación
- Pequeñas versiones
- Diseño simple
- Metáfora del sistema
- Propiedad colectiva código
- Estándares de codificación
Bienestar del programador
- Semana de 40 horas
4 Respuestas
A mí las que más me gustan son el desarrollo Test-driven, aunque no es muy ágil porque hay que escribir test unitarios pa’tó, y la integración continua, porque puede ayudar en la gestión de los test, el build y el control de versiones. Ambas técnicas son muy buenas para mejorar la calidad del software, aunque es necesaria mucha disciplina… ejem xD
Retroalimentación a escala fina
* Desarrollo guiado por pruebas
Es más fácil someter un programa a pruebas, que un concepto o un esquema a las mismas. Si programas primero la interfaz de usuario, detectarás fallos de usabilidad o accesibilidad.
Cómo se guarda o escribe internamente no es importante, lo importante es como se use el software, así que empieza haciendo lo que se ve.
Somételo a pruebas, de uso y de datos, antes de avanzar.
* Juego Planificación
Con un papel y boli diseña el proceso de producción. Simplifícalo. Simplifícalo aun más. Más aun.
Cuando el diagrama sea simple y entendible somételo a pruebas de escalabilidad y cambio. Si las resistes será el punto de partida y deberas tener cuidado, o los cambios te arruinaran.
Pártelo en trozos, muy pequeños, y haz de cada trozo un módulo independiente. Colocalos en una lista ordenada y ve haciéndolos uno tras otro.
* On site Customer
Que el cliente forme parte del proceso de desarrollo es algo muy bonito en teoría, aunque en la práctica puede ser una pesadilla, repito las palabras de miguel ángel: “mucho cuidado con las demos”.
Personalmente soy muy partidario del papel, enseñar lo que hará para que se evalue con un dibujito,dar una version básica y admitir correcciones tras el uso, pero no cambios bajo demanda, por ideas o genialidades del cliente.
* Programación en parejas.
Puede que alguno ya sepa lo que es el “code-blind”, pero para el que no lo sepa, es básicamente cuando tras 45 minutos tirándote del pelo por un error de ejecución, descubres que has puesto “=” en lugar de “==” en una condición.
Que esto pase, con dos personas mirando, es mucho menos probable…de echo tu compañero te correjirá antes de que cambies de línea. Esperemos.
Proceso continuo en lugar de por lotes
* Integración continúa
Que haya siempre un ejecutable: si la programacion es modular y carga componentes externos e independientes, ni siquiera habrá que recompilar.
Hacer un cargador comun y que cada cual pruebe su parte de forma independiente…si esta bien hecha, no ha de haber problemas.
* Recodificación
Si alguien ha hecho algo que te gusta, apúntalo a continuación de tu “TODO LIST” para hacerlo en cuanto termines lo que estas haciendo.
Si algún codigo es mejorable, considera la regla coste-beneficio y recuerda que en holandés (o era aleman?), a los perfeccionistas obsesivos se les llama, muy acertadamente “follahormigas”
* Pequeñas versiones
Modularidad y mas modularidad. La calculadora ha de funcionar, independientemente del navegador. Sino, mal vamos.
* Diseño simple
En http://www.chuidiang.com/ood/metodologia/extrema.php, hablan del diseño simple y dicen: “Hacer siempre lo mínimo imprescindible de la forma más sencilla posible. Mantener siempre sencillo el código.”
Este es el principio de la filosofía de programación KISS (Keep It Simple Stupid), que se muestra tambien en la filosofía de binarios de unix/linux: un programa que haga algo muy concreto y pequeño, pero que lo haga bien. ¿Porqué se empeña todo el mundo en añadir nuevas características, muchas veces innecesarias?
* Metáfora del sistema
Moraleja: programa en inglés, usa nombres largos pero entendibles como “thisVarIsMadeForWalking” y documentar.
* Propiedad colectiva código
El open source es algo muy positivo para los programadores, pero dificil de encajar (por muchos libros de catedrales y bazares que se escriban) en el mercado actual.
Hoy en día hay poca protección para el código y demasiadas patentes de grandes empresas. El conocimiento debería ser gratuito para todos, pero explotado por quien lo haya desarrollado.
* Estándares de codificación
En la misma web, incida: “Debe haber un estilo común de codificación (no importa cual), de forma que parezca que ha sido realizado por una única persona.”
Este punto es idílico, y solo tiene cierta posibilidad de lograrse si el jefe de proyecto ha dejado todo explicado de una manera clarísima. Personalmente intento que todo el equipo tenga claro qué se va a hacer y cómo, pero siempre hay que estar abierto a diferentes maneras de afrontar un problema, la creatividad ha de estar siempre presente.
Notacion camel, Clases con mayusculas…y el rollo aplicable en cada lugar.
Bienestar del programador
* Semana de 40 horas
…menos en semana de entrega, que sube a unas 53 diarias.
Uno de los consejos que mejor funcionan cuando te atascas programando es apagar el equipo, irte a casa y mañana será otro día. (Aunque en casa estés dándole vueltas, tarde o temprano la tele te librará del problema).
Obviamente, se admiten críticas y comentarios constructivos
Menudo mega comentario!!!
De la propiedad colectiva del código hablaremos en profundidad en las próximas clases. Es interesante la opción que planteas de que el conocimiento sea gratuito pero explotado por la persona que lo ha desarrollado.
A ver si algún compañero más se anima con los comentarios. Tendremos que idear alguna forma de valorar la “proactividad”.
@jorge Mucho cuidado con el Test-Driven Development. Es arduo y pesado, y siendo francos no siempre se testea todo. Lo de “Juego Planificación” me ha molado. En general, la simplicidad es la meta, pero no es nada fácil. La experiencia demuestra que es más fácil hacer algo complicado que algo sencillo, y aquí es cuando aparecen los malentendidos (falacias):
A – Hola, B, veo que estás programando
B – Sí… estoy haciendo un par de clases para acceder a la base de datos
A – Ah, pues ya hay algunas hechas y muy eficientes, como ADOdb o MDB2
B – Es que no quiero complicarme la vida, el proyecto es una cosa muy simple…
A – Buenos, días, señor B
B – Hola, friki A, verás necesito que me hagas una página güeb de esas
A – Ajá. Veamos. ¿Qué necesidades hay? ¿Había pensado algo concreto?
B – Bueno, en realidad quiero algo sencillo, na más que pa subir cosas y precios… una cosa simple. Te doy 200 euros, con lo sencillo que es y lo listo que eres tú te lo sacas en una semana y media no?
A – Que le folle un pez, señor B