Si, excelente articulo (aunque no estoy del todo de acuerdo con el autor)... a me llama la atencion que:
El autor se complica la vida creando una infrestructura para hace "pluggable" el algoritmo, para luego decir que son todo boberias... no puedo evitar pensar que aunque hasta cierto punto tiene razon, podria haberse ahorrado gran parte de ese codigo usando el JSR-299, o Spring y aun asi mantener la flexibilidad...
Quiza lo mejor seria utilizar un lenguaje como Scala con first class functions, en donde se puede pasar de parametro directamente la funcion que se quiere usar, en vez de tener que declarar una clase
Me encanto el detalle de se dio cuenta de que no maneja los numeros negativos... pero su idea de usar una matematicas avanzadas (Gamma function), que en mi opinon tiene mas probabilidades de causar problemas en el mantenimiento, no lo salvo del problema de utilizar double, cuando probablemente deberia haber usado BigDecimal, por otro lado, como siempre, depende de los requerimientos
Coincido con el autor en cuanto que se debe tener cuidado a la hora de aplicar patrones de diseño, pero creo tan malo considerar mala la aplicacion de los patrones, como considerar malo no aplicarlos... el problema, siento yo, esta en saber cuando vale la pena introducir la flexibilidad y cuando no... y eso, aunque puede aprenderse, no puede enseñarse.
El título del artículo es "cómo NO hacer un factorial" y luego va mostrando procesos comunes en sistemas empresariales, de cómo se van sobrecomplicando las cosas de manera innecesaria. Es la mentalidad de complicador y hay muchos ejemplos, y es algo que se tiene que combatir constantemente. No generalizar más de lo necesario. Como decía Mafalda, todo sirve para algo, pero nada sirve para todo. Por lo tanto cuando tenemos un algoritmo que queremos generalizar y poner en una biblioteca para reuso posterior, hay que saber qué tanto generalizar, y no es tan fácil.
El título del artículo es "cómo NO hacer un factorial"
Lo se... pero..
y luego va mostrando procesos comunes en sistemas empresariales, de cómo se van sobrecomplicando las cosas de manera innecesaria.
Innecesaria... o necesaria... depende... y solo se puede saber dependiendo del contexto dado por los requerimientos.
Es la mentalidad de complicador y hay muchos ejemplos, y es algo que se tiene que combatir constantemente.
Por otro lado, hay que recordar los peligros de la sobre-simplifcacion como:
El desarrollador que usa double en vez de BigDecimal por que "es muy complicado usar bigdecimal"
El desarrollador que concatena cadenas, en vez de usar parametros por que "es mas simple"
El desarrollador que declara todos sus metodos static, por que "es mas eficiente"
El desarrollador que pone todo su algoritmo en un mega-metodo de 5000 lineas de codigo por que es "asi mas simple"
El desarrollador que decide (ya lo vivi) que basta con 1 solo metodo static para realizar dentro de el todos los algoritmos en su codigo:
Razonamiento: Todo puede convertirse a cadena antes de recibirse, todo puede convertirse a cadena antes de retornarse, todo puede parsearse si es necesario que ejecuta llame a ejecuta para reutilizar codigo. ¿Para que complicarse la vida con varias clases y objetos si con esto puedo conseguirlo todo?
editPara un resumen todo este rollo, ir al final para leer la conclusión.
Hay un buen punto en ese artículo y en el de los Astronaustas de la Arquitectura ( mucho más antigüo por cierto ) y es, que hay que ser prácticos y pragmáticos y no andarnos volando.
Sin embargo hay un punto que se le escapa a estos dos artículos y es, que en el software existen muchos niveles de abstracción y cada uno tiene un nivel de concreción correspondiente. El problema que todos nos enfrentamos ( aunque no nos demos cuenta - o al menos a mí me pasa seguido - ) es saber en que nivel estamos trabajando. Como en el software es muy difícil discernir entre algo macro y algo micro porque todo al fin de cuentas es intangible, se vuelve más difícil utilizar el concepto de "tamaños" para ubicarnos en el nivel de abstracción correcto.
Algo abstracto es cuando se listan las características esenciales de lo que describimos de acuerdo al dominio que nos interese ( Esta es por cierto una de las características principales de la OO, no necesitamos definir por ejemplo el color de los ojos de una persona para tener una clase "Persona" en nuestro sistema ). Un nivel de abstracción X es cuando nos referimos a todos las cosas del mismo dominio de la misma manera. Cuando hacemos software sin embargo, la barrera de estos niveles de abstracción se difumina muy fácilmente. En un momento podemos estar hablando de un servicio de activación de clientes y al siguiente segundo del query que lo inserta en la base de datos con X o Y sintaxis determinada de acuerdo con el RDBMS y aún esto, es un nivel alto por ejemplo para el RDBMS mismo o los detalles del RDBMS es un nivel muy alto para el sistema operativo y como funciona una SO es un nivel muy alto para el kernel solamente y ....
La cuestión pues, está en discernir en que nivel de abstracción estamos tratando y como lo vamos a concretar. Cuando somos los implementadores hay que hacer algo que funcione, pero si también tenemos información de como "SI" va a ser usado el software tenemos que soportar esos "casos de uso". No tenemos que hacer que todo sea a prueba de balas, si no tenemos siquiera información de que balas serán usadas!, pero si tenemos que hacer nuestro software lo suficientemente robusto al menos para lo que sabemos se va a hacer con él. Si no sabemos todos los escenarios hay que preguntar o preguntarle al que debe de preguntar ( el analista de negocio en este caso ) y definir un alcance. Cuando no se tiene este alcance, puede que pasemos el tiempo codificando cosas que no se van a usar ( como en el ejemplo del artículo ) y probablemente dejando de lado algunas que sí se necesitaran ( como también se menciona en el artículo ).
Del otro extremo tenemos la práctica de la programación ágil con los conceptos de, TDD, YAGNI y DRY, pretenden reducir esta característica del desarrollo de software de volarse más allá del nivel del oxigeno ( de los astronautas del software ) y hacer algo concretito, muy aterrizado. Pero estas prácticas tampoco son las balas de plata ni se puede aplicar siempre. El TDD ( Desarrollo dirigido por pruebas, Test Driven Development por sus siglas en inglés ) dice que en vez de hacer mucho código antes de probarlo, hagas las pruebas primero y que estas pruebas, te defininen como va a funcionar tu software. YAGNI ( No lo vas a necesitar , you're not gonna need it ) dice que no escribas el código, antes de que lo necesites. DRY( No te autorepitas, Don't repeat your self, juego de palabras con "dry" seco ) sugiere que no tengas dos lugares con el mismo código, sino que se utilice una función que sea utilizada en ambos lados. La idea es tener solo lo necesario para funcionar y nada más que eso, lo opuesto a los Astronautas.
Este otro extremo de la programación ágil, aunque es muy atractivo, tampoco es la respuesta a todos las necesidades de software, la razón la misma que el anterior, depende del nivel de abstracción que se necesite; a veces se necesita ver más allá de lo inmediato y siendo ortodoxo con estas prácticas puede volver más complicado el desarrollo por que se vive al día. Se necesita madurez y experiencia para saber que tanto más se debe de programar aunque no se haya pedido, pero también saber cuando ya nos estamos volando la barda ( o nos estamos subiendo más allá del nivel de oxigeno ).
Hay que ser pragmáticos, pero si el nivel de abstracción lo requiere, hay que dejar que la imaginación vuele y no pretender que esta visión futurista de las cosas se mezcle con la inmediatez de la implementación, son cosas diferentes.
En un proyecto, se necesitan cosas concretas. En una visión a 10 - 20 años, se necesitan de los astronautas del software. Todo depende del nivel de abstracción. Sin ellos no habría JVM ( o .net for that matter ) y seguiriamos pegados al fierro como C++. O productos como los de Apple, Tampoco habría cosas como twitter o fakebook ( no sé si eso fuera necesariamente malo ) o internet para acabar pronto ( eso si sería malo ) porque esta imaginación desbordada es la que logra definir productos que después podrán ser o no implementados. Pero hay que saber discernir si lo que necesitamos en el proyecto de software es una mega abstracción donde todo sea polvo cósmico, o necesitamos que ese registro se salve a la base de datos y se quede ahí.
Conclusión
Irónicamente terminé escribiendo mucho para decir lo siguiente:
Al programar hay que ser pragmáticos y hacer nuestro software de acuerdo al nivel de abstracción que corresponda. Si el rol que se tiene es el de futurista entonces, hay que dejar volar la imaginación y pensar en todas las posibilidades al alcance.
El artículo me lo recomendó un ex estudiante de maestría Víctor (ceyusa) que siempre me está vacilando con eso de arquitectura de software y patrones y estilos y todas esas cosas que en ocasiones hacen barroca a una solución, pero otras muchas veces la embellecen.
En lo personal no estoy de acuerdo con lo visceral de la opinión del autor y coincido mucho con lo que ustedes comentan,pero lo que sí les aseguro es que me reí mucho.
Seguro este comentario lo amarán la mayoria de programadores de windows jaja. (es broma, antes de que me digan algo)
En realidad esto se trata de algo que ezamudio comentó hace mucho y con lo que comparto la idea: no siempre vas a utilizar las soluciones de moda solo por que han demostrado ser lo mejor. Como si alguien quisiera hacer un sistema distribuido cuando será mono-usuario.
El artículo puede que tenga un punto de vista de válido, pero muy mal aplicado. En la práctica, ¿en realidad hay quienes hayan hecho todo ese sistema para obtener un numero factorial?, solo basta una clase utils con un metodo static y listo, ¿por qué?, por que es tonto pensar que nosotros como programadores querriamos algunas veces usar una solucion y otras veces otras, como bien lo dijo él, buscamos la mejor, cuando la encontramos la reutilizamos y listo.
Sin embargo, un proceso complejo, con una arquitectura como ésa es treméndamente mas útil y fácil de manejar que algo simple.
En resumen, creo que el autor pasó un mal momento con algún código de otro desarrollador que no sabía como deshagor su coraje.
Submitted by beto.bateria on Jue, 03/10/2011 - 20:33.
Creo que hay una relacion muy importante entre "muy sencillo - facil de darle mantenimiento", es decir mantenerlo sencillo (el codigo ) y verificar tambien que sea facil de darle mantenimiento es lo mejor. He tenido malas experiencias de personas que hacen una superclase que resuelva todos los problemas, o de codigo spagetti que si cambias una cosa nada funciona, o aquellas personas que estan aprendiendo patrones y quieren aplicar el singleton en todas partes.
Creo que hay una relacion muy importante entre "muy sencillo - facil de darle mantenimiento",
Bueno, mas que haya, yo diria que "tendria que haber" por que en mi experiencia, los que programan "sencillo", no se preocupan por el mantenimiento posterior (no digo que no sea posible, solo que en general no es lo que mas comúnmente he observado)
Excelente!
Wow, muy buen artículo. Creo que va como muy buen complemento al de los Astronautas de la Arquitectura, de Spolsky.
Chido! Mis comentarios:
Si, excelente articulo (aunque no estoy del todo de acuerdo con el autor)... a me llama la atencion que:
Coincido con el autor en cuanto que se debe tener cuidado a la hora de aplicar patrones de diseño, pero creo tan malo considerar mala la aplicacion de los patrones, como considerar malo no aplicarlos... el problema, siento yo, esta en saber cuando vale la pena introducir la flexibilidad y cuando no... y eso, aunque puede aprenderse, no puede enseñarse.
Ilustrar el punto
El título del artículo es "cómo NO hacer un factorial" y luego va mostrando procesos comunes en sistemas empresariales, de cómo se van sobrecomplicando las cosas de manera innecesaria. Es la mentalidad de complicador y hay muchos ejemplos, y es algo que se tiene que combatir constantemente. No generalizar más de lo necesario. Como decía Mafalda, todo sirve para algo, pero nada sirve para todo. Por lo tanto cuando tenemos un algoritmo que queremos generalizar y poner en una biblioteca para reuso posterior, hay que saber qué tanto generalizar, y no es tan fácil.
Sobre simplificacion
Lo se... pero..
Innecesaria... o necesaria... depende... y solo se puede saber dependiendo del contexto dado por los requerimientos.
Por otro lado, hay que recordar los peligros de la sobre-simplifcacion como:
Razonamiento: Todo puede convertirse a cadena antes de recibirse, todo puede convertirse a cadena antes de retornarse, todo puede parsearse si es necesario que ejecuta llame a ejecuta para reutilizar codigo. ¿Para que complicarse la vida con varias clases y objetos si con esto puedo conseguirlo todo?
etc, etc
chale yo hasta el día de hoy
chale yo hasta el día de hoy usaba double, si me acabo de enterar del detallito que tiene, de ahora en adelante usaré BigDecimal =)
Hay que considerar los niveles de abstracción.
edit Para un resumen todo este rollo, ir al final para leer la conclusión.
Hay un buen punto en ese artículo y en el de los Astronaustas de la Arquitectura ( mucho más antigüo por cierto ) y es, que hay que ser prácticos y pragmáticos y no andarnos volando.
Sin embargo hay un punto que se le escapa a estos dos artículos y es, que en el software existen muchos niveles de abstracción y cada uno tiene un nivel de concreción correspondiente. El problema que todos nos enfrentamos ( aunque no nos demos cuenta - o al menos a mí me pasa seguido - ) es saber en que nivel estamos trabajando. Como en el software es muy difícil discernir entre algo macro y algo micro porque todo al fin de cuentas es intangible, se vuelve más difícil utilizar el concepto de "tamaños" para ubicarnos en el nivel de abstracción correcto.
Algo abstracto es cuando se listan las características esenciales de lo que describimos de acuerdo al dominio que nos interese ( Esta es por cierto una de las características principales de la OO, no necesitamos definir por ejemplo el color de los ojos de una persona para tener una clase "Persona" en nuestro sistema ). Un nivel de abstracción X es cuando nos referimos a todos las cosas del mismo dominio de la misma manera. Cuando hacemos software sin embargo, la barrera de estos niveles de abstracción se difumina muy fácilmente. En un momento podemos estar hablando de un servicio de activación de clientes y al siguiente segundo del query que lo inserta en la base de datos con X o Y sintaxis determinada de acuerdo con el RDBMS y aún esto, es un nivel alto por ejemplo para el RDBMS mismo o los detalles del RDBMS es un nivel muy alto para el sistema operativo y como funciona una SO es un nivel muy alto para el kernel solamente y ....
La cuestión pues, está en discernir en que nivel de abstracción estamos tratando y como lo vamos a concretar. Cuando somos los implementadores hay que hacer algo que funcione, pero si también tenemos información de como "SI" va a ser usado el software tenemos que soportar esos "casos de uso". No tenemos que hacer que todo sea a prueba de balas, si no tenemos siquiera información de que balas serán usadas!, pero si tenemos que hacer nuestro software lo suficientemente robusto al menos para lo que sabemos se va a hacer con él. Si no sabemos todos los escenarios hay que preguntar o preguntarle al que debe de preguntar ( el analista de negocio en este caso ) y definir un alcance. Cuando no se tiene este alcance, puede que pasemos el tiempo codificando cosas que no se van a usar ( como en el ejemplo del artículo ) y probablemente dejando de lado algunas que sí se necesitaran ( como también se menciona en el artículo ).
Del otro extremo tenemos la práctica de la programación ágil con los conceptos de, TDD, YAGNI y DRY, pretenden reducir esta característica del desarrollo de software de volarse más allá del nivel del oxigeno ( de los astronautas del software ) y hacer algo concretito, muy aterrizado. Pero estas prácticas tampoco son las balas de plata ni se puede aplicar siempre. El TDD ( Desarrollo dirigido por pruebas, Test Driven Development por sus siglas en inglés ) dice que en vez de hacer mucho código antes de probarlo, hagas las pruebas primero y que estas pruebas, te defininen como va a funcionar tu software. YAGNI ( No lo vas a necesitar , you're not gonna need it ) dice que no escribas el código, antes de que lo necesites. DRY( No te autorepitas, Don't repeat your self, juego de palabras con "dry" seco ) sugiere que no tengas dos lugares con el mismo código, sino que se utilice una función que sea utilizada en ambos lados. La idea es tener solo lo necesario para funcionar y nada más que eso, lo opuesto a los Astronautas.
Este otro extremo de la programación ágil, aunque es muy atractivo, tampoco es la respuesta a todos las necesidades de software, la razón la misma que el anterior, depende del nivel de abstracción que se necesite; a veces se necesita ver más allá de lo inmediato y siendo ortodoxo con estas prácticas puede volver más complicado el desarrollo por que se vive al día. Se necesita madurez y experiencia para saber que tanto más se debe de programar aunque no se haya pedido, pero también saber cuando ya nos estamos volando la barda ( o nos estamos subiendo más allá del nivel de oxigeno ).
Hay que ser pragmáticos, pero si el nivel de abstracción lo requiere, hay que dejar que la imaginación vuele y no pretender que esta visión futurista de las cosas se mezcle con la inmediatez de la implementación, son cosas diferentes.
En un proyecto, se necesitan cosas concretas. En una visión a 10 - 20 años, se necesitan de los astronautas del software. Todo depende del nivel de abstracción. Sin ellos no habría JVM ( o .net for that matter ) y seguiriamos pegados al fierro como C++. O productos como los de Apple, Tampoco habría cosas como twitter o fakebook ( no sé si eso fuera necesariamente malo ) o internet para acabar pronto ( eso si sería malo ) porque esta imaginación desbordada es la que logra definir productos que después podrán ser o no implementados. Pero hay que saber discernir si lo que necesitamos en el proyecto de software es una mega abstracción donde todo sea polvo cósmico, o necesitamos que ese registro se salve a la base de datos y se quede ahí.
Conclusión
Irónicamente terminé escribiendo mucho para decir lo siguiente:
Al programar hay que ser pragmáticos y hacer nuestro software de acuerdo al nivel de abstracción que corresponda. Si el rol que se tiene es el de futurista entonces, hay que dejar volar la imaginación y pensar en todas las posibilidades al alcance.
Complicadores por naturaleza
Nos gusta complicarnos la vida. Muchas veces creemos seguir el camino más sencillo y fácil de recorrer y hacemos todo lo contrario.
Yo también he hecho muy malas prácticas de programación como no documentar el código y escribir código muerto.
¿A quién no le ha pasado?
Que bueno que el artículo les agradó
El artículo me lo recomendó un ex estudiante de maestría Víctor (ceyusa) que siempre me está vacilando con eso de arquitectura de software y patrones y estilos y todas esas cosas que en ocasiones hacen barroca a una solución, pero otras muchas veces la embellecen.
En lo personal no estoy de acuerdo con lo visceral de la opinión del autor y coincido mucho con lo que ustedes comentan,pero lo que sí les aseguro es que me reí mucho.
Seguro este comentario lo
Seguro este comentario lo amarán la mayoria de programadores de windows jaja. (es broma, antes de que me digan algo)
En realidad esto se trata de algo que ezamudio comentó hace mucho y con lo que comparto la idea: no siempre vas a utilizar las soluciones de moda solo por que han demostrado ser lo mejor. Como si alguien quisiera hacer un sistema distribuido cuando será mono-usuario.
El artículo puede que tenga un punto de vista de válido, pero muy mal aplicado. En la práctica, ¿en realidad hay quienes hayan hecho todo ese sistema para obtener un numero factorial?, solo basta una clase utils con un metodo static y listo, ¿por qué?, por que es tonto pensar que nosotros como programadores querriamos algunas veces usar una solucion y otras veces otras, como bien lo dijo él, buscamos la mejor, cuando la encontramos la reutilizamos y listo.
Sin embargo, un proceso complejo, con una arquitectura como ésa es treméndamente mas útil y fácil de manejar que algo simple.
En resumen, creo que el autor pasó un mal momento con algún código de otro desarrollador que no sabía como deshagor su coraje.
sobres
Creo que hay una relacion muy
Creo que hay una relacion muy importante entre "muy sencillo - facil de darle mantenimiento", es decir mantenerlo sencillo (el codigo ) y verificar tambien que sea facil de darle mantenimiento es lo mejor. He tenido malas experiencias de personas que hacen una superclase que resuelva todos los problemas, o de codigo spagetti que si cambias una cosa nada funciona, o aquellas personas que estan aprendiendo patrones y quieren aplicar el singleton en todas partes.
tendria que haber
Bueno, mas que haya, yo diria que "tendria que haber" por que en mi experiencia, los que programan "sencillo", no se preocupan por el mantenimiento posterior (no digo que no sea posible, solo que en general no es lo que mas comúnmente he observado)