Buenas prácticas de desarrollo – Patrones de diseño
En este artículo se explica por qué es importante conocer, saber cuándo aplicar y por qué aplicar, buenas prácticas basadas en patrones de diseño en el desarrollo de cualquier proyecto, ya sea legacy o nuevo.
A lo largo de mi carrera profesional no han sido pocos los proyectos donde he contribuido en diferentes empresas, arquitecturas, lenguajes y metodologías. No es de extrañar que cuanto más antiguo y con mayor número líneas de código es el proyecto, más personas han contribuido y por ende, más diversa es la imaginación que se ha plasmado sobre el código fuente de cada uno de los desarrolladores. A veces escribimos código horrible aunque, inmantenible por el mero hecho de la presión en la finalización de una tarea. Queda demostrado que este tipo de código hace que el producto tenga fallos y la productividad sea menor. ¿Quiere esto decir que un proyecto tiene fecha de caducidad? ¿Existe un tamaño máximo de proyecto por el cual es viable / mantenible)? ¿Debemos asumir que de vez en cuando se escribe código horrible?
Debemos recordar que la metodología Agile asume que todos somos artesanos del software, sin entender eso no estamos aplicando la metodología correctamente. Bajo mi punto de vista y con la aparición de arquitecturas de microservicios, la respuesta a las dos primeras preguntas es directa: “Todo proyecto con una curva de aprendizaje alta indica complejidad y tamaño elevado, y esta condenado a su refactorización”. Es evidente el gasto de tiempo, recursos y dinero de proyectos legacy quitando opción a la mejora de producto, y pierde tiempo en el time-to-market.
Pensad en el trabajo de un desarrollador, por supuesto quiere hacer su trabajo con calidad. El día 5 le presionan para que termine, cada semana le presionan para que termine, cada mes le presionan para que termine, cada año le presionan para que termine ¿Os imagináis el resultado de su trabajo?
En consecuencia con lo anterior, la influencia de estos software craftman son las que hacen que las piezas encajen y permítanme la similitud, “que el libro se entienda de principio a fin” dando aportaciones de calidad y legibilidad al caos. No duden que esta nueva figura de Profesionales de la Calidad y Desarrollo traerán beneficios a todo proyecto software. A veces incluso lidian con los agentes externos de presión (A.K.A. directores, jefes, negocio…) para hacerles entender la diferencia entre “get it done” vs “get it right” no solo a medio / largo plazo.
Conclusiones
Gracias al manifiesto por la artesania del software (Software Craftmanship):
- No sólo software que funciona, sino también software bien diseñado.
- No sólo responder al cambio, sino también agregar valor constantemente.
- No sólo individuos e interacciones, sino también una comunidad de profesionales.
- No sólo colaboración de clientes, sino también asociaciones productivas.
Poco a poco esta surgiendo la figura de Software Craftman, que vela por la calidad y mantenibilidad del código. La profesionalidad del desarrollo es el futuro del sector.
Jesús Ramírez Guerrero · Software Arquitect & Team Leader · LinkedIn
Referencias
[1] http://manifesto.softwarecraftsmanship.org/#/es [2] The Software Craftsman: Professionalism, Pragmatism, Pride ISBN 0-13-405250-1. (Chapter 15: Pragmatic Craftsmanship)