VERSUS: Batalla por la productividad, IDEs completos VS IDEs ligeros.

Christian de la Fuente

Álvaro, parece que te has quedado un poco anclado en los 90, con ese estilo retro de programación que me llevas, yo opino que te tienes que modernizar un poco y dar un paso al futuro en cuanto a la forma de desarrollar…

Primero, los visualizadores de código integrados cuando se desarrolla son una gran ayuda a la productividad desde varios niveles. Para empezar, la propia definición de las funciones, las clases, incluso los tipos de variables, todo señalizado con unos colores o una tipografía distinta, nos ayudan a desarrollar aplicaciones más rápido y a que la calidad de código sea mejor instantáneamente, sin que tengamos que repasar después con herramientas externas sobre estilo o complejidad.

También está el autocompletado de variables o métodos mientras se desarrolla que te da un aporte extra de velocidad, por no hablar del hecho de que se resalten variables mal referenciadas, o que no se usen, importaciones erróneas o cualquier tipo de error mínimo que mientras vas desarrollando se te pueda pasar.

Todos sabemos que la refactorización de código para aplicaciones grandes y/o complejas puede ser un suplicio si no tienes una herramienta que te ayude. En este caso los IDEs nos proporcionan la posibilidad de refactorizar nuestro código, desde renombrado de funciones hasta disminuir la complejidad ciclomática de alguna función y replicar el cambio en todos los archivos que sea necesario (como importaciones desde otras librerías del proyecto). Intenta hacer eso desde tus métodos antiguos y tendrás que usar 2 o 3 herramientas distintas.

Una gran ventaja de muchos IDEs es que ya existe la posibilidad de manejar herramientas externas desde el propio editor. Esto va desde tener ya agregado el control de versiones (ya sea Git o SVN) y poderte mover entre ramas, e incluso subir cambios o resolver conflictos, hasta tener herramientas externas necesarias para el correcto funcionamiento del proyecto que estés desarrollando, como contenedores Docker o Vagrant.

Hay una cosa clara: los IDEs son herramientas hechas por y para desarrolladores, por tanto crecen y evolucionan en función de las necesidades de los usuarios. Por ejemplo, una nueva versión de un IDE puede integrar la conexión con un componente que esté en plena expansión tecnológica y ayudar a programar más rápido si no se tiene conocimiento sobre éste o incluso hacer de toma de contacto con nuevas tecnologías de una manera más “amigable”.

Dos razones que llevan los IDEs a un nuevo nivel de programación son: testing y debugging. La gran mayoría de IDEs tienen integrado un módulo de testing y cobertura de código algo que es realmente útil para poder desarrollar código de calidad y robusto. Por otro lado, al tener integrado un debugger en el propio desarrollo (sin tener que usar ninguna librería o herramienta externa que nos lo proporcione) se detectan mucho antes los posibles bugs o incluso las capas por las que están pasando nuestros datos cuando introducimos nueva funcionalidad.

En lo único que puedo estar de acuerdo contigo es que cuando necesitas cambiar código directamente en un servidor o en algún entorno que no sea el habitual, la gran mayoría de veces no dispones de los medios necesarios para desarrollar con un IDE, ya sea por falta de tiempo o recursos. Algunas veces estamos obligados a trabajar con herramientas más simples pero más extendidas como Vim. Aunque sea más cómodo y rápido trabajar con un IDE vitaminado también debemos conocer otras opciones más modestas que nos ayuden a ser unos auténticos todoterreno.

Alvaro León

Christian, ya sabes que el pulso con el ratón no es mi fuerte, siempre he preferido no levantar las manos del teclado y, llámame rebelde, pero normalmente me gusta tener control sobre lo que hago en contraposición a "la magia" de un botón.

El argumento de la pantalla monocroma no te va a servir. Bien sabes que el resaltado de código, dependiendo del lenguaje, no es problema. Los IDEs ligeros ya incorporan información de palabras reservadas y además es extensible. ¿Autocompletado? Sin problema, la capacidad de vitaminización de estos IDEs ligeros es altísima, podemos acceder a sugerencias de autocompletado o incluso dar un paso más de introspección para ver los métodos, objetos, librerías o cualquier recurso disponible al que quieras acceder de tu lenguaje de programación.

La productividad en la edición de código es la mejor, contrastada. La ventaja competitiva de un IDE ligero es la de prescindir del ratón, de manera que todo lo que necesites hacer, puedes hacerlo sin levantar tus manos del teclado, lo que te va a ahorrar tiempo, esfuerzo y cansancio. Y vale, por echar un poco de piedras sobre nuestros tejados, a veces se echa de menos un poco más de “inteligencia” que si te da un IDE muy orientado y específico. En ocasiones las tareas de refactorización se pueden convertir en una tarea cercana al masoquismo...

Me hablas de integración de herramientas. SCM, testing y debugging desde el propio IDE. Estoy de acuerdo que esto puede ser una ventaja casi siempre que no te sobrecargue y “crashee” tu máquina. Los IDES ligeros no pretenden engañar a nadie, si quieres puedes escribir comandos por consola directamente, tener plugins para integrar herramientas, lo que quieras… Pero, sinceramente, prefiero hacer un ctrl-Z y salir a la consola para tener total control de que estoy haciendo.

En una cosa estoy de acuerdo contigo, los IDEs son y crecen para los desarrolladores, por eso la posibilidad de customización aquí es ilimitada. No sólo hablamos de un ambiente configurable, si no de integralmente personalizable: desde detalles visuales a comportamiento por defecto del editor. En Vim, por ejemplo, podemos configurar todo lo relevante a la hora de la producción de código resumidos en más de 150 settings nativos de Vim más aquellos que la comunidad hace configurables. ¡Ah sí! ¡La comunidad! Cuenta con más de 20 años a sus espaldas, tanto desarrollando y mejorando el core del editor, así como compartiendo sus ficheros de configuración, macros y extendiendo las capacidades del editor. No está mal, ¿no?

En cuanto al consumo de recursos, es mínimo. No es necesario una gestión supersofisticada multihilo de los componentes del editor. Este tipo de editores son muy robustos, y si consigues romper algo, posiblemente no ha sido su culpa. ¿Y si pasa? ¿He perdido todos mis cambios? ¡No! En más de veinte años, y después de que seguramente le haya pasado a algún insensato, los IDEs ligeros se han cubierto las espaldas a la hora de implementar los sistemas y políticas de recuperación ante fallos. De nuevo, es altamente personalizable, puedes guardar tus avances en un fichero de swap eligiendo tu propia política sobre cuándo hacerlo.

Y sí, suelen ser feos. Aunque hay templates e incluso plugins para dar una vuelta de tuerca al estilo consolero que suelen tener estos editores. De todas formas, si eres un extreme programer ¿por qué deberías preocuparte por bonitos colores y botones biselados ;)? Bueno Christian, seguiré en mis trece, aunque le iré echando un vistazo a tu pantalla con ventanas de vez en cuando a ver si se me pega algo...