Esta es la discusión que tuvimos ayer en el trabajo, pero antes de empezar con el debate y dar mi opinión quiero diferenciar entre plataforma de desarrollo, que está claro que debe ser común a todos y herramientas de desarrollo (editor de textos, ide, cliente del sistema de control de versiones, etc).
En nuestro caso la plataforma de desarrollo está clara, Openbravo. Ahora bien, hasta el momento cada uno instala la versión de gnu linux que quiere, utiliza el editor de textos que quiere, el cliente de subversion que quiere… El tema ha sido que el jefe, que no es desarrollador, quiere que a partir del año que viene todos utilicemos las mismas herramientas para desarrollar.
Mi opinión es que es mejor que cada uno utilice lo que más le convenga ya que uno puede ser más eficiente con vim + el shell y otro con eclipse por poner dos ejemplos no muy compatibles pero que al final te dan el mismo resultado. También porque no sería la primera vez que escucho comentarios de gente que en su empresa le obligan a utilizar ciertas herramientas que bajan considerablemente su productividad.
Si todos utilizamos la misma versión de la plataforma de desarrollo ¿qué más dará que yo utilice un editor y otro desarrollador otro?. La excusa de cuanto más homogeneo más compatible y estable en este caso no sirve ya que eso se consigue haciendo que todos utilicen la misma plataforma, y ese es un punto de partida en el que todos estábamos de acuerdo.
En la universidad he hecho algunas prácticas de C++ con compañeros dónde mi versión de gnu linux era una y la de él otra. Al hacer el update con cvs (en aquel momento utilizábamos cvs) nunca tuvimos problemas, también porque intentábamos tener la versión del compilador y la biblioteca de C más parecida posible y a su vez con la de la corrección de prácticas.
También he estado durante años haciendo desarrollos por mi cuenta con amigos, chapucillas más bien, y por ejemplo uno de ellos utilizaba windows + dreamweaver para picar código html, javascript, css y yo desarrollaba casi toda la trastienda en php con eclipse. Al final todo quedaba en el subversion y a correr, nunca dió ningún problema. No importaba que cada uno utilizaramos herramientas completamente diferentes, al final el resultado era satisfactorio.
¿Qué opinais vosotros?
Cheli
Mi consejo es que sí. Con herramientas comunes de desarrollo es posible que tú pierdas algo de productividad; pero la productividad que adquiere el equipo completo al compartir herramientas compensa con creces lo que pueden perder alguno de sus componentes.
Errores, problemas que le surgen a un intengrante del grupo, ya le sucedieron a otro en su día, y al compartir herramientas se supera ese escollo mucho antes que si fueran entornos diferentes.s
Justamente ese es uno de los argumentos que esgrimia mi jefe pero yo no lo veo. Puede que yo me esté perdiendo algo por eso mismo me gustaría que me indicaras algún caso práctico respecto a los escollos. Te pongo algunos ejemplos, ¿qué escollo crees que tendría yo con vim que no tuviera otro desarrollador con kate? o ¿qué problema podría tener yo con kdesvn que otro desarrollador no tuviera con una extensión de eclipse?.
Los escollos los veo más en la plataforma de desarrollo e insisto, esa es común a todos.
En tu caso está claro que es mejor que cada uno utilice lo que prefiera porque, además de que estará más a gusto, sabrá desenvolverse mejor y como dices aumentará la productividad.
Si hablásemos de que algunos usan Windows y otros Gnu/Linux se entendería más, pues la codificación de caracteres en editores de texto plano es diferente, el compilador en C++ sería muy diferente (la experiencia en la uni lo avala xD) o, por ejemplo, la compartición de ficheros en red sería más toca-narices.
Pero vamos, si cada uno sabe lo que utiliza y cómo utilizarlo, una herramienta impuesta para que todo sea homogéneo es contra-productivo.
Hola:
Dile a tu jefe que me cae bien xD
Yo me refiero a desarrollar sobre Openbravo. Te voy a poner algunos ejemplos.
– En ubuntu, si no modificas el archivo de configuración los informes en jasper no se muestran.
– La tarea ant export.database ejecutada en diferentes entornos de desarrollo hacia pensar a subversion que el xml había cambiado completamente (bug solucionado para 2.40)
– Errores al dar de alta informes jasper en Openbravo dependiendo de si la base de datos es Oracle o Posgres
– Instalación o upgrade de cliente subversion en tu distro. Es un camino espinoso (al menos lo fue para la 1.5) que sólo debiera sufrirse una vez, y los que vengan detras copien lo que tu hiciste.
– Errores de configuación de eclipse (en este saco meto también errores de compilación, de build, …) que son específicos del sistema operativo que uses.
En fin, podría meterme listar muchos temas más pequeños que parece que son despreciables, pero que no lo son. Escollos que cuando los expones a tu grupo de trabajo, siempre alguien lo ha sufrido y te da la llave para que no lo sufras tu.
Si cada uno tiene un entorno de una madre diferente, por muy eficiente que sea en su entorno, siempre existirán escollos que nadie podrá ayudarle a superar y perderá mucho tiempo.
Voy a ver si puedo refutar todos los casos.
– En ubuntu, si no modificas el archivo de configuración los informes en jasper no se muestran.
Esto es como decir que en la mi instalación de vim como mi .vimrc no está configurado apropiadamente por defecto no me aparece el resaltado de sintaxis. Pues que quieres que te diga, tendrás que parametrizar tu entorno.
– La tarea ant export.database ejecutada en diferentes entornos de desarrollo hacia pensar a subversion que el xml había cambiado completamente (bug solucionado para 2.40)
Si sucede eso no es que haga pensar a subversion que ha cambiado sinó que realmente estará modificando el archivo, aunque sea metiéndo un carácter. En cualquier caso es un bug de la plataforma.
– Errores al dar de alta informes jasper en Openbravo dependiendo de si la base de datos es Oracle o Posgres.
Por suerte o por desgracia nosotros trabajamos con las dos bd dependiendo del proyecto y me imagino que la mayoría de asociados están en el mismo caso. De todas formas volvemos a tener un bug de la plataforma, no del entorno.
– Instalación o upgrade de cliente subversion en tu distro. Es un camino espinoso (al menos lo fue para la 1.5) que sólo debiera sufrirse una vez, y los que vengan detras copien lo que tu hiciste.
Si todos debemos utilizar una versión concreta de subversion porque es un requisito de la plataforma los mismos errores y problemas tendré utizando un gui que utilizando otro. Vuelve a ser un bug de la plataforma teniendo en cuenta que subversion pertenece a la plataforma.
– Errores de configuación de eclipse (en este saco meto también errores de compilación, de build, …) que son específicos del sistema operativo que uses.
Según mi premisa cada uno puede utilizar la herramienta que quiera y por tanto el editor que quiera lo que nos lleva que este problema lo tendrán los desarrolladores que hayan decidido utilizar eclipse, nunca va a ser común a todos. Desde mi punto de vista no aplica.
De todos los problemas que has dicho el único que podría considerar como un problema del entorno es el de ubuntu.
De todas formas repito, es mi opinión y puede ser equivocada o no aplicar bien en algunos escenarios.
No. Tienes razon en todos los puntos. Son bugs de plataforma; Openbravo.
Lo que pasa es que la realidad es que trabajamos sobre esa plataforma, y nos guste o no, esos bugs están ahi. Y más que saldrán.
Mi discurso es que en la realidad, es más eficiente que los 5 consultores (los que sean) de tu empresa trabajen todos con una imagen identica de disco duro.
No entro a valorar si es culpa de la plataforma donde desarrollan, si es culpa de sus entornos o del cabron de su jefe.
Para mí, es una realidad trabajando sobre la plataforma Openbravo.