Download BUENAS_PRACTICAS_en_el_desarrollo_de_software

Buenas prácticas en el
desarrollo de Software
Jorge Manrubia Díez
[email protected]
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


Cuando programamos codificaremos:



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


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


Invariantes


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.
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



Se presenta un catálogo de refactorings


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

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
[email protected]
www.hci.uniovi.es