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] ...
Buenas prácticas en el desarrollo de Software
Jorge Manrubia Dí[email protected]
www.hci.uniovi.esDiciembre 2004
Estamos aquí…
Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones
¿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
Estamos aquí…
Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones
Código ofuscado
Si nunca pensaríamos leer un titular como el siguiente…
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
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
“The candy machine interface”
61 65
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
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
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)
Código factorizado
Estamos aquí…
Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones
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:
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
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
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
Estamos aquí…
Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones
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
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
Un ejemplo sencillo (I)
Un ejemplo sencillo (II)
Estamos aquí…
Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones
¿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
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
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
Estamos aquí…
Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones
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”
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
Buenas prácticas en el desarrollo de Software
Jorge Manrubia Dí[email protected]
Fin de la presentación
www.hci.uniovi.es