Aquí están las razones que más a menudo se dan para evitar el uso de módulos:
- No necesito un módulo para una tarea sencilla
Puede parecerlo así ahora, ¿pero has considerado todos los posibles casos que tu código deberá controlar? ¿Qué ocurre si (o cuando) tus requerimientos cambien? Los autores de módulos, por lo general, han tenido tiempo para examinar los casos límite. Mejor aún, los módulos vienen empaquetados con un conjunto de pruebas para asegurarse de que pueden manejar esos casos. Incluso si planeas probar tu código por tí mismo (así es, ¿no?), el módulo te ha ahorrado el esfuerzo de escribir las pruebas.
Su tarea puede ser simple, pero utilizando un módulo mantiene la complejidad conceptual de tu código en un mínimo. En efecto, utilizando un módulo generalmente es la solución más simple a un simple problema. - El módulo incluye características que nunca usaré
¿Y qué? Como se señaló anteriormente, ¿cómo puede estar seguro de que nunca utilizaré esas características? E incluso si está realmente seguro (¡ja!) que nunca utilizará esos extras, no están haciendo ningún daño sólo por estar sentados a nuestro alrededor sin usarse. A menos que... bueno, lo que nos lleva a nuestro próximo punto. - Usar módulos engordará mi script, por lo que lo hará más lento
Comprendo tu preocupación, pero realmente, esta es una forma de optimización prematura. En lugar de citar aquí a Knuth, voy a mandarte a las reglas de Andy Lester del Club de la Optimización. Hasta que no hayas ejecutado la aplicación y visto que es demasiado lenta, y hasta que no hayas perfilado la aplicación y sepas que es el módulo la causa del problema, evitarlo porque quizás enlentezca tu programa no es una buena razón.
Además, no tienes ninguna garantía de que al escribir tu código sea más rápido. Muchos módulos están implementados usando enlazados XS a código C compilado. Estos normalmente irán más rápido que cualquier aplicación hecha en puro Perl. - Quiero que mi script tenga pocas dependencias
Bien, pero ¿por qué? Si es por razones de optimización, véase más arriba. Si es por razones de portabilidad, véase más abajo. De lo contrario sólo puedo pensar que estás evitando dependencias porque piensas que puedes hacerlo mejor que cualquier módulo existente y quiere ser responsable de mantener y soportar el código que hace esta tarea. Si estás escribiendo código que es de tu completa responsabilidad, sí es en realidad una razón completamente válida para crear tu propia versión y evitar un módulo. Como referencia, ver Joel sobre la defensa del Síndrome de lo No-Inventado-Aquí.
Sin embargo, dicho esto, si tienes que preguntar a los Monjes sobre cómo obtener su solución, lo más probable es que no sea de tu completa competencia, y que deberías tener unas buenas razones para considerar seriamente el porqué estás evitando tener dependencias. - Quiero que mi script sea fácil de transportar
El código Perl es muy portátil, ¡incluso con dependencias de módulos! La mayoría de ellos dependen de otros módulos, y se instalan bien. Creo que esta objeción no es más que otra manera de decir "No sé cómo empaquetar mi aplicación a fin de que pueda ser instalado junto con sus dependencias". Para hacer frente a eso, hay excelentes recursos disponibles en este mismo sitio que describe creación y distribución de módulos, que incluyen soluciones para que tu código declare sus dependencias por lo que se puede instalar de una forma portable. - No se me permite instalar módulos en mi organización
Estupendo, ¡instálalos localmente! A Perl no le preocupa si has instalado los módulos localmente o a nivel de toda la organización, funcionarán de la misma manera. De hecho, puedes tener tu propia versión de Perl para asegurarse que todas las versiones de los módulos están controladas por ti, localmente, y no tu sistema operativo o tu administrador de sistemas. - Hay un módulo que al parecer hace lo que necesito, pero está roto o con errores
Esta es, probablemente, la más legítima razón de todas, porque muestra que has hecho el esfuerzo de intentar usar un módulo, pero sin ser culpa tuya, has llegado a un rincón sin salida. Lamentablemente, eso es lo que pasa.
Una forma de proceder es informar del problema al mantenedor del módulo. Si es responsable, el problema puede ser resuelto y puedes luego proseguir felizmente, módulo en mano.
Algunas veces, sin embargo, los módulos no están suficientemente mantenidos. Eso no significa que haya que empezar desde cero. Probablemente quieras escribir un parche para el módulo que pueda ser aplicado a tu propio caso, y entonces usar esa versión parcheada. Incluso puedes pedir ayuda sobre cómo hacer esto a tus compañeros monjes. De hecho, una vez hecho debes enviar el parche al mantenedor del módulo, que muy probablemente agradecerá tus esfuerzos, si y cuando regrese de donde estuvo.
Dicho todo esto, naturalmente es solo un consejo. Pero en mi humilde opinión, es un buen consejo. Como el autor de tu código, eres el único que hace las decisiones sobre qué módulos usar basado en las necesidades y circunstancias específicas. Solo recuerda que cuando los monjes sugieren que uses un módulo, no es porque sean perezosos. Es porque la experiencia ha mostrado que en la mayor parte del tiempo, es la decisión correcta.
Si realmente no puedes usar un módulo por razones particulares, asegúrate que incluyes este razonamiento en tu disertación antes de mandar una pregunta al foro. De esa manera, no le harás perder un tiempo valioso debatiendo estos puntos con gente que solo está intentando ayudar.
Original, en inglés.
