Entorno No Integrado de Desarrollo (UDE)

Casi todos los desarrolladores que conozco acostumbran utilizar herramientas pesadas para hacer su trabajo.

Una de dichas herramientas, el IDE (entorno de desarrollo integrado) suele ser un programa grande que incluye en un sólo paquete las herramientas más comunes que un desarrollador puede llegar a necesitar.

Ese es el problema: asumir que el desarrollador VA a necesitar las herramientas, cuando en realidad sólo PUEDE que las necesite.

Por esa razón, tiene un tiempo ya que no utilizo IDEs para mi trabajo. O como leí alguna vez, utilizo un entorno NoIntegrado de Desarrollo (Unintegrated Development Environment).

Armar un entorno así no es nada difícil, y sólo requiere de un conocimiento concisio de las herramientas que en realidad tiene a su disposición un programador para hacer su trabajo, según el sistema sobre el que trabaje.




El primer elemento, el editor de texto, debe ser una herramienta sencilla y a la vez eficaz, que haga bien su trabajo. Suele ser una herramienta muy especializada, y aunque para muchos pueda parecer trivial, la realidad es que es la más importante de todas. Ideal que cuente con resaltado de sintaxis, y si es posible, integración con algunas de las otras herramientas (lo que haría del editor de textos, para efectos prácticos, un mini-IDE, pero eso es otro asunto). En gustos se rompen géneros, los hay para entornos gráficos de escritorio como para entornos de consola. Mi favorito, Emacs, tiene la posibilidad de integrarse con muchísimas herramientas más, además de poder ser programado y extendido (usando Lisp) para hacer mejor las labores que un editor de textos potente (propio de un programador) debe realizar. Claro, también está vim, gedit, en windows está notepad++, y un largo etcétera...

Anexo al editor de textos, no viene nada mal alguna herramienta para búsqueda de declaraciones, para localizar fácilmente los encabezados y declaraciones de funciones, clases y demás bichos que viven en un programa común. En Unix existen ctags y etags, que generan un pequeño archivo con las referencias para localizar estas declaraciones y que puede integrarse fácilmente a Emacs o vim.

Dependiendo el lenguaje de programación utilizado, por supuesto que se tiene que tener el compilador o intérprete adecuado al lenguaje en cuestión. Incluso los IDEs dependen de esta herramienta externa, pues los lenguajes de programación son algo tan vasto, que incluye librerías y extensiones por sí mismas, e incluirlas en un mismo paquete ya sería una exageración para el de por sí exagerado tamaño de los IDEs. No entraré en detalles de esta herramienta, ya que depende siempre del lenguaje en cuestión el tener el compilador o intérprete y las librerías adecuadas correctamente instaladas para su uso.

Y si el desarrollo que se está haciendo implica alguna plataforma específica, por ejemplo web, además se requerirá de algún entorno de desarrollo bien armado que incluya un servidor web, con cgi bien configurado, de forma que no sólo se escriba texto, sino que también se puedan hacer las pruebas adecuadas accediendo, por lo menos, a http://localhost , es decir a la propia máquina. Lo mismo aplica para motores de bases de datos y cualquier otro recurso del que haga uso el proyecto en el que se esté trabajando.

De la mano del proceso de compilación y lanzamiento para pruebas (o incluso a producción o 'deploy') del proyecto en que se esté trabajando, está la herramienta de generación y automatización de código. Compilar todo un proyecto puede ser un proceso complejo que incluya no solamente generar el código objeto (o como se llame en el lenguaje en particular que se use) de un archivo modificado, sino también puede haber dependencias entre los otros archivos, generación de código (por ejemplo para analizadores léxicos y gramaticales), producción de archivos de otros tipos (imágenes, documentación, etc.) que dependan directamente de otros archivos del proyecto. ¿Cómo hacer la vida sencilla a un desarrollador ante esta complejidad? La herramienta por antonomasia es make, que aunque se originó para proyectos en lenguaje C, es tan potente que puede ser usado para prácticamente cualquier proyecto de cualquier lenguaje, e incluso para cualquier otro proyecto que no sea de programación pero que requiera de la producción de archivos con base en dependencias.

Hablando del deploy, incluso este puede automatizarse de manera eficiente. Depende mucho del entorno en que el proyecto vaya a ser lanzado. Pensando por ejemplo en un proyecto web, si se cuenta con acceso SSH o FTP al servidor en donde será lanzado, se puede utilizar rsync. Algunos utilizan el versionador para estas labores, pero yo no lo recomiendo. Un versionador además de que incluye archivos ajenos al proyecto final ya lanzado, tiene un propósito específico. Recuerda: no uses un desarmador como martillo. Otros proyectos se lanzan en otros entornos o con otras condiciones. La idea en sí es encontrar las herramientas adecuadas que permitan estos procesos de manera sencilla, eficiente y precisa. Incluso simplemente copiar y pegar archivos puede servir, pero si se puede contar con una herramienta más avanzada (que mantenga por ejemplo un log del proceso del deploy, con capacidades de deshacer y revertir el proceso en casos de emergencia), mejor. Aquí, como en los otros casos, aplica también el principio básico de que, si no se cuentan con las herramientas adecuadas, habrá que crearlas. Por algo somos programadores, y por lo menos para el caso del deploy, algunos scripts en bash, sql, python y demás pueden bastar para lo que se requiere. 

