Buenas prcticas en el desarrollo de Software Jorge

Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo. es www. hci. uniovi. es Diciembre 2004

Estamos aquí… n n n 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? n Costumbres, hábitos, prácticas que utilizamos cuando desarrollamos SW q q n Al alcance de todos No ligadas a tecnologías concretas ¿Cuál es su finalidad? q Mejorar el desarrollo de software

Estamos aquí… n n n Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones

Código ofuscado n Si nunca pensaríamos leer un titular como el siguiente…

Código ofuscado (II) n Porque codificamos del siguiente modo: Fuente: New Language Features for Ease of Development in the Java 2 Platform, Standard Edition 1. 5 http: //java. sun. com/features/2003/05/bloch_qa. html

Código ofuscado (III) n ¿Por ahorrar tiempo? q n El tiempo tecleando código es insignificante frente al tiempo depurando Buscamos un código fácil de leer q q Los nombres deben de ser descriptivos Se debe emplear tiempo n n n Escogiendo buenos nombres Tecleándolos Renombrando los existentes

“The candy machine interface” 61 65

Interfaces de los métodos n Apliquemos esta metáfora a las interfaces que ofrecen las funciones/métodos q Ejemplo: Función realloc() de ANSI C -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.

Interfaces de los métodos (II) n n Los métodos deben presentar un interfaz extremadamente nítido Debe poder entenderse, sin consultar su especificación q q Lo que el método hace Su Entrada/Salida

Interfaces de los métodos (III) n Evitar parámetros que determinen el funcionamiento del método q Mejor hacer varios métodos. Ejemplo (clase String de Java) n n n Evitar códigos de error q n Usar excepciones Evitar que null: q q Sea un parámetro “con significado” Sea un retorno “con significado” (salvo excepciones)

Código factorizado

Estamos aquí… n n n Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones

Código sólido n Es el código preparado para detectar errores q n Cuando programamos codificaremos: q q n No errores de usuario, sino errores que introducimos al programar Lo que el programa tiene que hacer Código “extra” para detectar errores Un ejemplo:

Asertos n n Pero lo anterior no es práctico: asertos Un aserto es un mecanismo q Que permite hacer asunciones sobre el funcionamiento de nuestro código n q n 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 n Precondiciones q n Invariantes q n Condiciones que debe cumplir el cliente para poder invocar un método n Sun no recomienda el uso de asertos: excepciones de usuario específicas. Pero esto no es práctico. Condiciones que deben validarse para considerar el estado del objeto como legal Postcondiciones q q 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 n Usar sentencia assert (a partir de 1. 4) q Se habilita/deshabilita al ejecutar la aplicación n n Parámetro –ea de la VM Usar librería propia q Permite sobrecargar los asertos para adaptarlos a las comprobaciones más habituales n n Referencias no nulas Cadenas no vacías

Estamos aquí… n n n Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones

Tests unitarios n Un test unitario es un test que valida un módulo de un programa q n Valida que funcione como es de esperar El testing debe ser sistemático q Pruebas “bajo demanda” n n n 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 q Pero se complementan

Tests unitarios (II) n Los tests unitarios q q Deben ser auto comprobables Deben ser almacenados n n n Para crecer a la vez que nuestros componentes Para poder ser ejecutados en el futuro Veremos un sencillo ejemplo en Java con Junit q 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í… n n n Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones

¿Cómo afrontar el cambio? n Anticipándonos a él q n Desarrollo en cascada Abrazándolo q q Desarrollo iterativo Manteniendo el código en su estado más sencillo posible n n “Sencillo” distinto de “cutre” Se debe de volver continuamente sobre el código para mejorar su diseño: refactoring

Refactoring n Refactoring es cambiar la estructura interna del código q q n Se presenta un catálogo de refactorings q n Mejorar su diseño Eliminar la duplicación Replace error code with exception, Rename field, Extract interface. . . Pero más importante es adoptar la actitud q Mejorar el código siempre que se detecte la necesidad

Composición mejor que herencia n La herencia puede resultar tentadora como mecanismo de reutilización de código q q n 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 q Objetos que colaboran para lograr un fin

Estamos aquí… n n n Introducción Buenas prácticas de codificación Código sólido Tests unitarios Buenas actitudes de desarrollo Conclusiones

Conclusiones n Todo el tiempo empleado en escribir q q n n 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 q “I’m not an excellent programmer, I’m only a good programmer with excellent habits”

Referencias n n 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 q n www. junit. org Catálogo de buenas prácticas en Java q http: //www. javapractices. com/index. cjp

Buenas prácticas en el desarrollo de Software Fin de la presentación Jorge Manrubia Díez jorge_manrubia@yahoo. es www. hci. uniovi. es