Y es que al final a todos los programadores nos acabamos perdiendo en lo mismo: echando líneas de código.
Se nos ha enseñado a diseñar, a pensar todos los límites del sistema, a preveer como tendrá que estar todo, las interrelaciones entre los demás sistemas, la problemática a encontrar, etc., pero realmente nos emocionamos cuando pillamos un teclado y empezamos con la quinta línea de código.
En ese momento lo normal es que pasen un par de abducciones (¿horas?¿días?¿meses? xD) y tengamos en nuestras manos algo que bueno… ¿funcionará? Pues vete a saber…
Personalmente soy un poco desastre en ese aspecto, tiendo a tirar líneas de código como un poseso y solo ir comprobando de vez en cuando que compila hasta que termino de hacer una o varias funcionalidades (dependiendo de lo que demonios esté haciendo, claro) y en ese momento ya cruzo dedos y a comprobar si funciona y que cosas hay que hacerle para que quede bonito y funcional…
Aunque suene caótico, al final creo que es la mejor línea de trabajo. Básicamente lo veo como que hay que tener un gran plan de dominación mundial… errr, de proyecto, y luego que a cada uno se le asigne una parte y él diseñe coherentemente esa parte y le toque hacerla. Quizás no sea la más productiva, pero sí la más lógica (o eso pienso, claro ^^U)
Una vez tienes el diseño perfilado y eres capaz de contarle a otra persona que demonios vas a hacer y cómo vas a hacerlo… pues a tirar líneas de código y a ver que pasa. El resto de la documentación (es decir, ponerlo bonito, con lacito y todo) me parece que no es útil hasta la finalización del módulo que estés haciendo, porque sino pierdes un tiempo excesivo con los cambios (que siempre hay) y que además, sabiendo que es lo que buscas, ya no es necesaria porque lo tienes perfectamente claro y, cuando se estabilice y esté más o menos listo para testear, es un buen momento para poner en limpio toda la documentación para que luego se pueda mantener…
Sé perfectamente que la ingeniería del software tradicional me golpearía vilmente pero pardiez, hay que ser un poco ágil y ver que a partir de cierto detalle, toda documentación previa es inutil, porque habrá cambios que solo se verán en el código y que harán que se tenga que cambiar a la par la documentación y el código…
Oscar says:
¿Ves? nosotros intentando convencer a los profes de la facultad de que las cosas no se hacen así, que primero se hace la práctica y luego se documenta, y ellos erre que erre que no
Así… así… no se puede hacer nada, que no :-P
Ucedaman says:
Muy bonito eso de que “luego” se documenta ¿pero en cuantos casos es cierto?
La única documentación previa al código que he visto suele ser la que hace el cliente o los jefes. Y para tener eso, prefiero no tener nada. (o a un grupo de chimpancés con portátiles haciendo R&S’s, que al menos me echo unas risas)
Paranoid says:
¿Documentación? El código fuente es la documentación, el resto son mariconadas :-)
Black Hole says:
1. Hombre, lo dicho en el comentario… Hay que documentar cosas pero, en mi opinión, a partir de cierto detalle es una pérdida de tiempo…
2. Pues por dónde ando se documenta… y bastante y encima todo en una lengua extraña que llaman inglés O_O
3. ¡Eso mismo! Con un par ;)
Disquete Enmascarado says:
Lo ideal es que a partir de cierto bajo nivel la documentación sobre porque el código sea autoexplicativo, pero de vez en cuando no está mal poner unos comentarios.
Yo los pongo para mi, para acordarme de los pasos siguientes que pensaba hacer (y siguen pendientes) y para los que vienen, para las veces que hay que dar un rodeo para lograr algo y así el futuro lector no se pierda.
Subiendo algo el nivel de abstracción, sobre las metodologías universitarias, pues opino que el desarrollo en cascada es el precámbrico de la profesión. No sirve para nada o como decía otro, programar a partir de un diseño y especificaciones es como andar sobre las aguas, muy fácil si están congeladas. Desgraciadamente ambas suelen ser agua, my friend.
Para ser mínimamente útil una metodología debe ser iterativa y reflejar el nivel del conocimiento que se tiene del problema en cada caso, que suele ser poco o nada al principio, y cual es nuestro usuario.
Si el usuario es final lo que falta es un manual de usuario, pero si estamos haciendo una librería nuestro cliente es otro desarrollador y ahí sí que hay que explayarse en la parte técnica, para evitar los momentos “así sí, no te jode!”. Recordemos que si no usamos licencias libres, nuestro desarrollador no podrá ver el código de nuestra librería y lo que escribamos será su única guía.
Creo que los diagramas UML son útiles para comunicar la arquitectura de la aplicación y facilitan el reparto de líneas de código. También creo que el modelo no debe ser algo que hace un diseñador y permanezca inmutable, sino que sea editable por casi todo el equipo. Creo que debería haber una relación entre modelo y código parecida a la que hay entre guión y dibujo en el método Marvel del cómic.
Lo que actualmente hecho en falta es algo parecido a un CVS para UML o un formato de fichero amigable con el CVS. Con amigable no me refiero a la castaña de XMI, sino a algo que separe presentación del modelo de la información estructural del modelo en sí. Estoy harto de que por mover una caja o pintarla de verde cambien 500 líneas del UML. Como para mezclar cambios, vamos.
Black Hole says:
Totalmente de acuerdo con todo. Jo, deberías postear algún día cosas así en tu blog ^^
Pd.1. La verdad es que es un problema dónde guardar los datos uml. El problema también se encuentra en como guardar dichos datos, porque no hay un estándar en el formato…
Pd.2. ¿Método Marvel?
Pd.3. ¡¡¡¡¡¡¡¡¡FELICIDADES!!!!!!!!!! ;)
brie says:
Pues yo en el cole usaba un tiralíneas para hacer dibujo técnico… siempre me quedaban pegotes y se me corría la tinta… vale, es que no sé qué decir :D
Drizzt says:
Yo también! yo también! yo también usaba tiralíneas en EGB. Y había de dos tipos: de los guarrillos de SAMER (creo que era esa la marca) que sólo podían hacer los trazos gordos (aunque los cerraras del todo) y los STAEDLER (como se escriba) o similares, que podían hacer un trazo muy fino.
Luego había otra opción -modo bricomanía on- que era coger una lija de metal muy fina (las tenía mi padre para quitar o rebajar soldaduras) y con mucha paciencia ir rebajando la punta gorda de los Samer esos hasta hacer el tiralínes con la punta fina y uniforme, pero al menos en mi caso la línea del “tuneao” cuando lo cerrabas del todo era inconstante por los “surcos” que la lija había dejado en el metal (faltaba pulirlo y no tenía/sabóa con qué).
A mí me gustaba bastante y no dejaba ni manchurrones ni nada, y tenía bastante práctica, porque tenía que hacer con mis staedler mí lámina impecable y la de mi “guardaespaldas” de EGB con ligeros defectos aunque sin manchas para que llegara a un 7 y no cantara mucho.
Juas… me enrollo, pero es que he visto el de Brie, y me he acordado que los tengo guardados en el cajon de la mesa del PC XDDD.
brie says:
Caray, tabas hecho un artista :D a mi me quedaban muy marranos, no estaba yo destinada a ser una artista de la pintura y el dibujo… así que tenías un guardaespaldas en el cole? yo era muy pegona, en parvulitos me castigaron de cara a la pared por darle un hostión a una amiga mía… qué carácter, madre :D
Disquete Enmascarado says:
Bueno, vale, lo confieso: Hackeé las láminas de dibujo tras ver que el tiralíneas era un engendro horrible. En su lugar usé un rotring de punta fina ;)
Black Hole says:
7,8,9,10. Otra confesión… yo hice lo mismo que Disquete Enmascarado ^^UU
Ucedaman says:
Yo las hacía a lápiz y luego las retocaba con Photoshop :p
Mentira… las hacía con Rotring…
Black Hole says:
Ey, no mientas… ¡¡lo hacías con el Paint de Windows!! ;P