Nombrar archivos (o como mantener el orden en los proyectos)
Los proyectos de arquitectura suelen desarrollarse en periodos largos de tiempo y generan un gran número de archivos y directorios. Si no hemos sido rigurosos y ordenados, la tarea aparentemente trivial de recuperar un plano concreto desarrollado hace unos meses o unos años (una situación bastante cotidiana en la profesión) puede convertirse en una auténtica odisea que puede desembocar en graves errores.
Mantener un orden de archivos y seguir un patrón al darles nombre que nos permita saber en todo momento y de manera rápida qué es lo que contienen cobran una importancia vial.
Este artículo se centrará en dar unos criterios para crear un código propio para nombrar los archivos de manera eficiente que nos permita saber el tipo de información que contiene, su versión, el proyecto al que pertenecen…
Versiones anteriores
Soy partidario de no eliminar archivos antiguos, ya que el proceso proyectual a veces nos obliga a volver a soluciones que anteriormente habíamos desechado pero que por algún motivo vuelven a tener validez, eso origina un gran número de archivos y ponerles un nombre adecuado para identificar cual es la versión válida con la que deberemos trabajar puede ser complicado. Un sistema sencillo para identificarlos es añadir un número al archivo que nos permita identificar su número de versión. Sin embargo antes de aplicar este método tan sencillo en apariencia cabría hacer algunas consideraciones: ¿lo añadimos como prefijo o como sufijo? ¿la última versión será siempre la de número más alto? ¿cuantas versiones podemos tener de un mismo archivo?
Por defecto, los sistemas operativos suelen ordenar sus archivos alfabéticamente, lo que puede hacer desaconsejable añadir un prefijo que determine el número de versión al nombre de archivo: si tenemos tres archivos (A, B y C) y cada uno tiene un par de versiones (1-A, 2-A, 1-B, 2-B, 1-C, 2-C) al ordenarse alfabéticamente el orden sería este: 1-A, 1-B, 1-C, 2-A, 2-B, 2-C… y así sucesivamente. Los archivos se mezclarían y estarían ordenados por el número de versión.
La tendencia habitual es la de ir añadiendo números a la última versión y cuanto más elevados sean será sinónimo de tener una versión más actual. Esto conlleva un problema cuando se trabaja con archivos vinculados o referenciados: al añadir un sufijo, el nombre del archivo cambia, y por lo tanto el vínculo se pierde o no se actualiza. Cambiar el vínculo no suele suponer mucho engorro pero es algo que no se debería hacer más que una sola vez (esa es la filosofía de los archivos vinculados al fin y al cabo). Una buena opción para evitar ese problema es que la última versión sea siempre la única que no tiene sufijo, y las copias serán las que se numeren. Cuanto mayor sea el número, quiere decir que la copia es más actual.
Otro sistema podría ser añadir una fecha al archivo, si bien esta información es redundante por estar en las propiedades de cada archivo, es mucho más fácil y rápida de leer. Pueden aplicarse las mismas reflexiones hechas anteriormente.
Nombre del proyecto
Una opción interesante que puede facilitarnos el nombre de archivo es la de informar acerca del proyecto al que pertenecen. Esta información puede parecer algo redundante, pues los archivos suelen estar emplazados en un directorio que contiene esa misma información, sin embargo la experiencia dice que a veces los archivos no están en el sitio donde deberían estar (máxime si intercambiamos varios emails con nuestros colaboradores). Si a los proyectos les añadimos un código y a cada archivo le dotamos de ese código, será evidente si un archivo está fuera de su localización y será muy fácil moverlo al lugar correcto.
Información del contenido
Este es quizá el aspecto más evidente del nombre de un archivo, pero no por ello menos importante: el archivo debe informarnos de qué tipo de información contiene sin que sea necesario abrirlo para ver si se trata de una memoria, un presupuesto, un plano de instalaciones o un render. Una breve descripción bastará para satisfacer este propósito, sin embargo hay que tener en cuenta que aunque los sistemas operativos actuales permiten escribir nombres de muchos caracteres no hay que abusar de ello. No hay que olvidar que lo que estamos intentando es leer en el menor tiempo posible la mayor cantidad de información posible. Además, se da el caso de que algunos programas no admiten nombres más largos de 21 caracteres + la extensión: si usamos nombres cortos nos ahorraremos problemas de incompatibilidades.
Otro método puede ser establecer un código de letras; puede que al principio sea engorroso y su lectura no sea tan inmediata, pero con el tiempo este sistema puede ser tremendamente eficaz a la vez que rápido.
Otros datos
Algunas personas opinarán que además de todo lo expuesto anteriormente, el nombre de un archivo también debería dar información sobre si se trata de un archivo de arquitectura, ingeniería, urbanización… o de la fase de proyecto en la que se encuentran (estudios previos, proyecto básico, proyecto ejecutivo…), por dar algunos ejemplos.
Consideraciones generales
Llegados a este punto, un error habitual suele ser el de idear un código que trate de dar solución a todos los temas que aquí se han planteado e incluso otros nuevos, lo cual suele ser contraproducente pues resultan en nombres de archivo muy complicados, largos y difíciles de leer. El método utilizado lejos de ser un sistema rígido e inmutable debe de ser lo suficientemente flexible como para permitir mejoras en el tiempo, y para ello será imprescindible hacer un análisis exhaustivo de la realidad de cada uno que permita diseñar un sistema que satisfaga nuestras necesidades tanto presentes como las que preveamos que pueden ocurrir en un futuro no lejano y deseado.
Nombrar los archivos es algo muy personal y no existen fórmulas magistrales: el sistema que nos funciona de maravilla puede no servirle para nada a otro despacho de arquitectura. La experiencia, propia o ajena (este artículo es un ejemplo de ello), será de gran ayuda en estos casos.
Autor: Carlos Cámara Menoyo
Fecha: 14/01/2007
Permalink: ver enlace original
Contexto: A raiz de una consulta en el foro de +arquitectura decidí poner por escrito las reflexiones a las que había llegado respecto este tema durante mi experiencia laboral.
sobre la fecha y su redundancia me gustaría comentar dos cosas.
yo utilizo el sistema estadounidense (poner el mes antes que el día) ya que soluciona uno de los problemas que comentas, el orden alfabético.
En España sería…
Archivo 03.12.2006
Archivo 04.11.2006
Archivo 05.09.2006
es decir, sin u norden real y rápido para encontrar los archivos.
El otro sistema sería:
Archivo 2007.09.05
Archivo 2007.11.04
Archivo 2007.12.03
la parte de la redundancia que comentas es cierto en casi todos los casos. ahora bien, acostumbrados a hacer backups, copias de copias, retocar una pequeña cosa etcétera… puede hacer perder la fecha de creación del archivo que a veces puede resultar bastante útil.
Saludos,
Víctor
Fotocasa.es
Yo el método que utilizo para nombrar los archivos es bastante ajustado a los comentarios que se han realizado.
El archivo principal no tiene subfijos de versión para no tener que andar “revinculando” otros archivos. Añado un código inicial correspondiente al proyecto y añado un texto corto para indicar el contenido del archivo. A veces marco si son planos de estructura, instalaciones, etc con un pequeño código antes de la descripción del archivo.
Un saludo
Perdonad la demora en contestar. Gracias a los que habéis añadido algún comentario al artículo o habéis hecho referencia a él en vuestros blogs respectivos.
Mith: me alegra leer que hayamos llegado a conclusiones similares por caminos distintos. Será buena señal, ¿verdad?
Victor: tienes razón en lo que comentas de que las copias de seguridad pueden hacer que se pierda la fecha. Personalmente no suelo usar demasiado el formato de fecha, porque no me suele interesar cuando se hizo, sino si se hizo antes o después de tal o cual archivo. Las veces que tengo que poner fechas a los archivos lo hago siempre como tú comentas: año/mes/día para que todo quede bien ordenado.
Espero que sea de utilidad el artículo.
Pues yo debo decir que la idea de añadir prefijos o sufijos me parece nefasta. Los dibujos puede que esten referenciados en multiples hojas de impresion (hablo de archivos CAD) y la modificacion de su nombre de archivo nos obligaria consecuentemente a rerutear los archivos de referencia.
Yo personalmente copio los dibujos de versiones antiguas en una carpeta llamada “Archivo” o “Viejo”, de manera que todos los dibujos deben mantner SIEMPRE su nombre inicial para que no se pierdan las referencias.
EN entornos multiusuario el renombrar archivos tiene otra desventaja. Mientras tu trbajas en Archivo 2009-02-02, puede que yo sin saberlo haya creado Archivo 2009-02-03 basado en una version anterior, al intentar averiguar que archivo es el bueno, probablemente acbaremos perdiendo infomacion y sobretodo tiempo…
Bueno ahi esta mi miga de pan
Hola Marti!
Muchas gracias por el comentario, que por otra parte comparto en parte contigo por el problema con las rutas de las referencias externas (precisamente en el artículo original apuntaba ese mismo problema y comentaba que sería bueno solo renombrar las versiones, dejando la última versión con el nombre intacto). Lo que planteas de moverlo a una carpeta está muy bien, pero creo que no debería limitarse solo a eso, ya que debería haber alguna manera de distinguir el orden de la copia de seguridad y de distinguir la última versión de una copia más allá de la carpeta donde esté. Imaginemos dos casos:
A) soy un colaborador que no ha trabajado en el proyecto y tengo que hacerlo por primera vez. Como no se cual es la última versión ni dónde está guardada le doy a abrir archivos recientes porque se que mi compañero ha estado trabajando en ello. Pero como la ruta es muy larga, solo se muestra el final de ella, por tanto se muestran dos instancias que aparentemente son iguales pero solo cambia la ruta de la carpeta (la copia está en la carpeta “archivo”), por lo tanto tengo un 50% de posibilidades de equivocarme y trabajar en la versión incorrecta.
B)Quiero recuperar una versión concreta, pero como no la renombré, al moverla a la carpeta “archivo” he sobreescrito la versión anterior (en realidad solo hay una versión de copia) y por tanto es imposible hacer lo que quiero.
Por último me gustaría añador que hace ya bastante desde que escribí el artículo original. En este tiempo he ido metiéndome más en el mundo de desarrollo de aplicaciones web y he descubierto un concepto muy interesante y ligado en cierta manera al open-source que usan los programadores: el CVS o sistema de control de versiones. Todavía no he podido investigar a fondo con él, pero está claro que la solución podría venir por allí, ya que es lo que se utiliza en proyectos de programación desde pequeños hasta enormes en los que colabora un gran número de gente y es, por lo tanto, imprescindible poder restaurar versiones concretas.
Saludos
Hola Carlos,
agradezco tu aporte fue muy valioso para mí, quiero instaurar un procedimiento de nombre de archivos ya que trabajo en una empresa informática donde se maneja mucha informacion en el transcurso de un proyecto y muchas veces no la suelen encontrar rápidamente, por tanto tus consejos me dan una luz de como pudiera conseguirlo, aunque el manejo de versiones lo tienen super claro.
Hola Marce,
Me alegra leer que te ha servido de algo. Comentas que en tu empresa tienen muy claro el tema de las versiones, ¿podrías contarnos cómo lo hacen? Así podríamos aprender mucho, porque lo que yo comento no es para nada la solución a todos los problemas…
Saludos