Las líneas de código siguen sirviendo para juzgar una gema de Ruby

Kasper Timm Hansen, conocido en el ecosistema Ruby como kaspth, sostiene que contar las líneas de código de una gema sigue siendo un termómetro útil antes de meterla en el Gemfile. Lo dejó caer en el podcast Dead Code en abril y ahora lo ha desarrollado por escrito.

El procedimiento es de andar por casa. Lees el README, te haces una idea de cuánto debería ocupar la implementación y después pasas cloc para ver el recuento real. Lo interesante es la distancia entre tu estimación y la cifra. Pasar la opción --by-file da además la distribución por fichero.

Si sale menos de lo que esperabas, hay material que estudiar. Puede que hayan tirado de un método de Enumerable que no conocías, que resuelvan la seguridad entre hilos de una forma que no se te había ocurrido, o que organicen las clases de una manera que merece la pena mirar. Si sale más, hay dos lecturas: o el problema es más complejo de lo que pensabas, o la gema está sobreabstraída y demasiado densa, y quizá no quieras depender de ella.

Los cubos de servilleta

Hansen lleva tiempo diseñando lo que llama "breezy reads": que un desarrollador senior entienda qué pasa dentro en menos de una hora. Dos de las suyas, ActiveRecord::AssociatedObject y ActiveJob::Performs, no llegan a las 100 líneas. La primera extrae lógica de dominio en objetos colaboradores más pequeños; la segunda fija una convención de aplicación para integrar jobs en el modelo de dominio. El núcleo de la primera son unas 70 líneas de Ruby, publicadas en el repositorio.

Con los años ha acabado clasificando sus ideas en tramos según lo que cree que valen:

• Menos de 100 líneas: pequeña y al grano.
• 250-500: aquí hay complejidad.
• 500-1.000: tiene que resolver un problema sustancial para justificarse.
• Más de 1.000: otro partido, el margen de error es enorme.

Oaken, otra gema suya de 1.0.0, ocupa 280 líneas con un alcance que él estimaba en 1.000. Que una gema tenga muchas líneas no es el problema; el problema es que se pase de lo que su concepto vale.

Un amigo suyo, Thomas Cannon, contó que la idea de contar líneas no le convencía hasta que la vio emparejada con la complejidad conceptual: entonces dejó de parecerle un ejercicio de acortar por acortar. Ese es el punto que sostiene Hansen. El recuento no dice si el código es bueno, pero pone un número a la intuición y obliga a preguntarse si el tamaño cuadra con el problema. Para quien mantiene dependencias de terceros, es una comprobación de dos minutos antes de abrir el editor.