Primero documentar, luego programar

Desde que pasas por las clases de ingeniería del software no hacen más que repetirte que primero hay que definir requisitos, realizar una cantidad ingente de diagramas UML, seguir una metodología, plantearte el ciclo de vida que vas a seguir,etc. Se supone que cuando realizas el proyecto de fin de carrera tienes que aplicar todo eso, primero dedicas tiempo a lo que se denomina planificar y documentar y luego pasas al desarrollo en estado puro, siempre dependiendo del tipo de metodología utilizada.

Dejando un poco de lado la teoría, y llevándolo a la práctica, opino que realizar una correcta planificación de tareas así como definir los requisitos es fundamental en cualquier desarrollo. Es cierto que resulta una tarea pesada, que estas deseando ponerte a cacharrear, ver los frutos de tu trabajo, pero después de dos PFC puedo decir que es lo mejor que he podido hacer. Es tan simple como plantearte qué quieres hacer y en qué orden lo vas a hacer, y si realizas algún diagrama en UML ya tienes claro cómo lo vas a hacer. Luego, cuando toca programar, a  muchos de los problemas ya les tienes una solución. También se evita que tu programa empiece a crecer con mejoras y más mejoras, es decir, como previamente te has planteado lo que quieres hacer, ya tienes unos límites de hasta donde debes llegar para adaptarte a los tiempos de desarrollo establecidos.

En definitiva, aunque me quejara de estar documentando cuando empecé el proyecto, me alegro de haberlo hecho así. Y no quiero ni imaginar como hubiera sido tener que terminar de programar y ponerme a realizar toda la documentación, ingeniería inversa se llama. Ahora en vez de dedicarme a poner todo bonito en un documento de Word, hubiera tenido que hacer toda esa pesada tarea para que no me sirviera de nada, trabajo y tiempo perdido.