Ingenieria y Diseño antes de escribir codigo.

[_eternal_]

Como veis el tema ese en los programadores de videojuegos?

Muchas veces veo que la gente no comenta el codigo y que nisiquiera piensa mucho antes de escribir codigo, sino que se ponen a saco a hacer lo que haga falta sin hacer ni un UML ni nada, me pregunto si no seria mejor hacer algo de UML o pensar antes de escribir codigo por si se puede hacer de otra forma mas limpia, mas legible, que se pueda reusar, etc...

Vuestras experiencias?

Saludos.

[Gallo]

Mi experiencia es que ningún UML que he hecho en 5 años se ha parecido al resultado final. Eso tampoco es malo y me parece lo mas natural del mundo, creo que tanto si se implementa con orientación a objetos, como con componentes o simples módulos de funciones, es bueno hacerse un esquema de por donde irán los tiros. El diagrama de clases para un sistema donde realmente va a haber mucha herencia, vease un framework es sin duda muy util, para ver que todo encaja. Para componentes no se que se utilizaria oficialmente pero algún tipo de esquema de paquetes de componentes para enumerar los que serán necesarios también será muy útil.

Comentar el código es bueno hasta para el que lo escribe, si no lo hace... pos el sabrá. Eso si, no hay que tomarse estos "preparativos" a rajatabla, han de ser solo una referencia no estricta, en cuanto a los comentarios el código puede ser "arreglado" después de probar una implementación, y en cuanto al UML no hace falta volver a cambiar un esquema de clases cuando no parece que vaya a funcionar o cuando no esté todo cuadrado, eso queda como referencia y se puede intentar improvisar alguna clase o herencia o lo que sea con tal de comprobar como funciona, luego ya se hará un esquema real de lo que se ha implementado para el que venga detrás.

Otro apunte es que un programador con mucha soltura y metodologías como Scrum, la implementación de las "cosas" es tan concreta y ágil  que casi no se ha de invertir tiempo en diseñar nada a nivel programación, en una implementación en la que alomejor como mucho están involucradas 3 o 4 clases, el esquema te lo haces en la servilleta mientras almuerzas y a correr.

Obviamente coge cualquier opinión/experiencia de estas con pinzas, cada cual trabaja mas cómodo de una manera u otra.

Saludos.

[Mongo]

Hoy en día casi todo el mundo se pone a teclear sin  haber hecho nada antes y lo va documentando a la vez que lo va haciendo. Si tienes experiencia es una forma de hacerlo pero si no tienes experiencia es más complicado porque la teoría está muy bien pero luego la práctica te pone los límites de lo que se puede hacer más o menos fácilmente y es por donde deberías conducirte.

[TrOnTxU]

Yo hace mucho que no hago UMLs. Entre otras cosas, porque ahora intento diseñar orientado a datos, antes que orientado a objetos, y UML tira demasiado por el tema objetos.

Aun asi hay tipos de diagramas UML (clases, sequencia, etc) que a veces vienen muy bien para "plasmar" el tipo de interaccion o diseño que quieres para algo concreto. Pero como digo yo lo utilizo muy poco, y para cosas concretas, donde creo que se necesita una explicacion o diseño. Intentar diseñar todo un sistema entero con UML antes de comenzar a implementar nunca me ha dado buenos resultados.

Yo pienso que lo mejor son los free-forms y esquemas en general. Yo los hago con el inkScape, o en papel o el la whiteboard y luego tiro de foto con la camara digital, pero como he dicho antes es una ayuda para algunas cosas, no un "dogma".

Otra cosa que utilizo ahora, es mezclar el diseño, la documentacion y a gestión de tareas en un unico archivo .org (del org-mode de emacs). Esto viene bien en algunos casos. Por ejemplo, lo ultimo que he diseñado/"trackeado"/documentado asi es el "FileServer" para los assets.
El truco aqui es mezclar secciones de diseño (por ejemplo los goals e historias de usuario), con tareas (TODO list) que a su vez contienen algo de diseño y algo de doumentacion. En este caso, como se puede exportar el documento en formato HTML o PDF (entre otros) puedes utilizar el archivo final como documentacion.
Por ejemplo:

Código [Seleccionar] Expand


....

*** Commands [3/5]
**** DONE *quit-server* support
*USAGE:* "quit-server".
This command quits the server application.
This command returns a lson message:
#+begin_src lson
server_cmd_return = {
  isOk = // <bool>: is ok ?
}
#+end_src
...


El html que sale es mas bonito que esto, pero la idea es que sabiendo la documentacion final del usuario puedes hacerte una idea de lo que tienes que hacer y al marcar con (TODO/DONE/etc) puedes llevar el "tracking" de las tareas, con lo que te ahorras tener varios documentos, e informacion duplicada en ellos.
Que org soporte varios tipos de hipervinculos es lo que lo hace perfecto para poder añadir enlaces a las imagenes de los esquemas tambien, con lo que al final en un solo archivo de texto tienes tres documentos, y si lo organizas bien, queda todo bastante claro. Por supuesto, luego puedes separar las secciones, y generar un html solo con la documentacion (por ejemplo). Pero ya es mas trabajo, que es de lo que se trata de ahorrar con esto.

De todas formas, esto viene bien para "herramientas pequeñas separadas".
Estoy pensando en probar a utlizar un org por cada "sprint" que haga del "runtime" del engine.
Creo que puede ser útil para planificar los goals del sprint, juntar algo de documentacion de diseño, y  gestionar las tareas. Aunque en el caso de que la "documentación de usuario" sea sobre la interfaz de una libreria (como es el caso), creo que es mejor hacerla en doxygen directamente.

Un saludo.