Durante toda la carrera me hicieron trabajar sobre «proyectos nuevos» en el sentido que siempre puse la primera línea de código. Al mismo tiempo, los proyectos terminaban cuando aprobaba la materia y el código nunca más era tocado por nadie más, más allá de mi y mis compañeros de grupo.
Estas situaciones llevadas al «mundo real» resultan ser ficticias, rara vez escribimos código para que nunca más sea tocado. Y al mismo tiempo muchas veces nos toca trabajar sobre código ya existen que ha sido desarrollado por alguien más, a quien tal vez nunca conozcamos y que podria incluso vivir al otro lado del globo.
Lo triste es que esto es moneda común en los ámbitos académicos. Son contados los casos en los que los alumnos tienen que trabajar sobre código existente. Ojo, no me refiero a trabajar con librerías, algo que sí es común, sino a trabajar sobre código fuente de un aplicación desarrollada por alguien más. También resulta poco común que el código escrito por un grupo de alumnos, tenga «vida» más allá de la aprobación del trabajo.
Pasando en limpio:
- En la academia los alumnos trabajan sobre proyectos/productos empezando de cero.
Pero en la industria muchas veces nos toca trabajar sobre proyectos/producto ya existentes. - En la academia los alumnos trabajan sobre productos durante un período «corto» de tiempo y una vez completado el alcance originalmente acordado no vuelven a tocarlo.
Pero en la industria los productos evolucionan y luego de su versión inicial son modificados cientos/miles de veces a lo largo de su vida útil.
Con este planteo lo que quiero decir es que es necesario que la academia tome conciencia de esta situación y haga algo al respecto. Conozco algunas iniciativas que ya están trabajando en esta línea, pero eso será parte de otro artículo.
Continuará…
No se que tan nuevo es, pero la catedra de Taller de Programacion II esta haciendo una diferencia en eso, todos, o al menos casi todos los cuatrimestres plantean un TP con base en codigo heredado, el codigo heredado es el desarrollo del mismo TP del cuatrimestre anterior por parte de otro equipo, el codigo se pasa de cuatrimestre en cuatrimestre y los que va variando del objetivo del TP son las funcionalidades a agregar sobre las ya existentes.
Se ve que esta interesante lo que implementaron, pero hay algunas cosas que no me gustan, por ej la imposicion del codigo heredado viene con la imposicion de trabajar con X tecnologia (en el caso de Taller II, es Java) mientras que en el ambito profesional casi se puede decir que pasa lo contrario: si bien tb nos «imponen» trabajar con determinada tecnologia, esta siempre sera la mas afin a nuestras habilidades (por ej, si tenes experiencia en Ruby, lo mas probable es que te hagan trabajar en proyectos de Ruby)
Igual las dos cosas para mi estan buenas, por un lado, el usar alguna tecnologia diferente te ayuda a diversificarse (aunque no se que tanto si el lenguaje siempre es java), y por el otro el usar una tecnologia afin te permite explotar mas tus capacidades, solo para mi el punto era que en una situacion real, seria muy raro que te «impusieran» trabajar con una tecnologia que «no dominas», casi siempre te hacen laburar con algo que ellos saben que vas a ser productivo… y esto puede ser bueno o malo, a veces q te hagan trabajar con un lenguaje o tecnologia que no te gusta puede ser un plomo, pero otras veces es uno el que esta deseando trabajar con algo diferente, en mi caso me gustaria hacer algo con javascript (digo, mas alla de lo minimo requerido para hacer web, que siempre esta)
Muchas gracias, me alegro que esten haciendo lo que comentas, cuando yo la curse era más tradicional.
Hola Nico !
En la materia «Práctica del Desarrollo de Software» de la Licenciatura de UNQ, que abrimos por primera vez este cuatrimestre, tenemos una idea relacionada. En principio, este es el primer cuatrimestre, así que sí comenzamos de cero :S Pero estamos haciendo como práctica un producto/servicio comunitario para compartir precios. En lugar de tener un TP, y que cada grupo haga lo mismo que el grupo de al lado, planteamos la idea de, entre todos, hacer un producto. Así cada grupo encaró una parte. Tenemos una app android que utilizando la cámara lee el código de barras de un producto, y consume un servicio REST para consultar y actualizar un precio. Luego está la parte del servidor, que además, tiene una webapp para consultar y cargar precios también.
Los chicos definieron la arquitectura con Android+Scala, y Play2+Scala+Mongodb.
La idea es continuar con este desarrollo en futuros cuatrimestres, donde los próximos alumnos, sí se van a encontrar con la dificultad de trabajar sobre código ya escrito por otras personas.
Incluso nada impide que los chicos una vez que hayan terminado la cursada, puedan seguir contribuyendo en el desarrollo.
Tenemos el código del proyecto en bitbucket (https://bitbucket.org/practicadesw) y si bien todavía no formalizamos, la licencia será LGPL.
A todo esto, contamos con varios servicios para el desarrollo hosteados en un server de la universidad (http://practicasds.no-ip.org:81/jenkins/ por ejemplo).
Veremos en futuros cuatrimestres cómo resulta la idea 🙂
Saludos!
Muy bueno Javi, pinta muy interesante, ojalá camine bien.