Inicio > Desarrollo, Opinión > Padeces “NuGet-itis”?

Padeces “NuGet-itis”?

Cuando tú, programador, haces click en “Nuevo Projecto” en Visual Studio y el asistente termina, qué es lo siguiente que abres? Si la respuesta es agregar incluso más componentes de NuGet (o similares) puede que padezcas NuGet-itis.

Lo siento, es que hoy me he mosqueado. Estaba haciendo unas pruebas, necesitaba implementar un par de APIs básicos para hacer experimentos. Así que nada, abrí VisualStudio y creé un nuevo “proyecto Web/Web API”. Hasta ahí todo bien hasta que di a “Ok” y apareció ésta monstruosidad en mi entorno de desarrollo:

SimpleWebAPI-1

Lo triste no eran sólo las dependencias… lo espectacular era lo que había como “contenido” de mi nuevo servicio web:

SimpleWebAPI-2

Y eso que era un “Web API en blanco”, para añadir un par de cositas y probar unos servicios que tengo para probar. Es simplemente ridículo.

La idea de OWIN (para empezar) es un runtime “minúsculo” (ejem!) para el desarrollo de aplicaciones web con la mínima carga en el servidor. Obviamente, el que hizo la “plantilla” de Web API no leyó las especificaciones. Bootstrap? JQuery? Para un Web API? Pero qué locura es ésta? Y caí en cuenta… “Es que ahora, TODO va así”.

Recordé de repente a un compañero, con la tarea de utilizar una serie de archivos que contenían argumentarios para centros de llamadas, con contenidos codificados en BASE64. Se pasó tres días (literalmente) en buscar una implementación de BASE64 para Java, ignorando la que yo le escribí en media hora que hacía sobradamente el trabajo. O programadores que según empiezan un proyecto abren la consola de componentes para añadir “lo que necesitan”, aunque ello implique arrastrar (en la mayoría de los casos) enormes cantidades de código que ni siquiera necesitan (como el caso de mi proyecto “Web API”).

El problema de depender de NuGet (o similares) para realizar hasta el más simple de los proyectos es que en muchos casos las dependencias que arrastra determinan en qué forma hay que realizar el resto del proyecto. Me pongo en el ejemplo de varios tutoriales que muestran cómo añadir autentificación a una aplicación web: sólo funcionan si estás haciendo una aplicación web “desde cero”. Pero, qué pasa cuando ya tienes esa aplicación web hecha y simplemente quieres añadir la autentificación? Simplemente no puedes (os recomiendo fervorosamente que intentéis hacerlo siguiendo las instrucciones del tutorial). O eso, o te toca reescribir prácticamente la totalidad de tu aplicación – cosa que en muchos casos es incluso más caro que hacerte la autentificación a mano desde cero.

Entity Framework, OWIN, MVC, MVVM, todos son frameworks para conseguir hacer cosas que en muchos casos te “obligan” a desarrollar en cierta forma. Si tenías una base hecha, simplemente no puede ser portada directamente al nuevo entorno. O el mero hecho de añadir Entity Framework, que puede suponer un verdadero quebradero de cabeza de integrar con tu infraestructura de datos actual – o el error de asumir que tienes que usarlo absolutamente para todo, y es cuando acabas retorciendo el framework para que “tambien sirva” para lo que tenías antes, sin pensar que, simplemente, no te hace falta.

El problema finalmente reside en que muchos programadores modernos sólo saben usar este tipo de frameworks – y tristemente porque muchos leyeron el tutorial equivocado.. Les quitas Entity Framework o cualquier “sabor” de MVC o MVVM y simplemente están perdidos. Si, Entity Framework es absolutamente increíble, pero en su contexto – no sirve para todo. Al igual que muchos otros. Y el problema se agrava cuando hay múltiples opciones para un framework: no se sabe cual escoger, porque “todos hacen lo mismo” y todos son “maravillosos”.

Otro ejemplo, un “curso” de la MVA (Microsoft Virtual Academy) acerca de programación multiplataforma con Xamarin. Lo siento, pero eso no es un curso, eso es un tutorial de cómo pegar trozos de componentes – siendo generoso. Hace falta realmente Prism para hacer un “Hello World” en Android? No. Ni de lejos. El problema es que hacer el 90% del tutorial dejó de consistir en programación universal de aplicaciones para Android, iOS y Windows Phone para convertirse en cómo configurar una aplicación MVVM  – de una sola pantalla. Una sola! Queréis un excelente libro al respecto? No dudéis en descargar el ebook gratuito Creating Mobile Apps with Xamarin.Forms, Preview Edition. Ni MVC, ni NuGet ni nada – simplemente cómo se programa – porque el autor del libro asume que lo que haga la aplicación es cosa tuya. Y que sabes hacerlo.

Parece que hoy, todo lo que no se pueda escribir en doce (o mejor cinco?) líneas de código es “arcaico” o está mal hecho o “pues anda que no te has complicado la vida”. Ni mucho menos. Los componentes ayudan, pero cuando se limitan a una función concreta dentro de nuestro proyecto y, sobre todo, se adaptan a nuestra forma de trabajar. Si un framework, una librería, un componente define un cambio estructural en un proyecto, se debe buscar otra alternativa.

Programamos máquinas. Cuanto más liviano sea el proyecto, el ejecutable, el servicio web, mejor será el rendimiento de nuestra solución. No todo viene envasado en un componente de NuGet. A veces (la mayoría) toca mancharse las manos y hacer las cosas por uno mismo. Y lo mejor del caso, es que muchas veces esa es la forma correcta de hacerlo.

Anuncios
Categorías:Desarrollo, Opinión
  1. Aún no hay comentarios.
  1. No trackbacks yet.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: