Una breve historia de la modularidad
Josh Emerson
21 de noviembre de 2016
0 minutos de lecturaHace poco más de una semana, fuimos patrocinadores de la conferencia de Brighton, ffconf. Fue una jornada llena de charlas excelentes, tanto inspiradoras como útiles. Ashley Williams, de npm, dio una charla titulada «Una breve historia de la modularidad», que nos pareció especialmente relevante para Snyk. Por eso, pensamos en compartir aquí un resumen.
Además de leer nuestro resumen, puedes descargar las diapositivas a través de npm ejecutando npm install a-brief-history (¡nos encanta que la charla de Ashley sea en sí misma un módulo de npm!). El video estará disponible pronto; agregaremos el enlace cuando lo esté.
¿Por qué modularizar?
npm es el repositorio de módulos más grande del mundo. Ahora tiene más módulos que Bower (JS), nuget (.NET), Packagist (PHP), PyPI y Rubygems.org juntos. Entonces, ¿por qué npm tiene tantos módulos?
La gente respondió al tuit de Ashley con todo tipo de respuestas, pero la mayoría mencionó motivos similares para modularizar el código:
Permite reutilizar código común
Impone la separación de responsabilidades
Facilita la documentación y las pruebas del código
¿Por qué no modularizar?
La modularización tiene un costo real en términos de complejidad. Como escribe Guy Podjarny en Las 5 dimensiones de una dependencia de npm, es posible que dependas de muchas más cosas de las que crees al principio. Para cada una de tus dependencias, debes hacerte muchas preguntas.
Al final, encuentras un paquete que parece satisfacer tus necesidades, más o menos. Pero tus problemas apenas comienzan. Te corresponde evaluar la biblioteca: ¿tiene pruebas? ¿Puedes entender el código fuente? ¿Se mantiene activamente? ¿Es fácil encontrar y consultar la documentación?
Rich Harris – Módulos pequeños: no es tan sencillo
Además de esa lista de preguntas, también debes considerar la seguridad. ¿Quienes mantienen el paquete corrigen las vulnerabilidades de su código? ¿Hay vulnerabilidades conocidas en la dependencia o en sus dependencias?
El desarrollo de software es gestión del cambio
Después de analizar los beneficios y los costos de la modularización, Ashley se enfoca en la diferencia entre la percepción y la realidad de modularizar.
Cuando pensamos en el desarrollo de software, probablemente pensamos en resolver problemas y crear sistemas que realizan tareas. Pero no solemos tener en cuenta que el software evoluciona continuamente, y no siempre en la misma dirección.
En 1972, David Parnas escribió un libro titulado «Sobre los criterios para descomponer sistemas en módulos», en el que aborda la modularización desde la perspectiva de la gestión del cambio.
[Empieza] con una lista de decisiones de diseño difíciles o que probablemente cambiarán. Luego, cada módulo se diseña para ocultar una de esas decisiones a los demás.
Cuando piensas en la modularización desde esta perspectiva, intentas ocultar la complejidad dentro de los módulos para que el resto del sistema no tenga que preocuparse por la implementación.
En su blog, programming is terrible, Tef nos propone una manera de hacerlo.
Escribe código que sea fácil de eliminar, no fácil de extender. En lugar de crear software reutilizable, deberíamos intentar crear software desechable. No hace falta decir que eliminar código es más divertido que escribirlo.
Conclusión
Ashley termina su charla resumiendo que modularizar el código es difícil, porque necesitamos entender mucho más para empezar a determinar cómo y cuándo dividirlo. Uno de los principales desafíos al decidir cómo y cuándo modularizar el código es que también interviene el tiempo. Solo con el tiempo podemos observar si una estrategia nos está dando resultado o no.
