Buenas prácticas en el desarrollo de Software

Jorge Manrubia Díezjorge_manrubia@yahoo.es

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íezjorge_manrubia@yahoo.es

Fin de la presentación

www.hci.uniovi.es