Leo en este blog una referencia a un libro que leí hace tiempo Facts and Fallacies about Software Engineering, y que creo que resume perfectamente muchos de los problemas que se ven a diario desarrollando software:
Interesante recordatorio.
lunes, 31 de marzo de 2008
miércoles, 19 de marzo de 2008
KISS, DRY, YAGNI...
La comunidad de defensores de los métodos ágiles de desarrollo es muy aficionada a los acrónimos crípticos. Debe ser una forma de reconocerse unos a otros, y de impresionar a los no iniciados en la materia... en cualquier caso, merece la pena ver lo que quieren decir, porque las ideas que hay detrás son muy interesantes en nuestra búsqueda del Software de Calidad
DRY = Don't Repeat Yourself
Viene a decir que cada trozo de información, idea, concepto, decisión de diseño, dato debe estar expresada al menos en un sitio y como mucho en un sitio.
Un ejemplo evidente es la creación de un método para "formatear" coordenadas geográficas, es decir pasar de un double lat = 41.32242423 a un String latStr = "41º 19' 20,73"". Es lógico expresar ese algoritmo una sola vez en el código y utilizarlo desde todos los puntos de la aplicación en los que se necesite realizar esta conversión.
Parece una obviedad, y además, por suerte, este principio es una de las cosas que primero se enseñan en las escuelas de informática, por lo que a priori nadie se atreve a discutirlo... otra cosa es la aplicación real que se hace de él y lo fácilmente que lo olvidamos muchas veces.
Ventajas de aplicar este principio:
Un entorno de desarrollo que lleva al extremo el principio DRY es Ruby on Rails. Merece la pena echarle un vistazo aunque solo sea por la interesante aplicación de ideas como "convención frente a configuración", "database migrations", "modelo/vista/controlador" y "los 3 entornos: desarrollo, pruebas, producción" y la aplicación obsesiva del principio DRY.
Violaciones frecuentes del principio:
Está comprobado: todos tenemos un sexto sentido para detectar violaciones de este principio. Muchas veces cuando estamos escribiendo código, creando un esquema de base de datos, introduciendo datos de prueba... tenemos la sensación de "esto ya lo he escrito antes", "seguro que esto lo tenemos ya por otro lado" , "debería crear un método común en lugar de hacer copy&paste" una especie de alarma interior que nos indica que lo que estamos haciendo no huele bien del todo.
DRY = Don't Repeat Yourself
Viene a decir que cada trozo de información, idea, concepto, decisión de diseño, dato debe estar expresada al menos en un sitio y como mucho en un sitio.
Un ejemplo evidente es la creación de un método para "formatear" coordenadas geográficas, es decir pasar de un double lat = 41.32242423 a un String latStr = "41º 19' 20,73"". Es lógico expresar ese algoritmo una sola vez en el código y utilizarlo desde todos los puntos de la aplicación en los que se necesite realizar esta conversión.
Parece una obviedad, y además, por suerte, este principio es una de las cosas que primero se enseñan en las escuelas de informática, por lo que a priori nadie se atreve a discutirlo... otra cosa es la aplicación real que se hace de él y lo fácilmente que lo olvidamos muchas veces.
Ventajas de aplicar este principio:
- Menos trabajo inicial: nos ahorramos repetir código que ya tenemos desarrollado (o datos, o documentación, o lo que sea)
- Claridad: es más fácil entender la aplicación si cada cosa está en un solo sitio
- Coherencia: si algo está expresado en dos lugares diferentes, es casi seguro de que habrá variaciones. Incluso si inicialmente una de las instancias es resultado del copy&paste, con el tiempo serán diferentes, cuando alguien haga una modificación en una de las instancias y se olvide de la(s) otra(s).
- Subrutinas, clases de utilidad, código, refactorización
- Datos
- Reglas de negocio
- Esquemas de la base de datos
- Planes de Prueba
- Sistema de Build de la aplicación
- Documentación
Un entorno de desarrollo que lleva al extremo el principio DRY es Ruby on Rails. Merece la pena echarle un vistazo aunque solo sea por la interesante aplicación de ideas como "convención frente a configuración", "database migrations", "modelo/vista/controlador" y "los 3 entornos: desarrollo, pruebas, producción" y la aplicación obsesiva del principio DRY.
Violaciones frecuentes del principio:
Está comprobado: todos tenemos un sexto sentido para detectar violaciones de este principio. Muchas veces cuando estamos escribiendo código, creando un esquema de base de datos, introduciendo datos de prueba... tenemos la sensación de "esto ya lo he escrito antes", "seguro que esto lo tenemos ya por otro lado" , "debería crear un método común en lugar de hacer copy&paste" una especie de alarma interior que nos indica que lo que estamos haciendo no huele bien del todo.
- Copy & paste del código (tengo que probar la herramienta CPD Copy&Paste Detector a ver que tal... lo que he visto promete)
- Copy & paste de trozos de documentación
- El esquema de base de datos está en 3 sitios: en la documentación, en la BB.DD. y en las clases del código que acceden a la BB.DD.
- ¿se os ocurren mas?
- KISS = Keep It Simple Stupid !
- YAGNI = You are not going to need it.
miércoles, 12 de marzo de 2008
Software de Calidad
¿ Calidad Software = Software de Calidad ?
Desde hace unas semanas se ha creado en la empresa en la que trabajo un nuevo puesto: Gerente de Calidad Sw, que casualmente voy a ocupar yo mismo.
Desde estas líneas intentaré hacerme eco de todas aquellas iniciativas que emprendamos, los resultados observados, dificultades, sugerencias, etc que nos encontremos por el camino.
Hasta pronto!
Desde hace unas semanas se ha creado en la empresa en la que trabajo un nuevo puesto: Gerente de Calidad Sw, que casualmente voy a ocupar yo mismo.
Desde estas líneas intentaré hacerme eco de todas aquellas iniciativas que emprendamos, los resultados observados, dificultades, sugerencias, etc que nos encontremos por el camino.
Hasta pronto!
Suscribirse a:
Comentarios (Atom)