Perdiendo el horizonte

 

No recuerdo dónde, así que no puedo poner el enlace, pero hace unos días leí en un foro a una persona que comentaba haber hecho un proyecto/programa de software y que ahora le pedían hacer la documentación del mismo. Dicha persona preguntaba por herramientas que hicieran algo de ingeniería inversa y le facilitaran el proceso de generar dicha documentación.

Ese post tenía algo así como tres mil respuestas y alguna más. Todas ellas, sin excepción y hasta donde alcancé a leer, criticaban a la persona diciendo cosas como "primero se hace la documentación y luego el código", "hay que pensar antes de codificar", "te pones a codificar a lo loco y así te va".

Bien, esa es la idea generalizada de todo el mundo. Todos "sabemos" que hay que hacer el diseño y la documentación antes que el código. Y lo hacemos porque "sabemos" que hay que hacerlo … pero ¿realmente hay que hacerlo?

La persona del foro no daba detalles en absoluto de su proyecto, pero por cosas como "he hecho" y "ahora me piden" podía perfectamente ser un trabajo de clase. No sé la envergadura de dicho programa, pero si es un trabajo de clase y no un proyecto fin de carrera, posiblemente sea un pequeño software de prácticas que se hace en unas semanas a ratos perdidos (cuando no estás en clase o estás estudiando otras asignaturas y no tienes la resaca del día anterior).

¿Por qué hay entonces que hacerle antes la documentación? ¿Por qué hay que plasmar en un papel lo que vas a hacer antes de hacerlo?

Este señor, posiblemente si pensó antes en lo que iba a hacer. Es más, ante un programa cuyo esfuerzo no se mide en hombres/mes, sino en persona/ratos libres, es perfectamente posible pensar sólo un poco la idea general antes y dejar para mientras se programa el pensar los detalles. Al ser sólo una persona y un programa pequeño, no necesita en absoluto dejar un documento oficial con su "declaración de intenciones", diseño preliminar, detallado, trazabilidad de requisitos, plan de proyecto, protocolos de pruebas…. Si lo hace, nadie nunca va a leerlo o usarlo y además se le pasará el curso. Es posible que esta persona mientras lo programa necesite consultar algo que haya apuntado previamente, pero lo había hecho en una hojilla guarra de papel, que le sirve perfectamente.

Si suponemos que el programa es para una práctica. Es decir, una vez que apruebe, nunca nadie jamás de los jamases va a volver a mirar ese programa. Posiblemente, incluso se pierda. Tampoco es necesaria en absoluto una documentación para su mantenimiento. Es más, salvo que sea con fines académicos, posiblemente el código ni siquiera necesite comentarios, que nunca nadie jamás va a leer.

Me da la impresión, sobre todo en gente con poca experiencia, que se cogen las cosas como "dogma de fé" sin pararse a pensar el por qué. Las cosas hay que hacerlas "así" porque se hacen "así".

Casi con seguridad al 100%, toda la necesidad y buenas costumbres de documentar antes de empezar el proyecto, partió de grandes empresas con grandes proyectos, plazos largos y muchos, muchos programadores involucrados. Ahí sí es imprescindible hacer una documentación seria al principio, de forma que todo el mundo tenga claro como encajan las cosas y que tiene que hacer o no hacer. Pero eso no hace en absoluto que documentar antes sea una buena práctica en TODAS las demás situaciones. Un claro ejemplo es el programa de prácticas de nuestro amigo, que posiblemente le "han pedido" la documentación como parte de su trabajo de clase, pero que no tiene ni tendrá nunca utilidad ninguna.

Y de hecho, para proyectos no demasiado grandes y con un grupo reducido de programadores, posiblemente también sea excesiva e inútil una documentación excesivamente oficial. Cuatro o cinco programadores pueden pensar en reuniones lo que van a hacer, plasmar si hace falta en papel los bloques principales de su proyecto, cómo se relacionan, y ponerse a codificar, con reuniones y pruebas de integración frecuentes. ¿no os suena de algo? Pues sí, justo lo que dicen la mayoría de las metodologías ágiles.

Esta entrada ha sido publicada en metodologías y etiquetada como . Guarda el enlace permanente.

5 respuestas a Perdiendo el horizonte

  1. Pablo dijo:

    Buenas.
    ¿Y finalmente alguien sugirió alguna herramienta para generar la documentación?

    Saludos 😉

  2. Jersson dijo:

    Es cierto, considero que el problema es encontrar el equilibrio en saber lo que se necesita hacer y la especificacion minima para comenzar sin problemas de interpretación que a la larga modifiquen todo nuestro trabajo.
    Yo por mi parte aun soy partidario de tomarle foto a las pizarras de diseño y luego de algunas reuniones, continuar.

    Un saludo

  3. Chuidiang dijo:

    Para generar la documentación hay algunas, pero son de pago: Together y Rational. Hay otras gratis, pero se limitan a generar los diagramas UML de clases (el netbeans mismo, StarUML, etc). Con javadoc, si tienes comentado el código, también puedes generar algo.

    Se bueno.

  4. Blaxter dijo:

    Hombre yo al leer «me han pedido»/»ahora me piden» siempre lo he interpretada como un (mal) programador en una empresa pequeña.

  5. Lek dijo:

    Las cosas hay que hacerlas «así» porque se hacen «así»

    Pues, no te creas, pero creo que a esa frase le falta el matiz de «y porque lo digo yo»…

    No conozco el caso que mentas, pero sí sé que muchas veces se nos obliga a programar sobre una documentación prácticamente nula y sin tiempo para generarla «sobre la marcha», por lo que estás obligado a hacerla una vez terminado el proyecto (en ocasiones meses después) aún a riesgo de que se considere que estás literalmente perdiendo el tiempo. Una lástima 🙁

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.