Diferencia entre revisiones de «Codigo Legado»
(→Ver tambien) |
|||
| Línea 6: | Línea 6: | ||
* [[Diseño De Software]] | * [[Diseño De Software]] | ||
* [[Prueba Unitaria]] | * [[Prueba Unitaria]] | ||
| + | |||
| + | [[Category:Diseño De Software]] | ||
| + | [[Category:Testing]] | ||
Revisión actual del 14:41 31 ago 2009
Al examinar la palabra código legado, en la cabeza de los desarrolladores viene una visión de código imposible de comprender, estructuralmente complejo, lleno de condiciones encadenadas, código spaghetti y métodos con cientos e incluso miles de líneas de código! Según Michael Feathers (en su libro "Trabajar de manera efectiva con Código Legado") el código legado es aquel que es difícil de entender y, por tanto, difícil de cambiar para aplicar las nuevas funciones o corregir defectos.
Pero, además, la definición que es más importante: el código legado es el código sin unidad de pruebas unitarias automatizadas. Esa definición radical e inusual nos muestra la importancia de contar con una suite de pruebas de unidad para mantener la salud del código y nuestro coraje de hacer cambios cuando sea necesario. Sin pruebas los desarrolladores adoptan la postura de no juguetear con el código que no "es de ellos", por temor a generar defectos. Tampoco hacen cambios estructurales para mantener la cohesión del código y con bajo acoplamiento, en especial cuando incluyen nuevas funcionalidades. Entonces, sin pruebas unitarias es difícil dar mantenimiento evolutivo y correctivo en el código y mantenerlo bien, evitando que se convierta en legado y complejo.
