Buenas prácticas en el desarrollo de Software

Presentación del tema: "Buenas prácticas en el desarrollo de Software"— Transcripción de la presentación:

1 Buenas prácticas en el desarrollo de Software
Jorge Manrubia Díez 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

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”
61 65

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 “I’m not an excellent programmer, I’m 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 Catálogo de buenas prácticas en Java

30 Buenas prácticas en el desarrollo de Software
Fin de la presentación Jorge Manrubia Díez