Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez [email protected] ...
-
Upload
teresa-redondo-marquez -
Category
Documents
-
view
223 -
download
0
Transcript of Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez [email protected] ...
![Page 1: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/1.jpg)
Buenas prácticas en el desarrollo de Software
Jorge Manrubia Dí[email protected]
www.hci.uniovi.esDiciembre 2004
![Page 2: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/2.jpg)
Estamos aquí…
Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones
![Page 3: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/3.jpg)
¿Qué son las buenas prácticas?
Costumbres, hábitos, prácticas que utilizamos cuando desarrollamos SW Al alcance de todos No ligadas a tecnologías concretas
¿Cuál es su finalidad? Mejorar el desarrollo de software
![Page 4: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/4.jpg)
Estamos aquí…
Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones
![Page 5: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/5.jpg)
Código ofuscado
Si nunca pensaríamos leer un titular como el siguiente…
![Page 6: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/6.jpg)
Código ofuscado (II)
Porque codificamos del siguiente modo:
Fuente: New Language Features for Ease of Development in the Java 2 Platform, Standard Edition 1.5http://java.sun.com/features/2003/05/bloch_qa.html
![Page 7: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/7.jpg)
Código ofuscado (III)
¿Por ahorrar tiempo? El tiempo tecleando código es insignificante frente
al tiempo depurando Buscamos un código fácil de leer
Los nombres deben de ser descriptivos Se debe emplear tiempo
Escogiendo buenos nombres Tecleándolos Renombrando los existentes
![Page 8: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/8.jpg)
“The candy machine interface”
61 65
![Page 9: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/9.jpg)
Interfaces de los métodos
-Cambia el tamaño del objeto apuntado por ptr al tamaño especificado por tamanyo-Si ptr es un puntero nulo, la función realloc se comporta a igual que la función malloc para el tamaño especificado.-Si el espacio no puede ser desadjudicado, el objeto apuntado por ptr no varía.-Si tamanyo es cero y ptr no es nulo, el objeto al que apunta es liberado.
Apliquemos esta metáfora a las interfaces que ofrecen las funciones/métodos Ejemplo: Función realloc() de ANSI C
![Page 10: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/10.jpg)
Interfaces de los métodos (II)
Los métodos deben presentar un interfaz extremadamente nítido
Debe poder entenderse, sin consultar su especificación Lo que el método hace Su Entrada/Salida
![Page 11: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/11.jpg)
Interfaces de los métodos (III)
Evitar parámetros que determinen el funcionamiento del método Mejor hacer varios métodos. Ejemplo (clase String de
Java)
Evitar códigos de error Usar excepciones
Evitar que null: Sea un parámetro “con significado” Sea un retorno “con significado” (salvo excepciones)
![Page 12: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/12.jpg)
Código factorizado
![Page 13: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/13.jpg)
Estamos aquí…
Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones
![Page 14: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/14.jpg)
Código sólido
Es el código preparado para detectar errores No errores de usuario, sino errores que introducimos al
programar Cuando programamos codificaremos:
Lo que el programa tiene que hacer Código “extra” para detectar errores
Un ejemplo:
![Page 15: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/15.jpg)
Asertos
Pero lo anterior no es práctico: asertos Un aserto es un mecanismo
Que permite hacer asunciones sobre el funcionamiento de nuestro código Indican el error cuando no se validen
Que puede activarse (desarrollo) y desactivarse (lanzamiento)
El código de comprobación puede y debe ser tan complejo como sea necesario
![Page 16: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/16.jpg)
Tipos de verificaciones
Precondiciones Condiciones que debe cumplir el cliente para poder invocar
un método Sun no recomienda el uso de asertos: excepciones de
usuario específicas. Pero esto no es práctico. Invariantes
Condiciones que deben validarse para considerar el estado del objeto como legal
Postcondiciones Condiciones que deben cumplirse después de la
invocación a un método Verifican que el método se ha comportado correctamente
![Page 17: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/17.jpg)
Asertos en Java
Usar sentencia assert (a partir de 1.4) Se habilita/deshabilita al ejecutar la aplicación
Parámetro –ea de la VM
Usar librería propia Permite sobrecargar los asertos para adaptarlos a
las comprobaciones más habituales Referencias no nulas Cadenas no vacías
![Page 18: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/18.jpg)
Estamos aquí…
Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones
![Page 19: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/19.jpg)
Tests unitarios
Un test unitario es un test que valida un módulo de un programa Valida que funcione como es de esperar
El testing debe ser sistemático Pruebas “bajo demanda”
Implican asumir la corrección de lo que no probemos (ceguera)
No se pueden repetir (trabajo tirado a la basura)
No tiene nada que ver con los asertos del código sólido Pero se complementan
![Page 20: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/20.jpg)
Tests unitarios (II)
Los tests unitarios Deben ser auto comprobables Deben ser almacenados
Para crecer a la vez que nuestros componentes Para poder ser ejecutados en el futuro
Veremos un sencillo ejemplo en Java con Junit Pero es mucho más importante la práctica en sí
que la tecnología
![Page 21: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/21.jpg)
Un ejemplo sencillo (I)
![Page 22: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/22.jpg)
Un ejemplo sencillo (II)
![Page 23: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/23.jpg)
Estamos aquí…
Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones
![Page 24: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/24.jpg)
¿Cómo afrontar el cambio?
Anticipándonos a él Desarrollo en cascada
Abrazándolo Desarrollo iterativo Manteniendo el código en su estado más sencillo
posible “Sencillo” distinto de “cutre” Se debe de volver continuamente sobre el código para
mejorar su diseño: refactoring
![Page 25: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/25.jpg)
Refactoring
Refactoring es cambiar la estructura interna del código Mejorar su diseño Eliminar la duplicación
Se presenta un catálogo de refactorings Replace error code with exception, Rename field,
Extract interface... Pero más importante es adoptar la actitud
Mejorar el código siempre que se detecte la necesidad
![Page 26: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/26.jpg)
Composición mejor que herencia
La herencia puede resultar tentadora como mecanismo de reutilización de código Pero la herencia define una relación “es-un” entre
padre e hija La clase hija queda ligada a la clase padre: difícil
combinar funcionalidades La composición es una aproximación más
natural, por regla general Objetos que colaboran para lograr un fin
![Page 27: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/27.jpg)
Estamos aquí…
Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones
![Page 28: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/28.jpg)
Conclusiones
Todo el tiempo empleado en escribir Código fácil de leer Código robusto Tests unitarios Mejoras sobre el código existente
Lo ganaremos con creces en calidad y velocidad de desarrollo
Las buenas prácticas están al alcance de cualquiera “I’m not an excellent programmer, I’m only a good
programmer with excellent habits”
![Page 29: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/29.jpg)
Referencias
Writing solid code. Steve Maguire. Microsoft Press, 1993.
Refactoring: improving the design of existing code. Martin Fowler. Addison Wesley, 1999.
Extreme Programming explained: embrace change. Kent Beck. Addison Wesley Professional, 2000.
JUnit www.junit.org
Catálogo de buenas prácticas en Java http://www.javapractices.com/index.cjp
![Page 30: Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es Diciembre 2004.](https://reader036.fdocuments.net/reader036/viewer/2022062305/5665b4941a28abb57c925e8e/html5/thumbnails/30.jpg)
Buenas prácticas en el desarrollo de Software
Jorge Manrubia Dí[email protected]
Fin de la presentación
www.hci.uniovi.es