Estos últimos días estoy leyendo por enésima vez Code Complete, mi libro preferido sobre desarrollo de software, y el de mucha más gente. A este libro pertenece esta tabla, basada en diversos estudios, que ejemplifica el coste medio de arreglar un error durante el proceso de desarrollo de software según la etapa en que se introdujo y la etapa en que se terminó solucionando.
| Coste | Etapa en que se detectó | |||||
|---|---|---|---|---|---|---|
| Requisitos | Arquitectura | Construcción | Pruebas | Mantenimiento | ||
| Etapa en que se introdujo | Requisitos | 1 | 3x | 5-10x | 10x | 10-100x |
| Arquitectura | – | 1 | 10x | 15x | 25-100x | |
| Construcción | – | – | 1x | 10x | 10-25x | |
Como vemos, un defecto cuyo arreglo podía suponer un coste de 100€ en la fase de toma de requisitos podría multiplicarse hasta los 300€ de no encontrarse hasta que estuvieramos definiendo la arquitectura del sistema. Esta cantidad subiría hasta los 500€ si hubieramos empezado a escribir el código, 1.000€ si estuvieramos en la fase de pruebas, y hasta 10.000€ de no encontrarse el error hasta que el sistema se encontrara ya funcionando. Tenedlo en cuenta si alguien intenta justificaros el no seguir ningún tipo de método.
Bueno, por esto se está poniendo de moda el TDD (Test-Driven Development). Por lo menos, en la comunidad en la que trabajo (Ruby + Ruby on Rails) el TDD está muy arraigado…
Para quien no conozca qué es TDD, un breve resumen:
1) Escribimos las pruebas. Imaginemos que queremos implementar una serie de métodos: las pruebas tienen que contemplar los «edge cases» que pueden hacer petar el código y ocasionar bugs.
2) Escribimos el código de la aplicación, comprobando siempre que nuestro código no rompe nada de lo que ya funciona
Lo que permite el TDD es encontrar estos errores ANTES de empezar a programar la aplicación en sí, por lo que el ahorro es mucho mayor. Además, al estar trabajando siempre contra las pruebas nos aseguramos que nuestro código siempre funcionará en los casos que hemos especificado en las pruebas.
Si no usáis TDD os recomiendo darle un vistazo, os puede llegar a ahorrar mucho tiempo y dinero 🙂
Coincido. Además ya no es sólo el feedback, es que el simple hecho obligarte a escribir código fácil de testear suele provocar que todo sea más legible.
Ya tengo dos tareas, por un lado, hacerme con el libro y leerlo (de una vez por todas, que no es la primera vez que lo pones y digo ¡a leerlo!). Y por otro lado, estudiar la metodología TDD. Ya estuve leyendo un poco, poquito sobre esta, pero tengo que ponerme.
este libro es muy interesante es de mis favoritos sobre programación.
ing de software, esta materia no me gustaba