La programación extrema, y en general todos los métodos ágiles, sugieren que si algo no lo vas a utilizar no lo piques. Es decir, por ejemplo si se solicita una aplicación Java que sea una calculadora que sume y reste y todas las operaciones están en la clase Funciones.java entonces no se ha de implementar una función “multiplicar” en la clase Funciones.java porque no se ha pedido. Si en un futuro se necesita o lo solicita el cliente entonces ya se picara.
Esta filosofía se extrapola a componentes y frameworks. Se da a entender que al desarrollar componentes y frameworks se desarrolla más funcionalidad de la que se necesita.
Estoy de acuerdo que en algo tan simple como una “función“ no merece la pena y así se ahorra tiempo y dinero pero en algo como tan genérico como componentes y frameworks no lo estoy. El uso de componentes y frameworks, si se hacen correctamente, puede orientar la forma de programar y hacer más parecido el código de los distintos programadores que lo usen (mas mantenible) y orientado correctamente (evita que “lo mejor que le parezca al programador en ese momento” no sea la tónica de la programación). Lo que hay que hacer es que si realmente se quiere apostar por el uso de componentes y frameworks hay que molestarse un poco en leer la documentación asociada, seguir la guía de los desarrolladores, etc… Es decir, si se va a utilizar componentes y frameworks hay que hacerlo bien, siguiendo las recomendaciones de los fabricantes y leyendo documentación y no cogiendo el componentes o frameworks de cualquier manera y cuando no se comporta como se espera decir: “Este frameworks es una mierda ” (te suena, ¿verdad?)
1 comentario:
Sobre el artículo, lo que dice literalmente no es que uno no deba desarrollar o usar componentes o frameworks, sino que lo que hay que plantearse es "Es necesario para lo que me pide el cliente, hacer un framework, o un componente genérico", es decir, ¿Estamos "sobre diseñando" cuando generamos un framework y el objetivo del proyecto no es ese?.
Hacer un framework tiene sentido si dentro de los objetivos del proyecto es realizar un framework para desarrollar, pero lo que no tiene sentido, es si a ti te piden hacer un alta de usuarios, que te pongas a picar un super componente mega generico, o un framework para eso. Eso solo puedes hacer si ya tienes mucha experiencia previa picando ese código, tienes mucho conocimiento funcional de lo que se necesita, y tiempo para desarrollarlo, sino lo que va a pasar es que vas a tener algo complicado de usar, que no hace siquiera lo que tendría que hacer, y que ha llevado mucho tiempo hacerlo.
Y esto yo creo que ocurre, porque precisamente el software es facil de modificar y es muy flexible. En cambio en otras ingenierias, como podría ser la arquitectura, ya no es asi. Por ejemplo, ¿Te imaginas que a un arquitecto se le ocurriera hacer un mega puente estilo como el que hay en SanFrancisco para cruzar un riachuelo? A nadie se le ocurriría porque sería gastar dinero en material para hacer algo que no es ni mucho menos necesario. Pero en cambio si que es frecuente ver en el ambito informático como una persona monta una infrastructura de la leche para algo que se podia resolver de forma mucho más simple y que por otra parte lo otro era excesivo para los requisitos que se pedian. Por ejemplo, antes hubo una moda de colar EJB en todos los sitios, porque se suponia que al ser componentes distribuidos, eran muy reutilizables y encima te daban capacidad para que los EJB estuvieran desplegados en diferentes servidores. Pero la verdad es que muchos proyectos no necesitan añadir componentes tan pesados, para aplicaciones que no necesitaban ni ser distribuidas. Es por eso que se volvio a usar POJO inyectados por Spring. Una vuelta a la simplicidad.
También la culpa la tiene las metodologías predictivas y clásicas como el proceso unificado de desarrollo. Al final se termina haciendo un diseño muy complejo para intentar que la aplicación sea flexible y aguante los cambios de requisitos. Pero eso es como intentar hacer un puente y no saber ni el peso que tiene que soportar, ni la longitud que debe medir, con lo que al final el puente terminaría siendo más largo o corto de lo que se necesitaba, y además o se ha gastado más dinero del necesario, o se ha hecho algo que se queda pequeño.
Sin embargo en el desarrollo dirigido por tests, solo se implementa en cada iteración lo que es necesario, y además paso a paso, por lo que los cambios en los requisitos no afectan tanto.
Publicar un comentario