Comprender el diseño del Soft
Como ya puse en algún post anterior, cuando estas en la Universidad te enseñan muchas cosas. En concreto parte de mi formación, que no la más importante, era en programación. Uno de los últimos profesores que tuve nos enseñó, entre otras cosas, una serie de buenas prácticas a la hora de programar, específicamente para JAVA pero aplicable a la inmensa mayoría de lenguajes de programación. Dichas herramientas y “buenas prácticas” me fueron de vicio a la hora de hacer el TFC hará ya un añito, y entonces entré en el mundo laboral.
Como también decía en algunos posts, es fácil comprender que lo que se enseña en la Universidad es “lo ideal”. Como deberían hacerse las cosas, con muestras de que todo eso hace que los desarrollos sean mejores, más estables, más modulares, algo importantísimo hoy en día, y sobretodo y definitivamente mejores. Que luego llega un momento, en lo profesional, que es imposible cumplir todo, ya sea por tiempo, ya sea por falta de recursos.
El problema viene, cuando, tras casi 1 año trabajando, te das cuenta que lo normal es que no se cumpla apenas ninguna. Que si se cumple alguna de ellas es de puro milagro, y quieras que no, es algo que repercute negativamente. Sobretodo cuando te sueltan en medio de un desarrollo y tienes que comenzar a lidiar con código ajeno, especificaciones “hechas con la punta de la polla” y dimensionamientos que son claramente más bajos de lo que realmente deberían, eso sí, vendidos al cliente con lazo de seda y cobrado en consecuencia, básicamente algo como lo siguiente.
