Criterio para elegir una librería

[Michel Martens]

James Halliday, alias substack (https://twitter.com/substack), es muy
conocido en el mundo de node.js. Escribió muchísimas librerías, todas
chicas, eficientes, y a diferencia de lo que ocurre en el mundo Ruby,
los proyectos simples de Node.js son muy usados. Recién mandó por
twitter su respuesta a una pregunta similar a la que proponía Ernesto
hace un tiempo, y es sobre qué criterio utilizar para elegir una
librería.

http://www.reddit.com/r/javascript/comments/2378xo/the_best_frontend_interview_question_i_got_when/cgv9oky

Como está en inglés, les pego acá una traducción:

Estos son los criterios que uso:

* Que pueda instalar la librería con npm

* Que el código que se muestra en el README use require(). De un
vistazo tengo que darme cuenta cómo se integraría la librería en el
proyecto que tengo entre manos.

* Que tenga una idea y un propósito claros y específicos

* Que sepa cuánto delegar funcionalidad en otras librerías, que no
quiera satisfacer demasiados requerimientos.

* Que sea escrito o mantenido por autores cuya opinión sobre diseño de
software, modularidad e interfaces concuerda con la mía. Esto es más
rápido que inspeccionar detenidamente la documentación y el código.

* Que las dependencias cumplan con estos mismos requisitos.

Cuando un proyecto intenta hacer demasiadas cosas, algunas de sus
partes van a sufrir cierto abandono ya que el costo de mantenimiento
puede resultar prohibitivo. Cuanto más intenta resolver un proyecto,
más fácil es que esté completamente equivocado sobre alguna premisa y
esto también puede desembocar en cierto abandono ya que es muy difícil
modificar las premisas más adelante.

Las mejores librerías, las que más perduran, son las pequeñas piezas
de código que son difíciles de escribir, pero que pueden ser
fácilmente verificables. Las librerías muy matemáticas abundan en esta
categoría, como la función gama o un ecosistema de librerías para
manipulación de matrices como ndarray.

Cuando una librería es embebida en un ecosistema con otras librerías
de una forma desacoplada, el resultado es una dinámica en donde la
librería principal no necesita crecer para satisfacer más casos de
uso, y en cambio se puede perfeccionar para librarla de los bugs más
sutiles, mientras que las librerías dependientes pueden ofrecer
excelente interoperabilidad para encajar en una estructura informal de
mayor escala.

Estos son unos factores que no son importantes:

* Número de estrellas o forks. Por lo general esto es una señal
inversa, porque los proyectos que cubren muchos casos de uso tienen a
llamar más la atención, pero también a la larga necesitan más
mantenimiento y pueden quedar abandonados. Sin embargo, algunas
librerías están completamente erradas, pero hizo falta escribirlas
para que eso fuera evidente.

* Actividad. A partir de cierto momento, algunas liberías están
terminadas y continúan funcionando siempre que el ecosistema que las
rodea funcione.

* Una página web linda. Esto es muchas veces (aunque no siempre) un
signo de que la librería tiene muy buen marketing, pero el alcance es
demasiado amplio y es muy probable que sea abandonada.

[Angel Java Lopez]

Gracias por el enlace, maese @soveran!

Me gusta el cambio de titulo, "Criterio para elegir una libreria". El thread original de maese @etagwerker tenia algo mas: "Calidad de una gema", como diciendo, "la elijo por calidad", cuando parece que hay mas contexto a considerar. Y que la decision final es "la elijo o no la elijo", mas que "la premio o no la premio como la mejor gema de reparto de 2013" ;-)

El tema es elegir. Calidad puede influir, pero me gusta lo que pone el bueno de @substack (que varios de nosotros conocimos en la JS Conf de Montevideo, del mes pasado; parece que se alimenta con sandwiches de banana todo el dia ;-) conversando con el, me conto algo que no conocia: su trabajo con Smalltalk)

Tenia "in pectore" abrir un hilo como este, justamente citando el caso de la programacion en Node.js. Como no programo en Ruby, callo sobre el criterio de eleccion de gemas. Alguna vez, en un hilo aparte, hice la distincion entre

- gemas que son librerias, y que llamamos nosotros

- gemas que hacen algo mas, modifican algo de la conducta de otra cosa

En Node.js, son parva las librerias del primer tipo. Las del segundo tipo aparecen en general, como "middleware" a colgarse de algun framework, como Connect, Express. Serian como los middleware que tienen en Ruby para agregar a Rack.

Queria abrir ese otro hilo, con un titulo como este, porque estuve meditando, a partir de la pregunta de maese @etagwerker (que ayer se tranco flor de fernet, aunque no era viernes ;-), cual es mi proceso, y el de otros, para elegir consumir un modulo en Node.js.

Hace poco, en la lista en ingles de Node.js, aparece Floby (floren...@gmail.com) escribiendo:

My process is

• Assert what my problem at hand is
• find a lib that does this (this should result in several libs)
• if it does too much compared to what I need : trash it
• if it has no tests : trash it
• if it has bad tests: trash it
• if it doesn't `npm install` : trash it
• if it depends on too many big libs : trash it
• if nothing left, write it.

Coincido bastante, aunque tal vez no voy a tanto detalle. Vean que tanto @substack como Floby se fijan en el "npm install", que me parece resuelve mejor algunas cosas que el gem de Ruby. Pero un criterio es: que el modulo haga lo que tengo que resolver. Y trato que lo que tengo que resolver sea, digamos, sencillo, no hacer cuarenta cosas. De vez en cuando aparece un problema que necesita ser resuelto con cuarenta cosas (por ejemplo, una libreria de matrices, que maneje reales y complejos). Pero es raro encontrarse con eso en el desarrollo de aplicaciones mas o menos "normales".

La diferencia con el workflow de arriba, es algo que me parece que tengo que escribir:

- Elijo el modulo, de tal forma que si me equivoco, LO PUEDA CAMBIAR POR OTRO

Siguiendo el espiritu agil, las decisiones que se tomen no tienen que tener costo temprano. Hasta las podria diferir, en muchos casos. Para conseguir lo de arriba, elegir modulo y luego poder cambiarlo por otro, hago:

- El codigo mio que consume lo que el modulo a adoptar aporta, LO ESCRIBO CON TDD (test-driven development)

Entonces, tengo todo para en cualquier momento, cambiar el modulo que elijo, por otro. Los test (no del modulo original, sino los del codigo propio que consumen el primer modulo elegido), me dan la red de contencion para que las decisiones tempranas (si es que se demuestra que fue demasiado temprana) no me duelan.

Me da la impresion que en el ambiente Ruby, para un gran conjunto de gemas, ese camino no es tan facil. Alguno de los casos mas notorios debe ser el de las gemas para Rails. Lo mismo me parece en la adopcion de algunos paquetes en Django, en Python.

Volviendo a Node, y a un flujo de eleccion de modulos mas personal: lo que hago muchas veces, ANTES de buscar una libreria para solucionar un problema: la escribo yo mismo, usando TDD. Floby, en cambio, lo pone como ultimo punto. Muchas veces es un ejercicio interesante:

- (muchas veces) no cuesta mucho mas tiempo que el de elegir librerias

- Queda mucho mas claro el problema a solucionar, cuando uno intenta un camino de solucion

- Se aprende en el camino

- Si fue una decision temprana o no muy buena, como igual aplico lo de arriba (el codigo consumidor lo escribo con TDD), la puedo cambiar por una libreria mas acabada, en cualquier momento

Nos leemos!

Angel "Java" Lopez

@ajlopez

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a rubysur+u...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.