Sobre la Programación Orientada a IDE©

Hace algún tiempo que vengo luchando contra este concepto[*]. La idea viene de la falacia que todo hay que hacerlo desde dentro de la IDE. Así, la IDE es la que termina guiando nuestro desarrollo y volviéndolo uno con la decisiones unilaterales que han tomado sus desarrolladores.
No estoy para nada en contra de las IDE, solo de las IDE que te obligan a hacer las cosas de la manera que se les antoja. Ésta es una herramienta y no quiero que me obligue a nada, yo quiero usarla como se me antoje y mi profesionalismo me indique para expresar mi arte.

Yendo al contexto Java, que es donde me siento cómodo seguro por el momento, me he encontrado con incontables casos donde a la pregunta de “cómo es su ciclo de deploy” la respuesta comienza con “exportamos el proyecto desde eclipse”…
Por qué esto está mal (sin orden particular)?
• Se depende de un humano para armar ‘entregables’ (no hay integración continua)
• Atenta contra la posibilidad de incluir a un nuevo integrante al equipo que haga uso de otra herramienta
• Tenemos que manejar las dependencias desde el eclipse
Otros efectos colaterales:
• Tendencia a ensuciar los controladores de versiones con cosas propias de las IDE
• Tendencia a nunca entender lo que una IDE hace tan mágicamente (aunque esto es algo inherente a la estupidez en cualquier contexto)
Soluciones a esto:
• Uso de Maven

Por qué Maven?
Maven no es nada de otro planeta ni hace magias oscuras. Hace muy pocas cosas y las hace bien. Mediante el uso de Maven se obtienen algunos puntos muy positivos: controlar dependencias, manejar ciclos de deploy (incluyendo el empaquetado) y unificar (de manera IDE agnóstica) convenciones a la hora de trabajar. Ésto último tiene un punto a destacar alucinante, que venga alguien totalmente ajeno a nuestro desarrollo y no se sienta [tan] perdido frente a cientos de archivos de código; va a saber dónde estan los fuentes, dónde buscar tests, dónde mirar a grandes rasgos qué bibliotecas se usan y va a poder generar un entregable corriendo un solo comando.

Qué es lo peor que podés hacer?
Intentar ajustar maven a tu proyecto y no al revés. Maven es una herramienta para organizar, que si bien deja que modifiques sus convenciones al hacerlo estarías perdiendo muchas de las cosas que destaqué en la pregunta anterior. Cuando te convenzas que estas son las cosas que querés que tu proyecto cumpla, pagá el precio por haber comenzado por la senda del mal y purga tu alma moviendo archivos y repensando los paquetes que tiene tu sistema.

Qué es algo feo feo de ver?
A alguien usando JBoss Developer Studio para mostrar las maravillas de Seam (básicamente hot deploy) cuando realmente conciliar estas maravillas con las ‘buenas prácticas’ antes mencionadas es imposible (y lo peor es que la mayoría de la gente valora más un entorno de desarrollo a-La PHP en lugar de un proyecto ordenado).

Quiénes son los más horrorizados con no comer/ver la tele/dormir con la IDE?
Los desarrolladores .Net . Ellos han comprado una serie de preceptos guiados por Visual Studio y sus wizards, que se les hace arcaico y elitista tratar de usar herramientas de línea de comando, el resto simplemente “la complican de gusto”.

Qué es lo que tendría que hacer un desarrollador nuevo cuando entra a un equipo?
• git clone [o el scm que quieran]
• mvn eclipse:eclipse [o la ide que quieran]
• [abrir la ide y buscar las cosas como tu intuición te indica]
• mvn package
• [deploy]
• [probar la aplicación]

Qué alternativas similares hay?
Para Java ninguna[**] y no me parece mal. Creo que se puede confiar bastante en los desarrolladores de maven como para que guien este camino.
Hablar de ciclos de desarrollo en otros lenguajes no puedo, solo comentar que en C se adolece del mismo problema que generó Ant en su momento, Autoconf/Autotools son infinitamente poderosos, infinitamente complejos y no existe una manera estándar de hacer las cosas, realmente una pena; apenas crece un poquito un proyecto C meterse es una tarea heroica.

[*]: término que nunca antes había escuchado :)
[**]: ant+ivy me parece una aberración mutante

Advertisements

3 Responses

  1. Creo que elegir entre elegir un "IDE-driven-development" y "maven-driven-development" no hay mucha diferencia, en todo caso termina siendo lo mismo y sacrificamos nuestro "profesionalismo" en pos de desiciones de los dise~adores de la herramienta (maven, eclipse, o lo que sea). Maven es un excelente producto, pero no la bala de plata de la gestion de proyectos. Y no veo razon para crucificar a las IDEs. Si un equipo realiza deploys a mano porque no tiene un entrno de interacion continua no es culpa del eclipse. Quiza tampoco culpa del equipo!Lo bueno es que haya variedad y no tengamos que adaptarnos a una herramienta, sino que sean las herramientas las que se adapten a nuestros proyectos.

  2. perdon, pero me quedo esto ultimo:"Creo que se puede confiar bastante en los desarrolladores de maven como para que guien este camino"y porque no en los desarrolladores de IDEs?Saludos!

  3. Diego, estoy de acuerdo que los programadores tienen que dejar mas las IDEs y usar herramientas mas poderosas. El tema es que no todos los programadores estan tan interesados en las herramientas ni en el ciclo de deploy sino en lo que reciben a fin de mes. Vos sos parte de una elite que esta apasionado por lo que hace ;)Te felicito

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s