Buenas prácticas en el desarrollo de Software Jorge Manrubia Díez jorge_manrubia@yahoo.es www.hci.uniovi.es Diciembre 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.5 http://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 Apliquemos esta metáfora a las interfaces que ofrecen las funciones/métodos 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) 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 Fin de la presentación Jorge Manrubia Díez jorge_manrubia@yahoo.es www.hci.uniovi.es