Que funcione. El resto es secundario.

Hace poco hice un proyecto para manejar información de mis clientes. Empecé a hacerlo en Rails, pensando que de esta manera podía reutilizar el código mas adelante y hacer una página que pudiera servirle a otros, o al menos mostrar un código Rails como proyecto Open Source para tener algo nuevo en GitHub.

ERROR

Los proyectos propios tienen que tener un objetivo único. Y si es un proyecto personal, en la mayoría de los casos ese objetivo debe ser resolver un problema. La reutilización, la utilidad que pueda tener para otros, la limpieza de código para ser mostrado, todo eso es completamente secundario y sólo debería tenerse en cuenta luego de haber terminado el proyecto y haberlo usado un tiempo.

Como diría Torvalds, si no resuelve una necesidad inmediata entonces seguramente está sobre-diseñado.

Finalmente abandoné el proyecto en Rails (que ya cumplía con toda la funcionalidad, pero me daba vagancia hasta iniciar el daemon de Rails para usarlo), y terminé haciendo en Ruby una pequeña herramienta de consola que me permite administrar fácilmente esta información con una base de datos SQLite.

Ventajas

– Lo hice en menos de dos horas.

– Interfaz ultrasencilla por línea de comandos.

Simplemente escribo lo que quiero que pase (ej. client create “cliente”).

Interacción mínima – mouse = developer feliz.

– Casi no tiene dependencias. Funciona sin necesidad de ningún daemon prendido.

La aplicación de Rails necesitaba un servidor web y una base de datos MySQL corriendo.

– Código custom, sin convenciones.

El código custom, especialmente en proyectos pequeos, permite adaptarnos muchísimo mejor a las necesidades. Además, tener una estructura custom del proyecto favorece a la memoria del código. Supongo que tiene que ver con que al verse uno obligado a tomar decisiones sobre dónde poner los archivos, esto asienta en la memoria la estructura del proyecto.

– No me perdí nada de Rails

Usé la gema ActiveRecord así que manejé la base de datos sin tocar SQL.

– Performance

A veces cargar algunas gemas o no puede hacer que la aplicación de consola tarde algunos milisegundos mas en realizar alguna tarea. Al tener un código custom, podés hacer que sólo cargue las gemas cuando la aplicación lo requiere.

– Refactor fácil

Al no estar atado a una estructura de directorios fija como Rails, tenemos total libertad al hacer refactor. No tenemos que adaptarnos a las convenciones, sino al problema concreto con el que estamos lidiando.

Aprendizaje

– No hacer proyectos web en un principio, a menos que no quede otra.

Hacer algo que funcione para uno, bien rápido. Luego, ver de exportarlo a web si realmente tiene sentido, si realmente alguien mas va a usarlo. Las tecnologías web necesitan un servidor, son mas complicadas de desarrollar y mantener (entre otras razones, porque están pensadas para ser multiusuario) y pocas veces valen la pena.

– Objetivo único del proyecto: resolver un problema. Lo demás (subirlo a GitHub, etc.) es secundario y opcional.

– No añadir funcionalidad / convenciones / buenas prácticas sólo porque se supone que debemos hacerlo. La prioridad es resolver el problema. Si la buena práctica ayuda a resolverlo entonces implementarla. Sino, no.

Por ejemplo, podría haber usado Bundler para manejar las dependencias. Pero, en realidad, es sobreingeniería. Bundler debería usarse cuando hay que deployar aplicaciones complejas con muchas dependencias.

– Minimizar las dependencias (daemons y gems) y mantener la aplicación liviana.

Anuncios

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