Los desarrolladores provenientes del mundo .Net suelen esgrimir varios argumentos en contra de Java, algunos con razón y otros simplemente por mera pereza.
Uno de los argumentos más comunes en contra de Java es la cantidad de tecnologías y bibliotecas que lo rodean, muchas para hacer lo mismo, y cuando deseas comenzar te encuentras a ti mismo perdido en un mar de información muchas veces bastante desorganizado, prácticamente en un caos.
Pero es bueno o malo tener tantas bibliotecas para hacer lo mismo?
Lo positivo desde la perspectiva de los nativos de Java:
- La diversidad de opciones para lograr un objetivo.
- Casi siempre es código Open Source, puedes corregirlo si lo necesitas.
Lo negativo desde la perspectiva de los nativos .Net?
- No sabes por donde comenzar.
- No sabes cual de las tantas es la mejor. Pongamos por ejemplo esta lista de Plantillas para Vistas MVC: JSP/JSTL, Thymeleaf, Tiles, Freemarker, Velocity. Quiere decir que incluso dentro del mismo mundo Java puede ser alta la curva de aprendizaje para incluir un nuevo miembro al equipo.
- Documentación poco centralizada.
- El tiempo de caducidad de las tecnologías es relativamente mucho más corto que en .Net.
- Y finalmente un árbol de dependencias entre bibliotecas con muchísimos niveles, una historia sin fin muchas veces.
Están equivocados los nativos .Net? - No, no lo creo.
Recuerdo perfectamente que años atras trabaje en un proyecto para hacer un sitio web de juegos. El líder del proyecto (una de las personas con más conocimiento de Java que existen) se decantó o por una sería de bibliotecas bastante avanzadas y complejas. Un par de años después le pedí montar el sitio en un server de pruebas para mostrarselo a un cliente y saben que?
1- Necesitaba de un tiempo enorme para poder instalar todo desde cero. Al final, nunca se instaló nuevamente.
2- La principal biblioteca que usabamos, el core de todo, ya no se desarrollaba más. Quedaría por siempre en el olvido. Además que la enorme lista de dependencias ya corrían la misma suerte.
Entonces, en medio de todo este caos se necesitaba algo o alguien que pusiera orden y simplificará todos estos procesos. Allí es donde surgen estas herramientas de manejo de proyectos, administración de dependencias, actualizaciones automáticas, empaquetado y distribución de las mismas.
He aqui por qué a los nativos .Net les resulta tan complejo entrar al mundo Java, porque en honor a la verdad nunca han tenido ese desorden: siempre han contado con MSDN con toda la documentación bien centralizada, lo mismo online que offline.
Entonces en el mundo Java surge Ant, Ivy, Maven, Gradle, etc., y queda solucionado uno de los problemas, pero volvemos a lo mismo: y cual de los tantos manejadores de proyectos uso?
Realmente es irónico pero aún lo que se creó para organizar el caos crea aún más caos, ja ja.
Bueno, el más famoso y utilizado es Maven, creo yo, pero se esta potenciando últimamente con mucha fuerza a Gradle. No obstante, Gradle es un partner de Maven porque hace uso de sus repositorios y de todo su conocimiento acumulado durante años.
Gradle es hoy utilizado por Android Studio. También Gradle está hoy a la par de Maven en los tutoriales de Spring Framework.
Aqui les dejo una lista de recursos para profundizar en el tema:
http://maven.apache.org/what-is-maven.html
http://maven.apache.org/maven-features.html
http://spring.io/guides/gs/maven/
https://gradle.org/
https://gradle.org/learn
http://spring.io/guides/gs/gradle/
No comments:
Post a Comment