Buenas pr

1
Buenas prácticas en el desarrollo de Software

• Jorge Manrubia Díez
• jorge_manrubia_at_yahoo.es

www.hci.uniovi.es
Diciembre 2004
2
Estamos aquí

• Introducción
• Buenas prácticas de codificación
• Código sólido
• Tests unitarios
• Buenas actitudes de desarrollo
• Conclusiones

3
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

4
Estamos aquí

• Introducción
• Buenas prácticas de codificación
• Código sólido
• Tests unitarios
• Buenas actitudes de desarrollo
• Conclusiones

5
Código ofuscado

• Si nunca pensaríamos leer un titular como el
  siguiente

6
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/b
loch_qa.html
7
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

8
The candy machine interface
9
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.

10
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

11
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)

12
Código factorizado
13
Estamos aquí

• Introducción
• Buenas prácticas de codificación
• Código sólido
• Tests unitarios
• Buenas actitudes de desarrollo
• Conclusiones

14
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

15
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

16
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

17
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

18
Estamos aquí

• Introducción
• Buenas prácticas de codificación
• Código sólido
• Tests unitarios
• Buenas actitudes de desarrollo
• Conclusiones

19
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

20
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

21
Un ejemplo sencillo (I)
22
Un ejemplo sencillo (II)
23
Estamos aquí

• Introducción
• Buenas prácticas de codificación
• Código sólido
• Tests unitarios
• Buenas actitudes de desarrollo
• Conclusiones

24
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

25
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

26
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

27
Estamos aquí

• Introducción
• Buenas prácticas de codificación
• Código sólido
• Tests unitarios
• Buenas actitudes de desarrollo
• Conclusiones

28
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
• Im not an excellent programmer, Im only a good
  programmer with excellent habits

29
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

30
Buenas prácticas en el desarrollo de Software
Fin de la presentación

• Jorge Manrubia Díez
• jorge_manrubia_at_yahoo.es

www.hci.uniovi.es