Una de las herramientas más útiles que conozco para el desarrollo es el versionador. Con un versionador se puede, como su nombre lo indica, mantener versiones del código de un proyecto. ¿Para qué mantener versiones del código si de todas maneras lo que importa es el producto final? Por mil razones: a veces el desarrollo toma un camino que ya no agrada (porque funciona mal o porque cambian los objetivos) y es bueno poder regresar a una versión del código que no incluya esos últimos cambios; organizar equipos de desarrollo es muchísimo más fácil (en varios órdenes de magnitud) usando versionadores que administrándose como se pueda y dejando que todos hagan lo que deseen; los versionadores proporcionan la posibilidad de ramificar el desarrollo, dirigiéndolo hacia distintos objetivos cada rama, y posteriormente unificarlas de regreso, con los distintos desarrollos ya hechos de manera independiente. Hay muchos versionadores, pero los que valen la pena hoy en día son los llamados distribuidos, como Git (mi favorito) o Mercurial.

Y ¿qué desarrollo está completo sin un ciclo de depuración de errores? Alguna vez leí un artículo donde se mencionaba que el proceso de depuración (o debuggeo) conlleva cerca del 80% del tiempo de desarrollo de un proyecto. Así que más vale agarrarle el gusto a esta etapa del desarrollo, que está embebida dentro de todo el proceso, no es que vaya a encontrarse en algún lugar específico, al inicio o al final. Y se puede depurar haciendo simples prints de mensajes a consola, pero es mejor utilizar un debugger simbólico, como el que los IDEs acostumbran incluir. Claro está, dependiendo el lenguaje de programación usado, serán las herramientas de depuración con que se cuenten. Los proyectos en C y C++ pueden utilizar fácilmente gdb. Java cuenta con jdb. Python con pdb...

Dependiendo del lenguaje, sobre todo los interpretados, estos llegan a contar con una herramienta que a mi en lo particular me es muy útil. El shell del lenguaje donde se puede jugar libremente con el mismo, experimentar, probar cosas e investigar también. Python y Ruby, por ejemplo, tienen uno.

Y así puedo seguir enumerando más herramientas. Las que ya mencioné son las que más utilizo yo, pero existen otras. Por ejemplo, perfiladores de consumo de recursos (para la labor de optimización que, recuérdese, SIEMPRE se debe hacer hasta el final, y solamente una vez que ya se midió. El perfilador sirve precisamente para este propósito), o herramientas para armar pruebas (unitarias, funcionales, de estrés). Múltiples herramientas del sistema pueden aprovecharse para el desarrollo: buscadores de textos y de archivos, herramientas de diagnóstico, documentación, etc.


El punto es, como dije al principio, conocer todas y cada una de las herramientas individuales que suelen venir empaquetadas en un IDE, y así desmenuzadas, aprovecharlas al máximo y sin la obligación de tenerlas para no usarlas, con el consecuente consumo de recursos excesivo que los IDEs plantean. ¿O a poco no es cierto que Eclipse o Netbeans llegan a alentar tu máquina muchas veces?

Y además, se tiene la GRANDÍSIMA ventaja de poder elegir. Si un editor no te gusta eliges otro, si un debugger no te satisface, probablemente existan muchos más. Yo por ejemplo, cuando desarrollo en python, no utilizo el shell y el debugger por default que se incluyen con el lenguaje. Yo utilizo, como buen fan de la consola que soy, ipython como shell y ipdb (muy relacionado con ipython) como debugger. Es cosa de buscar, probar y elegir.


¡Ah! y no quiero terminar este post sin antes mencionar otro par de detalles de los UDEs (Unintegrated Development Environments). Conforme se quiera contar con más y mejores herramientas, se dará uno cuenta que el sistema sobre el que se trabaje también hará la diferencia entre PODER elegir, y TENER que elegir. Es decir, que la libertad que se tenga entre elegir por separado las herramientas para hacer un mejor trabajo de desarrollo, depende muy directamente del sistema sobre el que se trabaje. Y en algunos sistemas desafortunadamente, tanto la cantidad y disponibilidad de herramientas es más bien escasa (tanto que en muchos sistemas así a veces no queda de otra más que usar a fuerzas o a fuerzas un IDE), pero también las interfaces de desarrollo entre el proyecto y el sistema suelen ser pobres, defectuosas, mal documentadas, nada compatibles entre versiones diferentes del mismo sistema, en fin, que hacen de la labor de desarrollo lo que en inglés se conoce coloquialmente como un 'pain in the ass'. Yo por eso prefiero trabajar en un ambiente Unix. Es mi eleccion personal, sí, pero no sólo es mía, muchos desarrolladores estarán de acuerdo conmigo que trabajar en un sistema Unix es muchísimo más productivo, y hasta relajante, que trabajando en un Windows. Y claro, al decir Unix, abarco no sólo Linux o los BSDs, incluso Mac podría caer en esta categoría, lo malo es que no todos tenemos tanto dinero para pagarnos las herramientas, y además, en mi opinión, no es tan buen sistema para desarrollar: menos documentación, creo yo que menos gente en internet ayudando, más restricciones; es un entorno que, según leí alguna vez, podría compararse con un jardín amplio, grande y bello, pero que al final tiene bardas en los límites.

Y por cierto, acabo de mencionar casi por accidente el último recurso importante: internet. ¿Qué desarrollador puede preciarse de llamarse así si no sabe dónde y cómo buscar la información y documentos, ejemplos, ayuda que necesita entre otros desarrolladores (por ejemplo en foros o sitios dedicados a la consulta como stackoverflow) y que han enfrentado problemas similares? Simplemente para conocer más herramientas que cumplan las funciones ya enlistadas y otras, internet es fundamental. Yo soy de la opinión que un desarrollador no lo es más sólo por saberse un lenguaje o una tecnología de memoria al derecho y al revés. Esa función ya la cumple internet. Lo que se necesita es muchísima creatividad, y por supuesto un conocimiento y uso adecuado de las herramientas que convengan en el momento.