Cualquier proyecto de ingeniería por la complejidad que acarrea requiere de un esfuerzo especial para plasmar las idea principal y cómo desarrollarla de principio a fin. En el caso de los proyectos de software no nos encontramos en una situación muy diferente.
Pero cómo se puede documentar un proyecto software de forma sencilla y satisfactoria? En los tiempos en que UNIX era practicamente el único sistema operativo se usaban ficheros de texto plano, de hecho muchos de las guías rápidas de Linux o howtos también.
Si a estas alturas eso no nos parece una barbaridad debe faltar poco. Y por supuesto sustituir los ficheros de texto plano por archivos de Word no me parece una solución aceptable. Al fin y al cabo el hecho de tener que cambiar de aplicación para realizar una consulta es de todo menos eficiente, máxime cuando a pesar de las mejoras en potencia de cálculo sigue tardando una eternidad en abrir un simple fichero más o menos formateado.
Y si además se considera que los diferentes desarrolladores pueden no estar geográficamente (ni temporalmente seamos relativistas) en el mismo lugar. Se puede argüir que el correo electrónico salva este inconveniente. Pero en este caso hay que utilizar una segunda aplicación: el cliente de correo electrónico, para descargar el fichero y abrirlo con otra aplicación.
Sin duda alguna los proyectos de software libre, que adoro, han resuelto de forma satisfactoria este problema porque su propia supervivencia dependía de ello. Al ser proyectos colaborativos internacionales, y donde principalmente los desarrolladores aportan su conocimiento, ganas y tiempo libre, es de vital importancia que cada miembro sepa lo que debe hacer, para averiguar cómo hacerlo, y todo ello en el menor tiempo posible.
Es aquí donde el hipertexto o HTML demuestra sus virtudes:
Información accesible en línea
Referencias enlazadas en el documento principal gracias a los hiperenlaces
Estándar
A día de hoy donde muchas de las aplicaciones software a desarrollar hacen uso del navegador, tiene sentido usar esa misma herramienta para presentar la documentación. Al hilo de esta idea han surgido diferentes propuestas como wikis y blogs que además permiten la edición colaborativa.
Pero a todo esto le veo un problema. Por ser un aficionado a la lectura aprecio una correcta impresión, y se debe reconocer que un fichero HTML impreso es de una calidad inferior a un libro barato. De hecho durante bastante tiempo he usado LaTeX para generar documentación impresa de calidad como es costumbre entre científicos e ingenieros (de verdad).
Y aunque LaTeX está bien, por sus muchas virtudes, alguno de sus inconvenientes es aprender un lenguaje de macros (es anterior a la popularización de HTML) y que fue concebido como generador de documentos a imprimir.
Existe algo a día de hoy omnipresente en la sociedad de la información, que estructure correctamente la información, independiente de plataforma, a ser posible un estándar, donde prime el contenido, relevándonos de los detalles de composición y que permita un procesado ágil? Sí, XML.
La importancia de la documentación
Cualquier proyecto de ingeniería por la complejidad que acarrea requiere de un esfuerzo especial para plasmar las idea principal y cómo desarrollarla de principio a fin. En el caso de los proyectos de software no nos encontramos en una situación muy diferente.
Pero cómo se puede documentar un proyecto software de forma sencilla y satisfactoria? En los tiempos en que UNIX era practicamente el único sistema operativo se usaban ficheros de texto plano, de hecho muchos de las guías rápidas de Linux o howtos también.
Si a estas alturas eso no nos parece una barbaridad debe faltar poco. Y por supuesto sustituir los ficheros de texto plano por archivos de Word no me parece una solución aceptable. Al fin y al cabo el hecho de tener que cambiar de aplicación para realizar una consulta es de todo menos eficiente, máxime cuando a pesar de las mejoras en potencia de cálculo sigue tardando una eternidad en abrir un simple fichero más o menos formateado.
Y si además se considera que los diferentes desarrolladores pueden no estar geográficamente (ni temporalmente seamos relativistas) en el mismo lugar. Se puede argüir que el correo electrónico salva este inconveniente. Pero en este caso hay que utilizar una segunda aplicación: el cliente de correo electrónico, para descargar el fichero y abrirlo con otra aplicación.
Sin duda alguna los proyectos de software libre, que adoro, han resuelto de forma satisfactoria este problema porque su propia supervivencia dependía de ello. Al ser proyectos colaborativos internacionales, y donde principalmente los desarrolladores aportan su conocimiento, ganas y tiempo libre, es de vital importancia que cada miembro sepa lo que debe hacer, para averiguar cómo hacerlo, y todo ello en el menor tiempo posible.
Es aquí donde el hipertexto o HTML demuestra sus virtudes:
A día de hoy donde muchas de las aplicaciones software a desarrollar hacen uso del navegador, tiene sentido usar esa misma herramienta para presentar la documentación. Al hilo de esta idea han surgido diferentes propuestas como wikis y blogs que además permiten la edición colaborativa.
Pero a todo esto le veo un problema. Por ser un aficionado a la lectura aprecio una correcta impresión, y se debe reconocer que un fichero HTML impreso es de una calidad inferior a un libro barato. De hecho durante bastante tiempo he usado LaTeX para generar documentación impresa de calidad como es costumbre entre científicos e ingenieros (de verdad).
Y aunque LaTeX está bien, por sus muchas virtudes, alguno de sus inconvenientes es aprender un lenguaje de macros (es anterior a la popularización de HTML) y que fue concebido como generador de documentos a imprimir.
Existe algo a día de hoy omnipresente en la sociedad de la información, que estructure correctamente la información, independiente de plataforma, a ser posible un estándar, donde prime el contenido, relevándonos de los detalles de composición y que permita un procesado ágil? Sí, XML.