En estos últimos meses he visto, más de una vez, una serie de lindos “dibujos”, con colores, que pretendían demostrar la dudosa calidad de NHibernate. Como, por mi edad, he superado, ya hace tiempo, la celosía sobre código producido, la primera vez que vi ese análisis me pareció interesante sobre todo para aplicarla a algún otro proyecto. Todas las otras veces (7 u 8 en 5 meses) que vi ese link, con comentarios tipo “good luck to NH team” o “NH team should fix this problem”, ya empezó a parecerme un poco pesado sobre todo porque se evidencia un “posible problema”, una y otra vez, sin ocuparse de mostrar una “posible solución”. Tengo toda la sensación que se está usando NHibernate como medio para publicitar un producto comercial en lugar de hacer una crítica para mejorar NHibernate; si hubiera otra intención veríamos, adjunto a la crítica, una propuesta de cambios (por este motivo no publico el link a ese producto).
Les quiero dar mi personal opinión sobre la calidad de NHibernate analizándolo desde otro punto de vista; los hechos.
“por peso”
NH2.0.0 tuvo más de un año de desarrollo con más de 100.000 líneas de código entre modificadas y nuevas respecto a la versión anterior. NH2.0.1 tuvo más de 20.000 downloads en menos de 2 meses. NH2.0.x tiene más de 1400 tests entre tests unitarios y behavior-tests. En el team nadie tiene permiso de crear aunque sea un branch-official donde se pueda romper un solo test.
NH2.1.0 es el nombre de la próxima versión (el actual trunk). Por suerte, o tal vez por confianza y calidad, NHibernate tiene bastantes usuarios del trunk. NH2.1.0 posee casi 1600 tests que operan sobre más de 1100 clases por un total de casi 180.000 líneas de código C#.
¿Qué resultado da todo esto?
A hoy 80 bugs (o posibles bugs) de varios niveles, y más de 100 issues entre pedidos de nuevas features y mejorías; que representa 80 sobre la cantidad de lo que hay atrás, y las funcionalidades que NH ofrece, se lo dejo calcular a ustedes.
No sé a cuanta gente les preocupa como está hecho NH por adentro (a parte que para juzgarlo hay que conocerlo bien) pero que hasta el trunk se pueda considerar estable no es poca cosa.
Conclusión
La CALIDAD no se logra por casualidad; la calidad de un software se logra con muchos tests, reglas férreas en el team, y manteniendo la conciencia y el anhelo de mejorarse todos los días.
Amo NHibernate y veo el valor detrás de él. I' VE vista que Hibernate el proyecto (el hermano de Hibernate) tenía una página, porqué este proyecto es acertado:
ReplyDeletehttp://www.hibernate.org/38.html Soy revelador joven, queriendo ganar nuevas ideas y aprender mejores maneras de hacer algo, y el NH ha demostrado muchas buenas prácticas. Más importantemente, NHibernate tiene una buena comunidad, y lo amo.
If you want use english to comments a spanish post there is no problem ;)
ReplyDelete(google translation is pretty accurate but not so exact).
A mi me parece que es muy real decir que no es la forma de medir calidad de código el hecho de ver muchas flechas de un lado a otro en un diagrama de una herramienta.
ReplyDeleteEl enfoque de la cantidad de lineas de codigo y cantidad de downloads por si solo tambien es discutible. Microsoft y datasets tambien tienen cientos de miles de lineas de codigo atras y millones de programadores que lo usan sin problemas...y sin embargo dios mio con esos millones...
A mi gusto la calidad de NH se ve en la calidad de la comunidad que lo usa, el tipo de discusiones, la sencillez de la solucion utilizando el ambiente, esos cientos de miles de lineas de codigo hacen el trabajo sucio para que nosotros con dos lineas de codigo resolvamos con sencillez cosas que parecen dificiles.
Por supuesto que el argumento mas fuertes es el de los tests...saber que hay forma de identificar si lo que anda seguira andando...da tranquilidad para usarlo...y tambien para meterse en el trunk obviamente...ya que mientras que nada se haya roto se puede tener fe.
Tu final me sono a "Where do you want to go today"...capaz que en algun momento recibis una citacion de Redmond para mejorar el EF :). Pero bueno, es cierto, para hacer algo con calidad no vale el libre albedrio, hay que tener definiciones claras de la forma de trabajo.
@Gustavo
ReplyDeletePor eso le puse "por peso"... A lo que voy es que: - la usabilidad y la utilidad de NH para producir software es evaluada por muchas empresas en muchísimos países del mundo (acá vendría la historieta de las moscas)
- por lo que es visible en Internet un montón de usuarios de NH son MVP de Microsoft (y acá otra vez las moscas)
- aunque NH sea grandote y modificado en continuación NO SE ROMPE tan fácil
- alguien escribió un libro sobre NH y se que alguien más está pensando en escribir otro
- Hay productos comerciales para desarrollo de aplicaciones que usan NH como persistence layer
- NH tiene muchísimos tests y un alto coverage aunque en el team me habrán escuchado unas cuantas veces quejarme que no son suficientes
- En más de 3 años de uso masivo se "acumularon" 80 bugs (que para mí no son casi nada)
Evito de escribir todas las otras características técnicas que me llevan a una optima evaluación.
En lo personal, con eso me alcanza para usarlo. Dicho eso, claro está que cualquier cosa es criticable por varios motivos pero si encuentras algo que no te gusta o lo cambias o lo aceptas o usas otra cosa; quejarse sin hacer nada es un deporte que no aprecio mucho.
Solo voy a decir una cosa, tenía una duda a las dos de la mañana la primera vez que empecé a usar nhibernate, la postee en un grupo y en 15 mins fue contestada por un tal Fabio, después me enteré por Darío quien era ese tal Fabio.
ReplyDeleteLa comunidad rejuvenece y fortifica la herramienta.
Si los comentarios no edifican, entonces se tienen que deshechar. Lo unico que le sirve a la comunidad de NH, son ideas nuevas y personas que pongan a prueba esas ideas mediante el uso de NH.
ReplyDeleteFabio, lo que no mencionas, es si hubo otros productos que fueron evaluados a la par de NH...
Yo no lo he visto... igual no importa cuando se encuentre algo mejor lo usaremos, por ahora NH es lo que hay, peor es nada.
ReplyDelete